Meaning of CI.Velocity.MeasTime with a known DAQmx Timing set Sample Clock

[cbutcher]

I'm using the NI-9361 counter input module to read velocities from a rotary encoder.

A previous thread discussing this problem (with previous hardware) can be found here: Making pulse frequency measurements with NI USB 6356.

My code works pretty nicely, and I'm setting the divisor to 0 and the measurement time to a non-zero time, to have sample-clocked averaged measurements.

There are numerous tradeoffs discussed regarding the combination of divisor and measurement time that can be found in a tutorial here (slightly less clear): Frequency Measurements: How-To Guide, or in the 9361 manual here (page 14 is a good place to start).

My question is regarding the Measurement Time parameter that can be read/written using the CI.Velocity.MeasTime property node (DAQmx Channel type). I tested as follows, labelling Measurement Time from the property node as MT and measurement time from my FP control as mt:

1. Read the Measurement Time (MT). Call DAQmx Timing, and set the reciprocal of a measurement time (mt) as the rate. Read MT.
   • The first value is 0
   • The second call to read MT is non-zero, but less than the value of mt. For example, with mt = 0.02, MT = 0.0133333...
2. Read MT. Write MT with mt value. Call DAQmx Timing with reciprocal of mt. Read MT.
   • The first value is 0
   • The second MT value is the same as the value written. This is the same as the reciprocal of mt in this case. All seems sensible
3. Write MT with 2*mt. Call DAQmx Timing with 1/mt. Read MT.
   • Now, I'd expect the value of MT to be truncated. Using a stopwatch, the number of samples generated over about 10s is as expected by the value given to DAQmx Timing. The value reported for MT (after Timing) is equal to the value written, which is longer than the available time to take a sample.
   • What's going on? Is MT ignored once I called DAQmx Timing? The first test seems to suggest not.

Example code is shown below as PNG and snippet. (For reference, there is no error after clicking stop, and the queue input is invalid when used as a top-level VI)

DAQmx_RotEnc.png

DAQmx_RotEnc_snippet.png

[cbutcher]

Partial answer: If the measurement time is longer than the sampling period, then the output data is duplicated.

So with the multiplication by 2, I get each data value twice. Or at least, there are two consecutive identical data values, which might be subtly different.

The loop rate (measured using tick count) is not constant. It varies between 120000 and 80000 uSec, for an expected rate of 0.1s (number to read, taken from rate/10).