"DAQmx Write (VI)" explanation if it wait till the device generates all the samples

[tamirsh]

I am using the "Timing VI" to write continually data to DAQmx 4468. By the TEXT "If the task uses on-demand timing, this VI returns only after the device generates all samples. On-demand is the default timing type if you do not use the DAQmx Timing VI." (from help of this function) I understand that after using the "Timing.VI" the Device will not be in the "On-Demand" mode anymore, and the FUNCTION "DAQMX WRITE.VI" will immediately return and not wait for all the data to be generated.
I can see that the opposite is happened. The Function wait time relative to the number of Samples I`m feeding her.

Can someone explain this ?

Thanks...

The code I`m using is the  "Voltage (non-regeneration) - Continuous Output.vi" example.

[Kevin_Price]

When you use DAQmx Timing to configure a continuous sampling task, you are (very likely) starting to get involved with at least 2 buffers.  (There's a fairly uncommon mode without buffers known as Hardware-Timed Single Point.  If you think you want to use that mode outside of Real-Time, you're probably wrong.)

First there is a task buffer.  This lives in RAM on your PC and it's the buffer that your app deals with most directly.  It's size will be fixed by the time you start your task.  Thereafter, there will be 2 competing processes.  The DAQmx driver will be trying to pull data out of the buffer and transfer it down to your device, freeing up space in the task buffer.  Your app will be periodically writing new data to the buffer, trying to "keep up" with the signal generation process.   Most commonly your app will write bigger chunks of data into the buffer less often while DAQmx will transfer smaller chunks of data down to the device more often.

If you attempt to write more data to the task buffer than the amount of space available, *then* DAQmx *will* wait until enough data gets transferred to the device that it can receive all the new data you're writing.  How can that happen?  Well, now we need to consider the 2nd buffer stage.

Your DAQ device will have an onboard FIFO buffer as well.  DAQmx keeps wanting to transfer data down into the back of the line of this buffer, as long there's room to receive it.  Meanwhile each sample clock pulse causes one sample to be pulled out of the FIFO, making 1 sample worth of free space for DAQmx to transfer more data.

It's possible for this whole process to get backlogged.  Consider an example where you output at 1000 Hz.  The onboard FIFO holds 1000 samples and your task buffer can hold 2000 samples.  If your software tries to write 500 samples at a time as fast as DAQmx will allow, here's how that'll go:

1. You write 500 samples to the task buffer and start the task.  Your app immediately loops to write again.

2. DAQmx very quickly delivers these 500 samples down to the device's FIFO.

3. They start getting generated as output signals at 1000 Hz.

4. Meanwhile your app has already written another 500.  DAQmx gets them all delivered to the FIFO by the time 10 have been pulled out of the FIFO.  The device's FIFO now holds 990 samples and is nearly full.  The task buffer holds 0.

5. Your app loops to write again.  Another 10 samples have been pulled out of the FIFO.  DAQmx can only deliver 20 new ones to the FIFO b/c that fills it up.  So 480 stay behind in the task buffer.

6. Your app loops to write again.  DAQmx is keeping up with the task's sample clock so the FIFO remains full forever more.  The task buffer starts filling up, now holding 970 samples.

7. Etc.  Next loop the task buffer has 1460 samples, then 1950.

8. The next loop is where DAQmx Write gets stuck waiting.  There's only room for 50 more samples and you're writing 500.  Space is only being cleared out at 1000 Hz.  You'll be waiting ~450 msec to free up enough space to hold all 500 new samples.

9. Now both FIFO and task buffer remain full forever more.  Every DAQmx Write will need to wait ~490 msec until there's room for its data to be received.

(With USB devices, there's a 3rd buffer in between these known as the "USB transfer buffer".  I don't know exact details about its workings, but would expect a generally similar behavior.  The extra buffer is needed because USB is a less direct interface than the DMA available via PCIe and similar connections.)

-Kevin P

[Kevin_Price]

Addendum (not the main point of the previous answer, but worth emphasizing):

10. Once both FIFO and task buffer are full, latency is at its maximum.  Data you deliver to DAQmx Write won't become a real-world physical signal until it works through these buffers, leading to ~3 second latency for any changes.

-Kevin P

[dsb@NI]

Tamirsh, do you want help understanding the behavior you observed when modifying the example? or do you want help using the 4468 to generate a dynamic signal?

For understanding/accepting: 

The DAQmx Timing VI is setting properties other than just sample mode and sample rate. You cannot simply replace the DAQmx VI with those two timing property nodes.

For using your 4468:

Use the Timing VI as shown in the example (examples\DAQmx\Analog Output\Voltage (non-regeneration) - Continuous Output.vi) you referenced.

For that specific example, I changed the FP configuration:

With no changes to the Block Diagram and running with whatever buffer sizes DAQmx chooses by default, I get a responsive application where changes to Waveform Settings are seen/heard in the real world almost immediately. 

I would advise you not to rely on default values. Set the sample rate and sample mode using the DAQmx Timing (Sample Clock) VI.

---

If you just need an interactive panel to control your 4468 outputs, use the free DSA Soft Front Panels. The DSG app supports lots of dynamic signal types and handles all DAQmx configuration (including latency). The Pure Tone app leverages the Pure Tone feature of the PXIe-4468 to generate an exceptionally low-distortion tone.

[tamirsh]

Thanks for the answer.

1. First, this example don`t work without I change it a little as shown in the attached pic.

With the 4461 it work fine:

With the 4468 , if I placed the REGENERATION PROP. after the Timing.vi it will work good without giving the ERROR:

2. All I want to understand if the "DAQmx Write.vi" wait or no wait for all the Data to be generated.
From the HELP text I can not understand it. They say that with using Timing.vi we are no more in the On-Demand mode. so the function will not wait till all the Data will be transfer. If it true, how the example scheme has no WAIT DELAY inside?

Where is the function that keep it running with the Cycle Delay mSec it needed?

[tamirsh]

NA

[dsb@NI]

1. Interesting, I don't have to make any changes to the example to work for the PXIe-4468.
2. As Kevin explained, DAQmx Write returns immediately once data has been written to the DAQmx buffer. After a few iterations of the loop, that buffer is full, and DAQmx Write must wait for samples to be pulled from the buffer before new samples can be written. That is why the DAQmx continuous generation examples don't have Wait functions and why you don't have to add a software wait in your DAQmx analog output loop.

[tamirsh]

Thanks.

Lets do it from the end to the beginning.

If I need to :

1. Read continually from 4468 2 CHs like 50 or 100 samples every 2-4 mSec.

2. Update every 2-4 msec the Output D/A (AO0) by Increase the voltage from V1 to V2 or just give it a new value.

3. This Voltage update (AO0) must be "0v" immediately if one of the AI0 AI1 above lets say 2v ("immediately"-in the next 2-4msec iteration).

The outputs init by continues samples mode,  noregenration,  and the Inputs init by continues mode. I "feed" the outputs "DAQmx Write" function every itearation by 0.004Sec*SampleRate data values (for 4ms and 100kHz it`s 400 values) - This is my idea, and it steel give me errors sometimes.

What is the best way to program it? What should be the correct setup of the TASKs ?