Interesting app... I'm not sure I've got a handle on all the details, but with what time I've got, hopefully the following comments are useful.
1. For the record, it IS possible to perform hardware-timed "correlated" digital input and output simultaneously. I've had an app going for months that generates an 8 bit buffered output pattern on the leading edge of a sample clock and acquires a 24 bit response digital pattern on the trailing edge of the same clock. I'm using a 6259 as well. I'm also using all the static DIO bits for various other inputs and outputs without interrupting the continuous buffered acquisition.
2. If you perform an "on-demand" period measurement, you may stall out your loop waiting for the DAQmx call to return with a new measurement. Another possible option is to perform continuous period measurement. Then you can use a DAQmx Read property node to specify that you'd like to request the most recent data that's already in the buffer. No waiting. (The properties needed are "RelativeTo" = MostRecentSample, "Offset" = -1.)
3. This helps one aspect of your skew problem but another remains. The delay from when you write new DO values into the DO buffer until the time when they actually show up as output signals. Here you can help yourself somewhat by using another DAQmx property node with a name similar to "Data Transfer Condition". Basically, this property controls how much the boards hardware FIFO gets ahead of the system RAM buffer you write to. There's a non-default setting that'll give you faster response at the expense of more frequent short bursts of bus traffic, and hence more risk of underflow errors.
4. I've done this stuff using LabVIEW so I've got no help for C-family syntax for driver calls.
5. The higher the resolution of the encoder you use for period (speed?) measurement, the better you can expect the resulting value to approximate the instantaneous speed.
6. The problem of skew during speed changes is fundamental to the control system. You've got a time delay in your feedback signal. You've also got a time delay in your output control signal. In such a case, you cannot maintain 0 following error (0 skew) during a ramping input. Not unless you can invent what one of my profs used to call a "swami" controller, that exactly anticipates the future feedback signal so you can generate the control output. (There's actually some theory for how you might try to do this for systems with fully known inputs, but I'm assuming that you're dealing with a non-academic real-world case with random-like disturbances.)
-Kevin P.
ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
