NI-6289 DAQ latency for digital waveform generation

[jonathon14]

What I am trying to achieve is less than 1 second of latency between updating several digital waveforms and seeing those values appear on the digital output pins.  For example if I have 16 digital ouput channels in my task, and I write 127 samples to each channel at a rate of 1 sample every 10 ms, then I update the waveforms in Labview that are being sent to each channel, I do not see the new values on the output pins for about 21 seconds.  The onboard FIFO size for the 6289 is 2,047 samples.  At this point I am assuming that this latency is being introuced by the onboard FIFO- but I could be wrong. 

If the onboard FIFO is shared by all channels in a task, and one sample from each waveform is generated at the output every 10 ms, then I would expect the latency to be (2,047 samples/16 channels)*10 ms/sample = 1.27 seconds.  However, I still observe a latency of about 21 seconds. Is there something fundamental about the onboard FIFO I am misunderstanding? Or is there something happening in the PC buffer that adds this latency?

I have attached my VI for reference. NOTE: The attached VI only has 2 channels for simplicity yet it exhibits the same latency as the 16 channel example. I have a analog aquisition loop running as well to monitor the digital pin outputs.

Thank-you in advance.

[John_P1 · Accepted solution]

The FIFO isn't per channel, each line is one bit and the FIFO stores the entire port 0 as a single sample (lines that aren't used in your task are masked off and not updated).  So your 2047 sample FIFO clocked @ 100 Hz is going to take roughly 20.47 seconds to fully generate.  There is also a FIFO in software (the size of this is configurable) that stores the data before it is transferred to the device.  The driver will always try to keep the hardware FIFO full if there is data to be generated, which is good for preventing underflows but bad for latency.

Though I have LabVIEW 2013, I haven't installed it on this PC and so I can't look at your VI.  I'll try to give some suggestions anyway...

One way around this issue is to use non-regeneration (not sure if you are already or not) and to limit the rate at which you write to your task so that the FIFO is never full (once the data is written to the device, you can't remove it from the FIFO).  To limit the write speed, try looking at "Total Samples Per Channel Generated" (I believe it updates frequently enough on USB devices to be useful) compared to "Current Write Position".  Both are DAQmx Write properties.  Only write data to the task when the difference is below some threshold.

The other way you might consider would be to just output at a faster rate using duplicate data.  For example, [1, 0, 1, 0] @ 100 Hz = [1, 1, 0, 0, 1, 1, 0, 0] @ 200 Hz.

Best Regards,

[Kevin_Price]

Another thing you could experiment with is a special DAQmx Channel property node.  I've done little if any experimenting with this personally, so I'm not sure if it'll help.  Just figure it might be worth a try.

DAQmx Channel property node->Digital Output->General Properties->Advanced->Data Transfer and Memory->Data Transfer Request Condition

I *think* this will prevent the board from storing up samples in its FIFO and thus keep your board-driven latency small.  The board should only request data from the system when its FIFO is empty.  Note that it also leaves you much more susceptible to underflow errors -- that's the trade off.  Fortunately, I doubt you'll have underflow issues with a DO rate of only 100 Hz as long as your board is on an internal bus like PCI or PCIe.  Not so confident about USB.

-Kevin P

[jonathon14]

Thank-you very much for your helpful reply John.  The fundamental misunderstanding I had related to the onboard FIFO being 2,047 samples vs 2,047 bits.  I now understand that I have 2,047 bits for each line - thus the inherant latency.  

I had been playing around with the non-regenerative mode. My problem there was that my loop containing the DAQmx node wrote to the buffer at a much higher rate than what the FIFO was emptying at. Hence the FIFO would fill up and I would see a full FIFO's worth of latency.

The optimal solution I chose - considering my application - is the the following.  Use regenerative mode and write 2000 bits per line with each bit being generated every 250 microseconds.  In order to obtain a 10 ms pulse I write 40 bits of the same value.  But now due to my very short bit duration my FIFO empties and updates every 0.5 seconds. 

Thanks again!

[jonathon14]

@Kevin.  Thanks for the reply. I have tried playing around with this property but for some reason I get an error message each time I set it to "onboard memory empty".  The error message says that I can only use the other two options: "Less than full" and "Less than half full".