Aperiodic pulse-triggered AO waveform generation

[nvladim]

Dear LabView community,

I am trying to implement a seemingly simple task in my DAQ card - make it listen to aperiodic digital pulses (duration 2 ms, interval 10-100 ms, generated by a camera) and after every pulse it should generate an AO waveform, then wait for the next pulse. I digged through tutorials, examples, and forum topics, but cannot find how to implement it. My current code starts generation of the waveform after a trigger pulse, but then runs continuously, without listening to subsequent triggers. If I remove the While loop, it runs only once.

Pulse-triggered continuous waveform generation

My DAQ board is PCIe-6321, trigger pulses are TTL.

Any help would be greatly appreciated!

Thanks!

[nvladim]

Hi, everyone,

After more digging I found an elegant solution in this thread:

https://forums.ni.com/t5/Multifunction-DAQ/Time-critical-synchronization-using-TTL-trigger/td-p/2685...

and it solves my problem 🙂

Retriggerable AO waveform generation

 So, there were several steps which made it work:

1. Setting DAQmx Trigger property to Retriggerable start.

2. Putting the DAQmx Analog Write VI before the DAQmx Start Task VI. 

3. Putting only the DAQmx Is Task Done VI inside the While loop.

4. Setting the DAQmx Timing VI to Use waveform instance and Finite Samples mode.

Now that it works, could anyone explain why p. 2,3,4 are required for successful operation?

Thanks!

[Kevin_Price]

I just put together a new almost identical example but remembered to refresh before posting.   The only differences were in the loop: I added a Wait function for a little CPU-savings, allowed it terminate on DAQmx error, and I queried a different DAQmx function instead of "DAQmx Is Task Done?" due to some prior knowledge that it's surprisingly sub-optimal.

Why are various steps needed?

2 - must provide data to AO generation buffer before starting task, how else will it know what to start generating?

3 - I'm not entirely sure how "Is Task Done?" behaves in a retriggerable finite task.  Is generally a good idea to query a DAQmx function in order to be informed of any task errors.  In the specific example you posted, it serves no purpose because there's no reaction to errors.

4 - Finite Samples is critical so that retriggering can be meaningful.  Using the waveform instance is a convenience more than a necessity.

-Kevin P

[nvladim · Accepted solution]

Hi, Kevin!

Thanks for your reply, it helped me understand the code better. Indeed, the DAQmx Is Task Done? VI inside the Wait loop was unnecessary, I removed it and the code does its job with empty Wait loop, just waiting the stop button to be pressed. Is it an error-prone design?

Revised code

Regarding p. 2, I previously thought that DAQmx Start Task VI must be always called before Write VI, apparently this is not always the case.

Thanks again,

Nikita

[Kevin_Price]

RE: loop with no DAQmx function

   The way I'd put it is that it's a best practice to code yourself an awareness of any DAQmx task error that may occur.  If one does, your test run is being impacted in terms of signals or data, so you'd rather know that sooner than later.  The key is to call a DAQmx function that executes quickly, won't create a new error of its own, but will inform you of an underlying error that the driver ran into in the background.  My example queries a potentially useful task property and I know from past experience it executes very quickly.

RE: Write-then-Start vs. Start-then-Write

   I'm not near a DAQ machine now to check, but wonder if the sequence of Start-then-Write is needed for an unbuffered AO task (one with no call to DAQmx Timing)?  Something about that opposite sequence sounds familiar to me too, and I can't think of any other good reason why it might.

-Kevin P

[nvladim]

Hi, Kevin,

Thank you for your thoughtful feedback!