Synchronization 9172 9411 / Angular acceleration measurements

Question

Hello,
I'm trying to setup a measuring system for a wind power plant test bench.
As it is essential for measuring the power, I need to measure the rotational speed (up to 4000rpm) and acceleration of the device. (The rotor only powers a flywheel)
I'm using a cDAQ 9172 with a 9411 and a angular encoder with 2048 steps.
I don't have problems to measure angular position, speed or acceleration at small sampling rates, using a while loop with shift registers for time, positions and speed.
Problem is I only get a half to one sample per revolution in the interesting area of 2500 rpm. (41 rev/s => 25ms/rev)
How can I get faster angular/counter measurements? I read something about using the 9172's counters as sample clock, possibly giving angular measurements with a precise timestamp, but couldn't get it to work. I have no idea which clock I could use, as examples say neither 20MHz, 80MHz nor 100kHz work.
Can you help me to figure out how to setup this system?
Later on a temperature sensor, a differential pressure sensor and a stepper motor for the break shall be included using a 9401 and a BNC 2115, a 9472 is still available if it would be needed. (I think I can do that alone, when the acceleration measurement works)
Program in the attachment, "Winkel" = angle, "Geschwindigkeit" = speed, "Beschleunigung" = acceleration. (makes it a bit more readable, I hope)
Attachments:
Winkelpos_ohne_Temp.vi ‏86 KB

Answer 1

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