DAQmx write task not getting over

[jsamuel4]

I am trying to write 2 samples each on two channels. I am also simultaneously trying to read 2 samples from a single analog input channel. I am using AI trigger as AO StartTrigger and clock source as AO SampleClock. I have attached my VI. I want the sample to be read from AI after the corresponding samples have been written to the two AO channels. Now, my write task is not getting over - Is Task Done is always giving False. Why is it so?

Thanks in advance.

[GerdW]

Hi Samuel,

I want the sample to be read from AI after the corresponding samples have been written to the two AO channels.

Right now you start the AI task before you start the AO task - in opposite to what you want to do…

trying to read 2 samples from a single analog input channel.

Right now you trying to read as many samples as have been acquired so far - nowhere in your VI you are requesting just 2 samples…

- the error wiring is broken partly missing in your VI.

- there is no wait state in the while loop

- there are missing inputs to the DAQmx functions

Please clean up your VI and wire the missing items. Correct the order of DAQmxStart calls!

[jsamuel4]

Hi GerdW,

I have fixed my original problem of the task not getting over. I had given Sample Mode as Continuous Samples in the DAQmx Timing block. When I changed that to Finite Samples, the task gets over quickly as expected. So I guess the DAQ was writing those two samples again and again when it was in the Continuous Samples mode.

Right now you start the AI task before you start the AO task - in opposite to what you want to do…

I am doing that because I have set the AO task's StartTrigger as the trigger for the AI task. So the AI task should start first before the AO task so that it can get the trigger.

- the error wiring is broken partly missing in your VI.

- there are missing inputs to the DAQmx functions

I had a rather big diagram and I tried to condense it into the essential parts needed to generate my problem. That was the reason for these two issues. 🙂

- there is no wait state in the while loop

What do you mean by this? Should I put a wait block inside the loop? Why?

Thanks a lot.

Cheers,

Samuel

[Bob_Schor]

---

@jsamuel4 wrote:

 - there is no wait state in the while loop

What do you mean by this? Should I put a wait block inside the loop? Why?

---

Here's the loop in question.  We don't know exactly what the "Is Task Done" function does, but let's say it checks the value of a flag stored somewhere in memory.  It can probably do this pretty quickly, so let's say this takes 1 microsecond.  Then when the microsecond is up and the code inside finishes, the While loop makes it run again.  So this will run "as fast as it can", or at 1MHz (maybe even faster if the function takes less time).  Do you really want to be using all of those CPU cycles checking if the Task is Done?  Depending on what else is in your code, you may want some CPU power left to do other things.  So the question is, how quickly do you need to respond once the Task is done?  How does 10 milliseconds sound?  If you put a Wait 10 msec function inside this loop, the loop would be idle for 10 msec, would use 1 microsecond to "do its thing", thereby leaving 9.999 milliseconds (or 99.99%) of the CPU power available for any other part of your code that needs to run.

Timing functions are important in LabVIEW precisely because it is a Data Flow language, and hence is inherently parallel, with multiple processing streams needing to share the same Computer Resources.  Judicious use of Timing functions, of "blocking" functions (such as the Event Structure and Dequeue functions) that take no CPU time until "something happens" (note that most such functions include a Time-out feature) allows the various parts of your program to "play nice" and share resources, provided you don't code a "CPU Hog" such as the loop shown above.

Bob Schor

[jsamuel4]

Thanks a lot for the detailed explanation, Bob!

Samuel