NIDAQ Tools -- Triggered Change of Output Waveforms

Share icon

In the following thread the author details how to change the target wave into which a triggered DAQ sequence saves.  

https://www.wavemetrics.com/forum/general/how-programatically-repeat-daq-sequence

The key here appears to be the /RPT and the /RPTH (hook option) for each repeat.  However, I have the opposite problem that I need to change the output waveform specified in the DAQmx_WaveformGen function in response to an external TTL which does not have the repeat and repeat hook flags.  So the question is how to change the output waveform on receipt of a input trigger?

If anyone has an idea, I would appreciate any input.  

At this stage my strategy is as follows:

  • Set the list of wavenames I would like to output.
  • Setup a DAQmx_CTR_CountEdges instance and have it trigger on the rising edge of the input trigger and only acquire 1 data point.  Using the /RPTH flag call a user function "startWaveform"
  • Call a user function "setWaveform" that sets up the stops any existing waveform output and then sets up DAQmx_WaveformGen for the first entry in my wavename list and start immediately.
  • Repeat until done with the waves.

 

Does this sound reasonable?  Will there be a large time lag in the DAQmx_WaveformGen?

Thanks,

Brian

 

 

 

 

 

Wow. Very clever, and not at all obvious!

If you can tolerate having Igor unavailable, you could use fDAQmx_WF_WaitUntilFinished() and change the waveform wave when it returns.

May 23, 2019 at 05:09 pm - Permalink

For those interested in my solution please see the attached.  

In short, this method "works" with the caveat that there is a variable delay (30-70 ms) between the input trigger to change waveforms and the start of the next waveform.  I suspect this is due to the overhead with the NI control and the lack of the RTOS. For my application the timing needs to be solid and you can queue up two different waveform outputs on a NI device. Only one waveform setup call is allowed at any given time.

Other gotchas I noticed in debugging this approach is that if you reset the device before the waveform is stopped it can sometimes crash IGOR.  It would obviously be nice to a slower delay time between waveform outputs but this may help others.  

For reference I was using a USB-6351 unit and my goal was to have sub 10 ms delay between the ending and starting of user-defined waveforms.  

Off to microcontroller land...
Sequential output of waveforms--triggered (103.89 KB)

May 31, 2019 at 10:55 am - Permalink

Perhaps you could give me a recipe for a crash, or a minidump (DisplayHelpTopic "Crashes On Windows"). Crashing is something Igor and NIDAQ Tools should not do!

May 31, 2019 at 02:01 pm - Permalink

I will reproduce the error when I'm back in the lab next.  Also, a point of clarification, originally I wrote:

bhclowers wrote:

For my application the timing needs to be solid and you can queue up two different waveform outputs on a NI device. Only one waveform setup call is allowed at any given time.

The sentence should read: For my application the timing needs to be solid and you can't queue up two different waveform outputs on a NI device.

June 1, 2019 at 10:48 am - Permalink

Forum

Support

Gallery

Igor Pro 9

Learn More

Igor XOP Toolkit

Learn More

Igor NIDAQ Tools MX

Learn More