Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Delay seeing new data from correlated digital output

A customer wants to do correlated digital output with a PCI-6229 and C++ code using VC++.net. In addition,
he wants to be able to output a series of values from a given buffer, then switch to a "resting" buffer. That is, he has a series of outputs that do something specific, then he wants to be able to generate another pattern repeatedly until he decides to do something else.

I set up a counter to produce a pulse train to use as the clock for the operation.

The DO task is set up using DAQmxCfgSampClkTiming with DAQmx_Val_ContSamps.

In order to change the output being generated, I use DAQmxWriteDigitalLines. I expect a delay until
the buffer in PC memory empties andd can hold new samples, but in fact, the new outputs are delayed much
long than that. It is clear from the delay time that the entire FIFO on the DAQ device is playing out
before the pattern changes.

Some questions:

1) Is there a comprehensive description of how DAQmx does digital I/O with M-series devices (or any other devices)?

2) Is there something I can do to eliminate the switch-over delay?

Thanks!
John Weeks

WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
www.wavemetrics.com
Message 1 of 14
(4,015 Views)

John,

I've attached a couple of slides taken from a presentation explaining how data transfer across PCI works in the DAQmx driver.  The example in the presentation discusses analog output, but the concepts are equally valid for digital output.  The notes are pretty detailed and will hopefully give you an idea of what's going on.  To attach the document, I had to change the file extension (the forums don't allow power point attachments by default) so you'll have to change it back to .ppt before opening.

In your case, it sounds like you can fix the problem by changing the Regeneration Mode Write Property from DAQmx_Val_AllowRegen to DAQmx_Val_DoNotAllowRegen.  This can be done by using the DAQmxSetWriteRegenMode function.  This will ensure multiple copies of the host buffer are not downloaded to the board's FIFO and create a worst case latency of one buffer.  Hopefully this helps.

Message 2 of 14
(4,006 Views)
Thanks, reddog.

I think the nice animation needs the speaker to go with it 🙂

The second slide is helpful, though. The second case describes what I want pretty well. But the note says "Maximum latency of One Waveform Period Desired", and my problem is that the latency is at least one period of the onboard buffer.

The last case promises better response by setting the mode to non-regen. If I understand things correctly, that will cause exactly one period of the waveform to be generated, and then it will stop. Can this property be changed on the fly? For instance:

Create a DO task.
Set up clock for correlated output, and non-regen (DAQmx_Val_FiniteSamps).
Write a buffer.
Write new buffer.
Change to regen mode.

And maybe the last two steps need to be reversed.

Am I correct in thinking that the difference between DAQmx_Val_FiniteSamps and DAQmx_Val_ContSamps is the same as calling DAQmxSetWriteRegenMode with either DAQmx_Val_DoNotAllowRegen or with DAQmx_Val_AllowRegen?
John Weeks

WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
www.wavemetrics.com
Message 3 of 14
(4,004 Views)

Hi Reddog,

Could you please send me the complete original presentation that came from?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 14
(3,971 Views)

Unfortunately, the regeneration mode is a configuration time setting on the task and not a run time setting. 

The sample mode and the regen mode are not the same.  The sample mode (finite or continuous) controls how many total samples are transferred to the device.  The regen mode controls whether the same data sample in the buffer can be transferred to the device multiple times or not.  Allowing regeneration is equivalent to saying write once and transfer many.  Disallowing regeneration is equivalent to saying write once and transfer once.  For instance, with regeneration allowed, you can write one period of data to the buffer and set the sample mode to continuous to continuously generate a waveform without writing new data to the buffer.  By setting the sample mode to finite, you can generate exactly N periods of the waveform without having to write new data.  You can accomplish the same thing with regeneration disallowed, but instead of writing the waveform period once, you have to continually write new data to the buffer and keep up with the generation or you will receive a buffer underflow error. 

Each approach has its trade offs.  Regeneration is convenient when you want to replay a pattern.  However, as you've discovered, with regeneration allowed, the driver will attempt to keep the onboard FIFO as full as possible to maximize throughput and resistance to jitter in the system.  This means the worst case latency before seeing new data output is (FIFO Size + Buffer Size) samples.  If your buffer size is significantly smaller than the FIFO size, this latency may not be acceptable.  On some devices, you may be able to set the data transfer request condition to FIFO empty.  This shrinks the worst case latency to Buffer Size samples, but it also effectively eliminates your FIFO.  This means your overall throughput will suffer because you have less tolerance to jitter.  With this setup, you'll likely only see throughput rates around 10 KS/s.  The only other option I can think of to decrease latency while using regeneration is to increase the buffer size, pad the data appropriately, and clock the data out faster.  This is pretty inconvenient, but it could work to solve your problem.

With regeneration disallowed, your worst case latency is simply the amount of data you've written to the buffer.  This approach provides good latency, but it means your application will have to work harder to keep up with the generation since it has to continually write new data to the buffer.  Without knowing more about your application, this is the approach I would recommend trying first.

Message 5 of 14
(3,941 Views)

HI reddog,

Kamran suggested I ask you to forward the complete presentation.

E-mail me at

bar@dsautomation.com

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 14
(3,934 Views)
Reddog:

Thanks for the detailed description of these modes. It is very helpful. I think my approach has to be to pass along the options to my customers; the question then becomes how to do it without generating lots of tech support calls!

Again, thank you. You obviously took a lot of time with your reply.
John Weeks

WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
www.wavemetrics.com
0 Kudos
Message 7 of 14
(3,911 Views)
Hi Ben,
 
It's in your inbox Smiley Happy
Micaela N
National Instruments
Message 8 of 14
(3,906 Views)
Hi Micaela
 
(thanks Ben for pointing me to this discussion)
 
I'm also very interested in the correlated IO presentation
In fact we have some problems with a Dell Xeon processor system that is too fast for the software resulting in only 1MHz Digital Out and even then having to add 2 ms of delay between writing the data and starting the clock
I did send this as a bug and was told to wait on the next DAQMX release.
Everything that helps to solve such issues is welcome.
 
Albert
another LabVIEW champion.
greetings from the Netherlands
Message 9 of 14
(3,873 Views)

Hi Albert,

I posted the Advanced DAQ System Development presentation and the demo VI on our ftp site: ftp://ftp.ni.com/outgoing/ under the Advanced DAQmx - NI Week folder. 

I am curious, is the problem you mentioned in one of the forum threads? 

I hope the presentation gives you some ideas!

Micaela N
National Instruments
Message 10 of 14
(3,841 Views)