topic DAQmx: read value(s) with delay in LabVIEW

DAQmx: read value(s) with delay

Pavel_47 — Wed, 04 Jun 2025 19:35:09 GMT

Hello,

Here is a part of my initial setup:

analog output generates a value at each loop iteration
analog input must wait for some time (50ms in this case)
then AI reads a number of samples
then it calculates average, that is used for further processing (in this simplified version connected to 2nd output to be controlled at oscilloscope).

This setup doesn't work, generate error 200284 (some or all samples requested have not been required).

Similar example I've found here:

http://www.ni.com/example/25905/en/

Thanks in adavnce.

Re: DAQmx: read value(s) with delay

Bob_Schor — Mon, 02 May 2016 13:33:10 GMT

A couple of questions.

The example does a single sample. Your AI task is also set up as a single sample, as you start and stop the task within the loop.
Look at how the example starts the tasks. Which does it start first? Can you understand why that is important? Think about it, then fix your code.

Bob Schor

Re: DAQmx: read value(s) with delay

Pavel_47 — Mon, 02 May 2016 14:06:56 GMT

Indeed, "read" starts first.

So, the solution would be put start/stop staff for generation branch also inside loop ?

Re: DAQmx: read value(s) with delay

Bob_Schor — Mon, 02 May 2016 14:18:26 GMT

No, to start both outside the loop. Think about the sequence you want to have happen. Both the AI and AO systems are running, waiting for something to do. The AO gets a trigger, does its thing, generates (after a delay) the AI trigger, the AI is Ready to Roll so it also does its thing, the loop "loops", and you Do It Again. The point being, everybody is running and waiting for their signal.

Bob Schor

Re: DAQmx: read value(s) with delay

Pavel_47 — Mon, 02 May 2016 15:08:23 GMT

Here is what I tried.

Once running it generates the following error:

Error -200557 occurred at Property Node DAQmx Trigger (arg 1) in read_input_with_delay (1).vi

Possible reason(s):

Specified property cannot be set while the task is running.

Set the property prior to starting the task, or stop the task prior to setting the property.

Property: Start.Delay

Task Name: _unnamedTask<36>

It seems that "Start" block should be used after "Start Trigger". Isn't it ?

Re: DAQmx: read value(s) with delay

crossrulz — Mon, 02 May 2016 20:11:13 GMT

@Pavel_47 wrote:
It seems that "Start" block should be used after "Start Trigger". Isn't it ?

No. You have the trigger being set up after you call the DAQmx Start Task. All of your trigger setup should be done before that and before the loop.

Re: DAQmx: read value(s) with delay

Pavel_47 — Wed, 04 Jun 2025 19:35:36 GMT

Thank you for suggestion.

Here is what I've tried (snippet below).

The same error: some of all samples requested have not been acquired.

I've looked through a number of examples concerning synhronization.

None corresponds to my setup.

All of them uses waveform defined outside loop, whereas in my case the output is generated inside loop.

For example this one:

https://forums.ni.com/t5/NI-DAQmx-Examples/Multi-function-Synchronization-for-AI-and-AO/td-p/3490608

Re: DAQmx: read value(s) with delay

Pavel_47 — Tue, 03 May 2016 12:22:26 GMT

The issue seems to be enchanted.

Having no solution with HW triggering, I've tried to create something similar using only LabVIEW programming features.

And even this doesn't work.

