Trigger with DAQmx Wait Until Done.vi

[rbarth]

Hello,

I'm trying to use the Voltage - Finite Output.vi (from the Example VIs) to understand behavior with a trigger and a task where I'm writing a waveform.

I'm using the Start Digital Edge version of the DAQmx Start Trigger.vi using "Rising" for Trigger Type.  I'm writing an analog waveform and want the task to run at an interval defined by the trigger - say every 1 second.  However, I want to generate a waveform that is much shorter than 1 second - say 400ms.

My question is with the DAQmx Wait Until Done.vi.  I've put in indicators for timing and it appears that the DAQmx Wait Until Done.vi does not complete until reaching 1 second, regardless of how much shorter the time is that is required to output the waveform.  Same thing happens if I change the trigger to be every 2 seconds.

Why isn't the task complete after the waveform output is complete.  I figured any code/hardware response included in each iteration should give plenty of time to catch the next trigger occurrence, but instead the "Wait" VI does not finish running until the duration of the trigger somehow.

Any thoughts would be great on what exactly defines a task being completed when a trigger is involved.  Thanks!

[ZYOng]

What is the model of the DAQ device you are using?

Please post the code so that we can provide recommendations.

[rbarth]

Thanks for the reply.  Attached is the VI that I'm using.  I'm using the NI USB-6343.

I've labeled "Frames" where I am attempting to capture elapsed time.  In my scenario, I have the trigger at 1 Hz, and I am trying to generate a 400ms waveform, I am getting 900+ ms time elapsed for Frame 4, which is the DAQmx Wait Until Done.vi.  If I make the trigger 2 Hz, then this frame will take close to 2000 ms.  I'm trying to figure out why it seems to be waiting for the duration between triggers there.

[Kevin_Price]

You're fooling yourself by running your benchmark repeatedly with that outer While Loop.  The first iteration ends at a particular phase within the trigger cycle.  For a 1 Hz trigger and 400 msec of data, the task is done 40% of the way to the next trigger.

Then you rapidly wrap around the loop to do it again and start the task within a few msec.  That leaves you *nearly* 60% of the interval to wait *before* the next trigger *plus* the 40% after it for a total of nearly 100% of the trigger interval.

Try running just once instead by wiring a constant True to your loop terminator.  Then you can initiate distinct individual runs by clicking the run button.  That should pretty well randomize your starting phase, so you should see durations varying randomly in a range like 400-1400 msec.

-Kevin P

[rbarth]

Thanks for the response.  I really appreciate the help.

Shouldn't the time taken in "Frame 4" always be only the amount of time taken to generate the signal?  The "Frame 4" timing ends up being the 1000ms minus the other frames in this loop.

Or is it the case that "Waiting for the task to complete" includes the time waiting for the trigger?

Or am I completely off in understanding this?

I wanted to add a little more context.  I'm trying to perform a little bit of work between each trigger such as choosing different waveforms to generate.  I want to make sure not to miss a trigger and was trying to figure out how much time there was to spare (in general).  My thought was that I would have the total amount of time between the task being completed and the occurrence of the next trigger.  From my timing, it doesn't seem like there is any time in between, but I agree that I might be fooling myself with the way that I am attempting to track the timing.

Thanks again for the help.

[Kevin_Price · Accepted solution]

---

Or is it the case that "Waiting for the task to complete" includes the time waiting for the trigger?

This.  Draw up a timeline for yourself and you'll see it.  Place the trigger pulses one second apart.  Imagine starting your code at some random phase between two triggers.  Then walk through your code while cross referencing the timing to see what's going on.

For simplicity, let's just suppose the trigger times are 1.0, 2.0, 3.0, etc.

On the first iteration, your task will end at time 1.4.  The 'Frame 4' time will depend on whatever random time you arrived at the call to DAQmx Start relative to those trigger pulses.  There's an unknown time to wait until the next trigger pulse so let's call it X.  After you start the task, you'll wait X sec for the trigger and then wait another 0.4 sec for the task to run to completion.  So 'Frame 4' will give you a value X+0.4.

    Then you wrap around to the next iteration of your While Loop and arrive back at DAQmx Start at a time like maybe 1.405.  Then you wait 0.595 for the next trigger and 0.4 for the task for a total of 0.995.  Thereafter, all subsequent iterations will do the same.

If you did 0.25 sec worth of work in the last frame before iterating again, your next iteration would hit DAQmx Start at 1.65, you'd only wait 0.35 for the next trigger, and 'Frame 4' would read 0.75.

-Kevin P

[rbarth]

Kevin,

Thank you, this has been really helpful.  I tried what you talked about originally with wiring a true constant to the while loop.  I do get times randomly in the range you mentioned, although sometimes slightly over 1400msec.

The timeline description was great!  I appreciate the help in understanding.

-Ryan