DAQmx Wait Until Done.vi problem

[RnDMonkey]

From what I've seen on the forums, it seems like I'm not the first to have issues with the DAQmx Wait Until Done.vi VI. In my particular case, I am generating several pulse trains of various numbers of pulses, with 200 ms between each burst. The highest number of pulses would be about 260 of them at a 2 kHz rate. The problem I ran into is that the Wait Until Done VI seems to be waiting in increments of 100 ms, so that when I send 201 pulses (100.5 ms burst), it waits a full 200 ms before continuing on. This makes the Wait Until Done VI amazingly useless once I exceed this number of pulses. I've already figured out how to make my VI work by a case structure that alternates to a fixed 130 ms delay for any number of pulses greater than 200, but the Wait Until Done VI should have worked for this, or at least had documentation indicating this limitation.

Why not operate in 10 ms increments at least, rather than 100 ms?

[RnDMonkey]

Is anybody looking at this? Is it even on NI's radar?

[RT4CY]

Hello Ryan,

Sorry about the delay.  I don't think this is a limitation of the DAQmx Wait Until Done function.  So, normally the DAQmx Wait Until Done function is used for finite generation.  Here is an excerpt from the NI-DAQmx Help.

"When using an external ao/SampleClock for finite generations, you need to provide one extra sample clock pulse than the number of samples in the generation for the Wait Until Done function/VI to indicate the task is complete. For example, if you want to generate 1000 samples using an external sample clock, you need to provide 1001 sample clock pulses or the Wait Until Done function/VI never indicates the task is done."

The important thing to note here is that you need to provide one additional sample clock pulse for the Wait Until Done function to pass along data flow.  This sample clock pulse may be much quicker than 100 ms.  In your case, you are generating a pulse train.  This is implicit timing, so there is no sample clock.  I believe the delay is caused by the use of two counters.  For a finite pulse generation, you are using one counter to generate the pulses, and a second to tell it how long to generate for (the gate).  This is where the delay is happening.  I will try and find some literature which talks about this.

[RnDMonkey]

While that may begin to explain the problem, it does not justify it. Why would it take 100 ms at 200 pulses, but 200 ms at 201 pulses?

[Kevin_Price]

I don't know if these will help for a pulse generation task, but I've used them for analog tasks before.  Check out the properties found under:

DAQmx Write Property Node-->Advanced-->Wait Mode         (and  ...-->SleepTime).

You can try setting Wait Mode to either Poll or Yield to see whether the driver recognizes done-ness sooner.  Possibly even setting to Sleep with

a very small sleep time.  (I *think* I recall that the minimum legal sleep time may be about 10 msec).

-Kevin P.

[RnDMonkey]

Thanks for the response, though I still think NI should correct this shortcoming.

[RT4CY]

As I mentioned before, it does not have anything to do with the DAQmx Wait Until Done function, or how quickly it recognizes that you have completed writing the data.  In fact, if you set the wait mode to sleep, you will be in effect slowing it down.  I have attached a VI in which I measure the delay time between the Write and after the Wait has yielded.  On my system, I receive delay times of 5 ms or less.  In your case, I believe the delay time is due to using two counters.  I am glad you were able to find a solution that worked for you with case structures.  Another method would be to use the DAQmx Is Task Done function in a while loop.  The function keeps checking to see if the task is done.  You can configure the while loop to stop if the function returns True (i.e. if the task is done), and get very low delay time.