Here is the gernerated error (apparently it's impossible to copy error message as text !)

Re: DAQmx: read value(s) with delay

Bob_Schor — Tue, 03 May 2016 14:06:32 GMT

Wow. I got it to work, and in the process, learned something I didn't know about Finite Sampling.

So I have a USB-6009 that has 2 D/A output channels and A/D input channels, so I thought "Why not run this program on my own DAQ device?". Of course, it didn't work, but for different reasons, such as my not having set the Max/Min properties of the Channels (your device probably allows D/A ranges of ±10V, but the USB-6009 is 0 to +5. Not only do you need to set the Output Scales (easy to do with MAX Tasks), but you need to be sure that when you send the Averaged A/D Voltage out, you don't send a negative value (since I had no signal, I just send "Average + 1").

I simplified my DAQmx coding by using MAX Tasks (see "Learn 10 Functions in NI-DAQmx ..." -- a Web Search will surely find this very nice NI White Paper). But it still didn't work -- it failed on the second loop. Now, I've never done Finite A/D sampling under program control before (I usually use Continuous Samples), so I wondered "Maybe I need the Start and Stop Task function inside the loop". And then it worked.

Here's my slightly-revised code (I did some wiring cleanup). Note that V_Output, V_Control, and V_Sample are the names of the DAQmx Tasks I created (where the "DAQmx Details" are hidden). I did my best to get rid of frames, keeping only the one needed to "separate" the AO from the AI.

Bob Schor

Re: DAQmx: read value(s) with delay

Pavel_47 — Tue, 03 May 2016 15:51:48 GMT

Bob_Schor a écrit :
Wow. I got it to work, and in the process, learned something I didn't know about Finite Sampling.

So I have a USB-6009 that has 2 D/A output channels and A/D input channels, so I thought "Why not run this program on my own DAQ device?". Of course, it didn't work, but for different reasons, such as my not having set the Max/Min properties of the Channels (your device probably allows D/A ranges of ±10V, but the USB-6009 is 0 to +5. Not only do you need to set the Output Scales (easy to do with MAX Tasks), but you need to be sure that when you send the Averaged A/D Voltage out, you don't send a negative value (since I had no signal, I just send "Average + 1").

I simplified my DAQmx coding by using MAX Tasks (see "Learn 10 Functions in NI-DAQmx ..." -- a Web Search will surely find this very nice NI White Paper). But it still didn't work -- it failed on the second loop. Now, I've never done Finite A/D sampling under program control before (I usually use Continuous Samples), so I wondered "Maybe I need the Start and Stop Task function inside the loop". And then it worked.

Here's my slightly-revised code (I did some wiring cleanup). Note that V_Output, V_Control, and V_Sample are the names of the DAQmx Tasks I created (where the "DAQmx Details" are hidden). I did my best to get rid of frames, keeping only the one needed to "separate" the AO from the AI.

Bob Schor

Bob, thanks a lot.

I've tried your example and it works.

Unfortunately the accuracy with SW timing is quite mediocre ... instead of specified 50ms the delay is about 75ms (please the snapshot from oscilloscope).

For our actual testbend is sufficient, but with some advanced features (that we planify to integrate in the future) such accuracy will be probably insufficient.

It's 2nd day I'm searching for a solution with HW timing (i.e. using "Start Trigger" and "Start.Delay" property node), but without success: all the examples that I've found until now uses perdefined waveform (i.e. defined before loop), whereas in my setup output value is generated inside loop. Have you any experience with "Start Trigger" ?

Thanks in advance.

Pavel.

Re: DAQmx: read value(s) with delay

Bob_Schor — Tue, 03 May 2016 17:35:48 GMT

Sorry, I've been fortunate in dealing with "simple timing" situations. However, I'm sure other Forum readers with the proper experience will see this and chime in (and maybe even point out flaws in my code -- where did the extra 25 msec come from?)

Bob Schor

Re: DAQmx: read value(s) with delay

Bob_Schor — Tue, 03 May 2016 19:45:45 GMT

Oops, I spoke too soon -- I should have tested my own code (and my own device). So here's what I did --

I sprinkled 5 High Precision Timers in the code that I posted. Two were back-to-back before the D/A loop to estimate how much time the "Timer" took to produce a time.
The third was right after the D/A (I was curious how long it took to output a sample).
The fourth was right after the 50 msec delay.
The last was right after the 100-point (at 10KHz) A/D sample.
All of the Timers were tied to Error lines. The first three were on the Error Line through the D/A function, while the last two were before and after the A/D read.

Here are the results after running about 10 seconds (generating about 100 results), expressed as Mean ± Standard Deviation.

Delay caused by the timers: 2 ± 1 microseconds.

D/A conversion : 1.0 ± 0.2 milliseconds

Delay : 56 ± 0.3 milliseconds

A/D conversion : 100 ± 31 microseconds

Aha! If the A/D conversion started when I did the DAQmx Read, the timing should have been 10 milliseconds, not 0.1 millisecond. So the code is wrong -- the Start belongs on the other side of the Wait.

That's much better. Here are revised timings:

Delay caused by the timers: 4 ± 2 microseconds.

D/A conversion : 0.6 ± 0.05 milliseconds

Delay : 49 ± 0.08 milliseconds

A/D conversion : 18 ± 0.7 milliseconds

So the Delay is pretty accurate (providing you have the rest of the code right, of course. Yes, now that we are starting the A/D after the delay, we may have to do "timing tests" such as this to figure out how much (8 milliseconds?) is taken up "getting ready" (provided we don't discover how to "start" the A/D but tell it to wait for a hardware trigger signal).

It is also not a bad idea to test your code (as I initially failed to do, but now have done), as it might prove to be illuminating.

Bob Schor

Re: DAQmx: read value(s) with delay

Kevin_Price — Tue, 03 May 2016 20:33:38 GMT

Pavel,

I think the following is what you were describing in the original message. Generate an AO stimulus, wait 50 msec for your system to respond and settle, capture AI to do averaging, output the average as AO.

I included partial code below. It's based on expecting the tasks *NOT* to be using any kind of triggering. The AO tasks should be started before the loop, the AI task should be committed before the loop (as shown).

Expectation is that the 2nd AO will occur about 60-61 msec after the 1st. 50 msec for the explicit delay, about 10 msec more for the 100 samples at 10 kHz. Adjust as needed.

-Kevin P

Re: DAQmx: read value(s) with delay

Pavel_47 — Wed, 04 May 2016 10:52:43 GMT

Thanks Kevin and Bob,

I've tried the enhanced solution, proposed by Kevin (snippet below) and the delay seems to be perfect ... probably because of using virtual device (I've tried it at home)

I will try it next Monday on a real device and communicate you the results.

But besides that do you really consider that for such kind of setup HW synchronization (i.e. triggering with specified delay) is unrealizable ?

I've looked through a certain number of exapmles and all of them use HW synchronization.

Of course all of them use prediefined waveform for DA output (not generated inside a loop as in my case).

So, this particularity of my setup makes HW synchronization unrealizable ?

Thanks

Re: DAQmx: read value(s) with delay

stockson — Wed, 04 Jun 2025 19:36:22 GMT

Hi Pavel,

a few comments:

1) The error -200284 was appearing most probably because the trigger works only once, in the beginning of the acquisition. To have it armed again you would need to set the task as retriggerable and use a different signal as trigger (the start trigger will also be generated only once - in the beginning of the acquisition).

2) If you want your code to be running continuously, the AI acquisition cannot be finite (starting the ascquisition/generation inside the loop is not the best idea, especially if you want to have tight synchronization on the level of ms).

