Hello all, I am at a bit of a loss using the "DAQmx Triggering.vi" to trigger voltage output with the NI9263 card by detecting a certain level of analog voltage on the NI9239. So far, I have just used a case structure: However, I would like to use Analog Hardware Triggering like on this page (example below): https://www.ni.com/en/support/documentation/supplemental/21/ni-daqmx-data-acquisition-triggering-techniques-using-labview.html In the example above, I believe it starts recording data once the threshold is reached, however, I would like to be recording the voltage the entire time and once the threshold is reached, stop the voltage acquisition and then generate voltage output. Thank you!

Yes. You have to configure the trigger on the AI task, and then import the trigger on the AO task. Here's a quick example. (Disclaimer: I've only tried this with a simulated NI 9775 and NI 9263, and not real hardware). In this example, I configure a rising-edge analog trigger on the AI task, then query its Start.Term[1] property to be imported on the AO task. The AO task is loaded with the data to be written, with a configured start trigger so that it will wait on the AI task's StartTrigger. We start the AO task first (so that it's ready to receive the start trigger) and then the AI task (which will generate the start trigger), then just wait for everything to complete. In this example, we never read from the AI task, because we don't care about the data at all-- we just care that the hardware observes the trigger condition. You'll probably have to play around with it (at least you'll probably want a AO waveform that's not 1000 samples of zeros!), but I think that's the general flow you'd be looking at. [1] On cDAQ, this does require explicitly reserving or committing the task to retrieve that property because it has multiple timing engines, although I could have also explicitly chosen one with the SampTimingEngine timing property.

Multifunction DAQ

Triggering NI9263 card (Voltage Output) with NI9239 (Voltage Input) on cDAQ-9174

Solved!

I'm just gonna piggyback a bit on the good ideas bstreiff has already been offering up.

1. Let's start with speeding up the reaction speed of your original software-timed approach. In addition to starting the AO task before the loop (to speed up the process of writing the output), you could also *possibly* help yourself some by how you handle the AI task config and read.

Do you have a high clocked sample rate for AI? If so, your software loop might not be keeping up. Each time you read 1 single sample it might represent a sample from farther and farther in the past. Even if the reaction speed to write the AO is fast, you'd be reacting to stale data so the overall apparent reaction time would look slower. Instead, you could wire in the magic # -1 to read "all available samples" every iteration. You need to handle the possibility that you get 0 samples out in an empty array, but otherwise you just check whether any of the samples exceed the threshold.
Do you have a slow clocked sample rate for AI? If so, the interval between clocked samples is adding to the latency between "AI threshold exceeded" and "AO value generated".
Do you need your AI samples to be clocked at all? You might be able to speed up the loop by running the AI task in "on-demand" mode (accomplished by omitting any call to DAQmx Timing).

2. It sounds like his analog pause triggering suggestion might also work well (if you get a module that supports it). Note that the hardware trigger will not work on an absolute value of voltage the way your software does. You'll need it to react while crossing a specific signed voltage in a specific direction.

If still ok, then his recommendation about using the analog comparison event sounds promising. The AO task could be configured to use that event as a sample clock, and you'd get hardware-level timing in the AO reaction to the AI threshold.

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.