I think there's some pretty good clues there, let's see what we can do with them.
First, here's my interpretation of the screenshots you embedded in the attached doc. For each you mention 2 different sample rates but only show a single plot on the graph. I'm supposing that the seeming "drop-out" is where you changed sample rate in the midst of the run? So one plot where the left side comes from the first sample rate and the right side comes from the second?
Because both the degree of quantization (not dramatic) and the density of discrete points doesn't seem to change visibly, I'd have to question what exactly is meant by "sample rate" here and also what the X-axis represents (msec? sample #?). Not knowing DAQ Express to say for sure, I'm inclined to think that your "sample rate" setting is being *ignored*, perhaps because of your choice of "auto-managed timing"?
That said, the next clue is that the apparent fluctuation was reduced *dramatically* when you changed from a 1024 cpr encoder to a 150 cpr. In fact, it seems to have been reduced pretty nearly in proportion to the encoder resolution change. Normally, such a relationship would scream out a problem with fairly severe quantization, but here your graphs don't appear to show such quantization.
Earlier in the thread, you also said that a 10x speed change with the same encoder and same "loop cycle time" both resulted in about the same ~30% apparent speed fluctuation. Of course that means the *absolute* fluctuation must have also varied by a factor of ~10.
So what can explain all this? Well, here's part of it at least: DAQ Express must *not* be doing a fully hardware-based frequency measurement. I think it's using software methods to query (and probably also to try to control) the time intervals. Then it calculates frequency as an integer # of counts (hence the possibility of quantization) divided by a precisely-measured but pretty variable time interval.
For example, let me suppose your attached screenshots were taken at a nominal speed of ~6 RPM or 1 rev every 10 seconds. Now let's look at the nominal time interval between encoder cycles. With the 1024 cpr encoder you get about 100 cycles/sec so the interval is about 0.01 sec. With the 150 cpr encoder you get about 15 cycles/sec so the interval is more like 0.07 sec.
Now let's further suppose that the software method being used is trying to notice and react to each pulse from the encoder, at which point it queries a high-res timestamp. Let's further suppose that the software's reaction speed to such things can vary by 1 msec (in reality, most any software timing under Windows is subject to *much* more variability than this).
With the 1024 cpr encoder, the nominal time interval should be about 10 msec. But the actual interval may be *anywhere* in the 9-11 msec range. 1 cycle divided by any number between 9 and 11 would lead to a +/- 10% error in the frequency calculation.
With the 150 cpr encoder, the nominal time interval should be about 70 msec. Now the actual interval may be *anywhere* in the 69-71 msec range. 1 cycle divided by any number between 69 and 71 would lead to a much smaller +/- 1.5% error in the frequency calculation.
These values are not meant to match your graphs exactly, they're just intended to illustrate the basic idea that there's very likely a quantization effect happening, but the extreme timestamp *precision* (perhaps down to the microsecond?) helps to mask it.
Unfortunately, none of this attempt at understanding will necessarily solve your problem. The bottom line is that DAQ Express appears to use software-timing methods to measure frequency, and that will inescapably add quantization-rooted noise to your measurement. The only way to reduce the apparent fluctuation is to measure time over longer intervals -- but then that will average out and hide any *real* fluctuations happening at higher frequencies.
Under LabVIEW and full access to the DAQmx driver, I'd have (at least) 2 better options:
1. Direct hardware-based frequency measurement for every encoder interval. What makes this better than the software approach above is that the time interval is determined by the counter hardware, so the timing variation caused by the *measurement* method is no longer 1 msec or more, it's 1 80 MHz timebase cycle or 12.5 nanosec.
2. Direct hardware-based sampling of encoder edge counts. This can't be done quite so directly on an M-series device like yours, it requires another task or other clock source to provide a sample clock signal. It isn't too difficult to make this work out in LabVIEW, but I don't know whether DAQ Express has the wherewithal to handle this part, and given the observations so far I'm kinda doubtful.
-Kevin P
ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