3) Usually the best way to create unusual timing configurations is to use counters. Counter functionality will depend on the device family - you can find more details on this topic in the manual (information relevant to the X series is here: https://www.ni.com/docs/en-US/bundle/pcie-pxie-usb-63xx-features/resource/370784k.pdf#page=155 ). The general idea is the following: you configure AO to use the counter output as sampling signal, connect the AI sample clock to the counter input and create a counter task that will output a single pulse with 50ms of low time every time it gets a rising edge on the input. The outcome? AO will output a signle sample exactly 50ms after the AI is sampled (this is the effective delay we create). Please let me know if something is unclear. I can elaborate more if you are interested.

Re: DAQmx: read value(s) with delay

Kevin_Price — Wed, 04 May 2016 15:23:42 GMT

I'm fully in agreement with stockson that continuous AI would be a better choice. I didn't want to get into it b/c it looks like your app wants to ignore most of the AI data, and only pay attention for about 10 msec out of every 100. The way *I* would approach that situation is to use DAQmx Read properties to always ask for the most recent sampled data rather than gathering a continuous stream and throwing out 90% of it after the fact. Here's an older post that shows how to set that up.

As to the hardware timing sync, yes there are probably ways to accomplish what you need but it'll take a relatively advanced bit of DAQmx programming to pull it off. Doable, but not trivial. Spend a little time learning about "Hardware Timed Single Point" sampling mode, which is what you'll need for the AO task(s). On a given board you'll probably only be allowed a single AO task that uses hw timing, so you'll need to figure out how to handle 2 channels of output that need to be updated at different instants. (Hint: calculate once, write twice) The exact timing relationship between the AO and AI isn't clear to me yet either, but you'll probably want something more repeatable than a msec wait timer. Syncing them in hw is complicated by the fact that you want the AI running at a much faster rate so you can do some noise-suppressing averaging. Therefore, the AI and AO can't simply share a sample clock.

In short, yes you can probably get there from here, but there's a lot to be learned and tried along the way. I suggest you start by taking the software-timed example and converting the AI to a continuous sampling task. Next, I'd suggest playing around with hw-timed single point AO as a separate dedicated program before integrating it in with this one. And so on, one step at a time.

-Kevin P

Re: DAQmx: read value(s) with delay

Pavel_47 — Wed, 04 Jun 2025 19:37:05 GMT

stockson a écrit :

Hi Pavel,

a few comments:

1) The error -200284 was appearing most probably because the trigger works only once, in the beginning of the acquisition. To have it armed again you would need to set the task as retriggerable and use a different signal as trigger (the start trigger will also be generated only once - in the beginning of the acquisition).

2) If you want your code to be running continuously, the AI acquisition cannot be finite (starting the ascquisition/generation inside the loop is not the best idea, especially if you want to have tight synchronization on the level of ms).

