There are two ways one might decide to measure rotational speed given an encoder input:
1. Sample an encoder task at a fixed time interval--the speed is the difference in position divided by the time interval. This is basically what you are doing now, except your fixed time interval is software-timed (which cannot be as fast, nor is it as accurate as a hardware sample clock).
You may configure a sample clock on your encoder task to address the shortcomings of using software-timing. Typically the clock would be generated by the second counter on the 9172 (or if that is in use, use the "frequency generator" instead). If your clock is faster than the software loop can keep up, you would need to modify the code to read back multiple samples per loop (there is an overhead with each read call so reading more samples at a time would allow for faster rates).
The rather significant downside to this method is that the measurement resolution (in Hz) would be the inverse of the sample clock rate--remember, speed is calculated as some integer count divided by the sample clock interval. If you speed up the clock too much, your measurement resolution might not be good enough (as reference 4000 rpm => ~136.5 kHz). If you do use this method, you'll want to use x4 decoding which effectively quadruples the steps per revolution (so 4000 rpm would now become ~546 kHz).
2. Measure the time between consecutive encoder pulses (pick either A or B) using a known timebase--the speed is the inverse of this time. DAQmx does this for you when you set up a Frequency measurement task (although you'll need to convert Hz back into rpm or whatever equivalent unit you prefer).
Here, you would get a fixed 2048 samples per revolution (one sample for each edge of the encoder). You would use the 80 MHz timebase on the 9172 to measure the duration of each sample, so you would have a 12.5 ns time resolution (1/80 MHz). At the maximum 4000 rpm (~136.5 kHz as mentioned above) your measurement resolution (in terms of frequency) would still be well within 1% of the value (approx. 0.17%).
The issue most people run into is not gracefully handling the case when the encoder stops and no samples are available (or more generally, the issue is that the sample rate is now a function of motor speed). Allowing DAQmx Read to timeout and reporting an error to the user is bad form--you'll want to handle the timeout in a more graceful manner.
The downsides to this method are that you cannot read back the absolute position of your encoder, nor does this method account for direction changes (i.e. there is no concept of 'negative' speed). This method is also less tolerant to noise (since we are not using both A and B) but this can usually be overcome by the use of digital filtering if necessary.
It sounds to me like #2 would be better for your use case, although I guess it depends on how you would like to present your measurements.
Best Regards,
John Passiak
