Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Delay between the write on an anaolg output and the actual change in continous mode

I am trying to use my 6281 card driven by Labview 7.1 as a function generator.
The analog output is configured in continous mode and the buffer contains the periodic patern that I want to output.
From time to time I rewrite the buffer data to change the patern.
My problem is that there is a great delay between the time I write in the buffer and the time the new pattern is actualy present in my card's output terminal. This delay is independant from the size of the buffer or from the sample rate. In fact it seams that this delay is always equivalent of about 8000 samples, which is the size of the onboard FIFO (but maybe it has no relation).
Could someone give me an explanation for this behaviour ?

I tried to change the "Data Transfer Request Condition" property and when selecting the "On board memory empty" value the delay disapeared and all was fine. With the two other values ("onboard memory half full or less" and "onboard memory less than full") the delay was present.
How is it possible that when waiting for the buffer too be empty I have no delay, but when I write in the buffer as soon as there is some place (so I don't wait at all) I have this great delay ?

Thank you for your help...
0 Kudos
Message 1 of 5
(3,640 Views)
Sreeb,

I don't know the 6281 card specifically, but here's what I *think* is going on. (Comments/corrections from NI folks are welcome):

1. In your app when your use DAQmx Write to define your waveform, it is written to your PC's system RAM. This RAM space is treated as a circular buffer, so each time you write to it you start at the point where you previously left off.

2. Your 6281 card has 8k of on-board FIFO memory that it uses for the actual hardware DAC conversions. The DAQmx driver fills this 8k FIFO by copying data to it from PC RAM. The same PC RAM that you write to once in a while using DAQmx Write.

3. So what happens in the "onboard memory less than full" case? Each time a DAC conversion is performed, the onboard FIFO memory becomes "less than full", so the DAQmx driver will try to refill it more-or-less immediately. Since the FIFO is always defined for the next 8k samples beyond the last DAC conversion, any new output data you write with DAQmx Write can only be appended somewhere *after* those 8k samples.

So you write your data to RAM. DAQmx immediately starts copying it to its FIFO. But it copies it to a position that's still 8k samples in the future.

4. Now for the "onboard memory empty" case. Here the DAQmx driver will try to copy data from system RAM to board FIFO just barely in time for the DAC conversion. The onboard FIFO is always in an almost-empty state, so when you write with DAQmx Write, and the driver copies that data to the FIFO, it comes due for DAC conversion and output within just a few samples.

-Kevin P.
CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 5
(3,627 Views)
OK, this explanation sounds quite relevant.
Thank you very much.
0 Kudos
Message 3 of 5
(3,608 Views)
What is "Data Transfer Request Condition" and where I can found it??????? I'm using labwindows 7.1 but I'm experiencing the same problem, and I cant found it here.

thanks!
0 Kudos
Message 4 of 5
(3,573 Views)

Hi,

You will find explanation about "Data Transfer Request Condition" and n example at the following link:

http://digital.ni.com/public.nsf/websearch/45A7AC6B59E026B386256F90006DAA49?OpenDocument

Best regards

Alexandre D

NIF

Message 5 of 5
(3,546 Views)