"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 ?

[Kevin_Price]

I think I gave a pretty good outline about how buffering works earlier in the thread.  After your latest post, I now see that it's not entirely relevant to your *actual* problem.  Which turned out NOT to be about the role of buffers in affecting the time you wait for DAQmx Read to execute and return.  Rather your problem has much more to do with latency for what sounds like a real(ish)-time control app.  One with a loop rate higher than normally recommended for Windows apps.

A really important question to answer for your app: does your AO produce a waveform that requires a 100 kHz update rate for the dynamics of the data?    Or is it conceivable that you could do piecewise constant updates at ~250-500 Hz using an unbuffered on-demand AO task.  For the sake of this post I'm assuming the former, but if you could "get away with" the latter you'd be making your programming life much simpler.

To minimize latency, you need to minimize the buffer space through which your AO data needs to progress before turning into a real-world signal.  This means you need to minimize the size of the task buffer and the device's onboard FIFO buffer.

First let me refer you to a recent thread I was in where I wrote up some details about settings that affect latency.  Make note especially of #5 in the linked post about managing the device's onboard FIFO buffer.   Also note that the linked thread was about solving the *opposite* problem of yours.  Over there, large latency was fine, long term high speed operation with smooth waveforms transitions were the problem to solve.

Now, a reality check.  What you *want* out of your app is probably more than you can expect if running under a general OS like Windows.  You may be able to meet your 2-4 msec targets a large majority of the time, but not ALL the time.  So you really need to approach the whole thing from a standpoint where you *expect* such occasional timing misses, and have a plan for accommodating them.

One part of this might be to let the AO task *allow* regeneration (for the occasions when timing targets are missed).  I would further advocate that you set up your AO task buffer to be 2x the # samples you will write during each update.  Yes, this can potentially increase your latency.  But it will likely make your overall app more robust and less prone to fatal task errors.

You should also minimize the device's onboard FIFO buffer as much as you can (within reason) without inducing task underflow errors.  But be sensible -- if your task buffer is 100's of samples long, the difference between a 5-sample FIFO and a 25-sample FIFO isn't a big part of the overall latency.

Once you've decided to *allow* regeneration to occur, you'll also need a plan for how to make a proper transition from the "regeneration data" already in the buffer to the next data you're going to write, with the understanding that you need to skip over some data you would have *liked* to write but missed your opportunity.   Depending on your output waveforms and what they are affecting, this could be nearly trivial (simple piecewise constant values) or very difficult (complex waveforms requiring smooth derivatives such as for motion control).

-Kevin P

[dsb@NI]

Tamirsh,

What do your outputs look like? sinewaves, DC, or something else?

It doesn't make sense to output DC values at 100 kHz if you only care about changing the DC value on a scale of 2 - 4 ms. If you only care about DC outputs, why use a 4468?

Is the latency requirement driven by need to control a dynamic system? shutdown when levels exceed threshold?

If it is critical to always meet loop timing, commit to a real-time application. If the application can tolerate occasional misses, define what recovery behaviors are acceptable. As a datapoint, on my desktop system I am able to write to two channels (using the non-regeneration example referenced previously, and explicitly setting the buffer to be 100 samples and sample rate to be 100 kS/s/Ch) using only 1% of my CPU. I have not yet seen any performance errors. The system can acquire and process two ai channels in 2 ms blocks at 100 kHz (takes 16 % of CPU). I have yet to see a performance error. What errors do you see? Do they happen right away? intermittently? or is a slow, but inevitable result of the system not keeping up?