DAQmx Continuous Analog Output Write with Buffer Offset

[Phil Rawlings]

When writing data to a continuous analog output task (using DAQmx), I need the physical output to change as soon as I write the data (not once the current buffer has finished generating).

I have written a LabVIEW program with regeneration set to TRUE, such that when I write new data - it will update at the end of the current buffer. If I don't write new data, it keeps generating the data in the buffer. What I need to know is this:

Does setting the write offset (using the DAQmx write property node) allow me to write a full buffer of data and have it AUTOMATICALLY wrap data to the beginning of the buffer if my write position is NOT at the beginning of the buffer?

Thanks,

Phil

[Jonathan_Brumley]

Hi Phil,

Are you trying to generate a waveform and update the waveform that is being generated?  If so, you are on the right track with using "Allow Regeneration".  And if you want to change the entire waveform that is being generated, then you can set the "RelativeTo" property to "First Sample".  Now, every time you write new data, you will be updating the waveform that is being generated starting at the beginning.

However, if you aren't generating a waveform and are trying to output a constant level and change it every so often, then there is a much simpler way to do it - don't use the DAQmx Timing VI at all and whenever you call Write, you will be updating the current value.

[Phil Rawlings]

Hi Jonathan,

Yes, I am am generating 8 simultaneous waveforms, which I need to keep generating without any intervention from the program. However, periodically I do want to change the data. From my understanding, if you call DAQmx Write when regeneration is set to TRUE you can do this, however it will only take effext once the current buffer has finished generating (although I could be wrong about this!!) What I want to do is to update the output immediately with the new waveforms - so wondered if by writing at an offset, the extra data over the ned of the buffer would wrap around to the beginning... AND also whether this would affect the output straight away (as I have a feeling DAQmx sets up double buffering under-the-hood).

Any ideas?

Thanks,

Phil

[Jonathan_Brumley]

Hi Phil,

Sorry for the _very_ slow response.  I missed your reply the first time.

Have you solved this problem yet?

Here is a little more information that may help in the future...

DAQmx maintains a "device position" in the output buffer that indicates the next sample that should be written to the device.  This internal device position will always be slightly ahead of the actual sample being generated in the hardware because it is updated before the samples are transferred.

When you have regeneration enabled, DAQmx allows this device position to loop around to the beginning of the buffer and start generating "old" data without causing an error in your program.

When you use DAQmx Write to update the buffer during a regenerated AO operation, the DAQmx Write call does not affect the location of the device position.  So, for instance, if you update the ENTIRE buffer with new samples, as soon as the DMA controller on the device fetches new samples from the buffer, the samples fetched will be the samples from your newly written waveform.  There is some delay before the device starts generating the new samples because latency inherent in the DMA controller and in the AO FIFO.  But the delay is NOT typically a whole buffer's worth of delay.  So you should start seeing your new samples in the output relatively soon after writing them. 

You can figure out the maximum delay caused by the AO FIFO by looking up the "depth" of the FIFO in the specs for the device.  Some devices have a single sample FIFO (which causes no delay but limits the update rate).  Other devices may have 512, 2048, or 4096 samples of depth in the FIFO.  Just divide the number of samples in the FIFO by the sample rate to get the FIFO delay.

The delay caused by the DMA transfer is very system dependent so I can't be of too much help without going into a very in depth discussion here.  If this delay is critical to your application, your best bet is to benchmark it by starting with a buffer filled with one value, update the entire buffer to a different value, and finally, update the entire buffer to the original value.  You can use a scope to determine how long the new value shows up on the output terminal before reverting to the old value, or if you don't have a scope, you can time it with your device by routing back the output into a counter (try Measure Pulse Width).

Hope this helps,
Jonathan

[iapetus2001]

Hi, what if I'm not generating waveforms but DC that need to be change every minute between two values? thanks in advance!