Huge latency reading quadrature encoders

[gfoulk]

I'm using a PCI-6601 to read two quadrature encoders on a pan-tilt mechanism. The software uses the DAQmx C interface and polls the encoder positions at 200Hz. The problem is that there appears to be a huge latency on the order of ~50msec between when the encoders move and when the positions being read out reflect the movement. That can't be normal.... is it?

I am able to get data off the DAQ at the 200Hz rate, and the values all look reasonable except that they're time delayed by the aforementioned 50ms. So I'm getting a resolution of at least 5ms, just time-shifted. The first thought was that the values were being buffered somehow, but there doesn't appear to be any buffer, at least that I can find. As I understand it quadrature input shouldn't be being buffered in the first place, and in any case a buffer should be read out with the call to DAQmxReadCounterF64 (the DAQ returns only 1 value), and indeed explicitly setting the input buffer via DAQmxCfgInputBuffer does nothing. 

To double check the results I tested NI's sample code for reading quadrature encoders (http://zone.ni.com/devzone/cda/epd/p/id/5735)  and I get the same latency (minus the ~5ms that was caused by the 200Hz timer, as the sample code polls in a tight loop.)

Any idea of what might be going on here?

Thanks!

Gene

[John_P1]

Hi Gene,

Are you using DAQmx or DAQmx Base?  The sample code you linked is for DAQmx Base.  If you are using DAQmx Base, I would suggest insted using DAQmx if possible--not only does it expose more features but it should result in better single point performance.

I don't know which OS you are on though so perhaps Base might be your only option.

Could you post your code so that we can see if there is anything you could be doing to reduce the latency you are seeing?

Best Regards,

[gfoulk]

Hi John,

Thanks for the reply. I'm using DAQmx. For the sample code I modified it to DAQmx (i.e removed the "Base" from all the calls.)

The code is clearly based on the sample and essentially doing the same thing. I tried the sample to make sure that the problem wasn't due to anything else in the in the code, and since the sample exhibits the same latency you can just refer to that. (The only thing I changed in the sample when running my test was the channel.) It's so simple though it's hard to imagine something is wrong with the code - not to mention the sample was written presumably by someone at NI that knows what they're doing. Unless there's some lower latency way of doing things that DAQmx exposes but DAQmx Base doesn't support, and therefore wouldn't be used by the sample?

Thanks,

Gene

[John_P1]

Hi Gene,

I just wanted to make sure you were indeed using DAQmx (since you linked the DAQmx Base example).  I might expect the DAQmx Base version of the code to take longer to execute, but re-reading your post it sounds like the problem isn't with the code keeping up but rather that the values themselves are delayed by ~50 ms.

A buffer would only be allocated if you configure sample clock timing on your encoder task.  The example you linked doesn't do this, so I'll assume your code doesn't either.  It's probably worth noting that you can configure a hardware-timed sample clock so you can deterministically sample the count register at regular intervals, but this isn't going to help with latency.

So taking a step back for a moment, I am now curious on how you are measuring the 50 ms latency.  To verify a 50 ms delay would require measuring the actual time difference between the start of the counter task and the first pulse of the encoder and then comparing the measured time with the time you are seeing in software (assuming ~5 ms per sample from your 200 Hz polling loop).  I would not expect a 50 ms latency in your measurement, so it's probably worth elaborating on exactly what you are seeing and how you are characterizing it.

Best Regards,

[gfoulk]

Yes, you are correct I have to measure against the physical movement. I happend to have a high speed camera (300FPS) handy so that's what I used, with the time provided by taking the same high-performance clock that's being used to tag the encoder reads and displaying it on-screen. Because the refresh rate of the graphics is 60Hz (verified by measuring time between draws and also by observation on the camera), the resolution of this setup is ~16ms, which isn't great but the observed problem is large enough that it shows up clearly even so. Across numerous runs I see a 3 to 4 frame (48 - 64ms) lag between motion and seeing it in software, which is where I'm getting the 50ms figure from.