NI-DAQmx 6221 USB - high (18 ms) latency?

[CTRInsurgent]

Hi

I've been working on some NI-DAQmx (8.8) code (Visual C++ Express 2008) that's designed to measure a pulse width and then generate a second pulse with width based on the measured width of the first pulse. What I've found is that there's an enormous latency of around 18 ms that occurs between when DAQmxReadCounterScalarF64() returns after its trailing input edge and when the counter output edge goes up, via DAQmxCOCreatePulseChanTime()) and DAQmxStartTask(). Everything does what it should, other than being 18 ms late. I understand that USB has a fair bit of lag involved, but as far as I can tell it should be a few milliseconds or less on a USB 2 link. I can't think of anything these function calls should be doing that takes 18 ms on a brand new 2+ GHz Windows XP box. The two tasks are on different counters, with the input on ctr1 and the output on ctr0.

Also, if the counter task initialization is where the latency is, is there any way to preinitialize it and just write the counter register value after I calculate it?

Thanks,

Ben Buckner

Message Edited by CTRInsurgent on 01-19-2009 09:25 PM

[Jason_D]

Ben,

As you figured I believe most of your latency is coming from the counter initialization.  I am assuming we are constantly updating the frequency of your output?  In that case I think we will want to use DAQmxWriteCtrFreq to change this frequency without having to reinitialize. 

Here is another thread that may help.

Let me know if this does not solve you issue or you have further problems!

[CTRInsurgent]

Thanks for the answer-  the help file I was using only lists the control functions, not the property setting functions, but I found the one that lists the prop functions too.

I'm not doing it in continuous mode. I did find that DAQmxStartTask() is where the latency occurs, but I'm not having much luck changing the property. Is there some quirk related to changing multiple properties as with the duty cycle/frequency linkage in the continuous PWM generation?

Regards,

Ben

[stilly32]

Rather than read a pulse, check the value in SW, write a value and generate a new pulse (all of which are dependent on SW and bus latency) there may be a better way to do this in hardware. Can you describe the signal you expect to measure and the pulse you want to generate (timing diagrams are useful). Also, what other subsystems (AI, AO, DIO) are you using on the device?

Thanks, 

Andrew S

[CTRInsurgent]

Oh, I know there are better ways to do it - this will ultimately be done on an embedded system with interrupts and deterministic latency that I can hide with the counters. We were wanting to prototype a slower version with this card, but I hadn't expected the latency in the DAQmx layer to be this extreme. I think it's the time it takes to spawn a new thread for every task that must be killing it.

Ben