3) Usually the best way to create unusual timing configurations is to use counters. Counter functionality will depend on the device family - you can find more details on this topic in the manual (information relevant to the X series is here: https://www.ni.com/docs/en-US/bundle/pcie-pxie-usb-63xx-features/resource/370784k.pdf#page=155 ). The general idea is the following: you configure AO to use the counter output as sampling signal, connect the AI sample clock to the counter input and create a counter task that will output a single pulse with 50ms of low time every time it gets a rising edge on the input. The outcome? AO will output a signle sample exactly 50ms after the AI is sampled (this is the effective delay we create). Please let me know if something is unclear. I can elaborate more if you are interested.

Hi Stockson,

I'm trying to implement your scenario.

Indeed there are points that I didn't properly understand.

Here is a staff that I've composed, based on your propositions (at least as I understood them).

As you can it's only rough draft ... only few connetctions are wired.

For example for me it was not clear 2nd point: sampling source management for AI ?

Counter task is configured as follows:

Output terminal: PFI12

Trigger Source: PFI0

Edge: rising

Trigger Type: Digital Edge

High time: 50msec

Low time: 50msec

Idle State: high

Should I create an additional task that outputs square waveform (with period that corresponds to the timing of my while loop on PFI0 output) and also make it sampling source for AI ?

Thanks in advance.

Pavel.

Re: DAQmx: read value(s) with delay

Pavel_47 — Mon, 09 May 2016 10:51:52 GMT

Kevin_Price a écrit :

I'm fully in agreement with stockson that continuous AI would be a better choice. I didn't want to get into it b/c it looks like your app wants to ignore most of the AI data, and only pay attention for about 10 msec out of every 100. The way *I* would approach that situation is to use DAQmx Read properties to always ask for the most recent sampled data rather than gathering a continuous stream and throwing out 90% of it after the fact. Here's an older post that shows how to set that up.

As to the hardware timing sync, yes there are probably ways to accomplish what you need but it'll take a relatively advanced bit of DAQmx programming to pull it off. Doable, but not trivial. Spend a little time learning about "Hardware Timed Single Point" sampling mode, which is what you'll need for the AO task(s). On a given board you'll probably only be allowed a single AO task that uses hw timing, so you'll need to figure out how to handle 2 channels of output that need to be updated at different instants. (Hint: calculate once, write twice) The exact timing relationship between the AO and AI isn't clear to me yet either, but you'll probably want something more repeatable than a msec wait timer. Syncing them in hw is complicated by the fact that you want the AI running at a much faster rate so you can do some noise-suppressing averaging. Therefore, the AI and AO can't simply share a sample clock.

In short, yes you can probably get there from here, but there's a lot to be learned and tried along the way. I suggest you start by taking the software-timed example and converting the AI to a continuous sampling task. Next, I'd suggest playing around with hw-timed single point AO as a separate dedicated program before integrating it in with this one. And so on, one step at a time.

-Kevin P

Kevin,

I've tried your suggestion on HW and it works quite properly - the delay is about 60 ms (measured with oscilloscope) that is explained by conversion time.

Concerning my application, actually it's more simple that I've exposed in my previous posts.

The idea is taking measurement in loop:

AO generates a voltage
Testbend reacts to this stimulus (settling time isn't defined, so the acquisition delay should be adjustable)
System acqires input data - many samples (adjustable ... can be until the end of the while loop iteration)
Acquired data is averaged and then processed

As for me this kind of scenario is one of the most generic, so I was surprised that there is no templates for it (here I mean HW synchronization).

Thanks

Pavel

Re: DAQmx: read value(s) with delay

stockson — Tue, 10 May 2016 08:10:14 GMT

Hi Pavel,

The configuration of the counter should be Retriggerable Single Pulse Generation and the trigger should be set to AI sample clock (you started well; if you need help there is an example in LabVIEW that shows how to do it - Counter - Single Pulse Output).

It would result in something like this (screenshot is taken from the M Series manual):

You don't need to worry about AI clock, it will be generated automatically.

Re: DAQmx: read value(s) with delay

Pavel_47 — Tue, 10 May 2016 11:01:58 GMT

stockson a écrit :
Hi Pavel,
The configuration of the counter should be Retriggerable Single Pulse Generation and the trigger should be set to AI sample clock (you started well; if you need help there is an example in LabVIEW that shows how to do it - Counter - Single Pulse Output).

It would result in something like this (screenshot is taken from the M Series manual):

You don't need to worry about AI clock, it will be generated automatically.

Hi Stockson,

Thanks for feedback.

I've tried "Retriggerable Single Pulse Generation" example. It works.

Then I've tried to implement the similar staff for my case.

Here is the code

Unfortunately an error is generated on running:

I didn't understand what this error means, as I've only one virtual channel. Here is snapshot from Counter task settings: