LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Stop waiting for analog trigger

Solved!
Go to solution

This probably is a dumb question, but - I have a simple little vi process, running in its own loop.  I send it a command to "ArmTrigger", and I want it to set an analog reference trigger, and when the trigger is satisfied, send me back a message.  *BUT* - 1) that analog trigger may never come, and 2) I obviously need to be able to send an END command to shut down the app.  So my understanding of this is that you 'arm' the trigger, and then "DAQmx Start Task" just blocks and waits - is that right?  This is my first analog triggering task, so maybe I've got it completely wrong... THANKS!!!!

Message 1 of 12
(377 Views)

Not on LV2019 and can't look at the code.

 

"DAQmx Start Task" won't block and wait.  A call to "DAQmx Read" often will, but it also provides a timeout input you can use to limit the (uninterruptible) time spent blocked and waiting.

 

 

-Kevin P

0 Kudos
Message 2 of 12
(329 Views)

Can you save the VI for a previous version (e.g. 2014 or 2015)? I don;t have 2019 installed. 

 

0 Kudos
Message 3 of 12
(323 Views)
Solution
Accepted by topic author PaulOfElora

@Kevin_Price wrote:

A call to "DAQmx Read" often will, but it also provides a timeout input you can use to limit the (uninterruptible) time spent blocked and waiting.


Actually, it *is* interruptible 🙂 If you branch the DAQmx task wire (which is by-ref) you can call DAQmx Control Task with the "abort" option, which will abort the DAQmx Read, returning error -88710.

 

I have used this to do exactly what the OP said, but you need your "control" loop to be in parallel (basically, I had one task monitoring an encoder, and one task reading an analog value. If the encoder behaved in a certain way, I needed to stop the acquisition immediately to turn off the motor driver or it could overheat something.)

 

Another option would be to use DAQmx Events to trigger an Every N Samples Acquired Into Buffer event. You can call DAQmx Start (which, like Kevin said is non-blocking) then wait at the Event Structure, which would be your "listener" for your command messages. (If you're using a Queue, you could switch to User Events to make this a bit simpler). If it gets a Command message, then it can call DAQmx Stop. If it gets the Samples Acquired Into Buffer event, it can then call DAQmx Read to get those samples out of the buffer. To get this, wire a DAQmx Task into the Register For Events function, then click the purple text to select "Every n samples acquired into buffer" event, which you can wire to your Dynamic Event Registration terminal.

Message 4 of 12
(308 Views)

@BertMcMahan wrote:

@Kevin_Price wrote:

A call to "DAQmx Read" often will, but it also provides a timeout input you can use to limit the (uninterruptible) time spent blocked and waiting.


Actually, it *is* interruptible 🙂 If you branch the DAQmx task wire (which is by-ref) you can call DAQmx Control Task with the "abort" option, which will abort the DAQmx Read, returning error -88710.

 

I have used this to do exactly what the OP said, but you need your "control" loop to be in parallel

Nice tip!  Didn't even think of branching the task wire, which can be useful for other monitoring functions as well.  To the OP: just be sure you don't use the branched task wire to *read* data from the task in 2 parallel places.

 

As to the DAQmx Events: do you know how this will behave in a *reference* triggering situation?  I don't (yet), and am not near hw to test.  I'm kinda guessing that even though the task does A/D conversions and buffers them continuously while waiting for the trigger condition, it won't give them to a DAQmx Read call nor will it fire a DAQmx Event until the trigger condition has been satisfied.   

   From there, and still just guessing, lets suppose the DAQmx Event was set for "every 500 samples" and the task was configured for 1200 pre-trigger samples.  Then at the moment the trigger condition is met, there are 1200 valid pretrigger samples and 0 post-trigger samples.  I figure 2 DAQmx Events would fire immediately and a 3rd one would fire after an additional 300 post-trigger samples.

 

Corrections or confirmation?

 

 

-Kevin P

0 Kudos
Message 5 of 12
(297 Views)

Ya got me there, I don't know about that one. I don't think I've ever even used a reference trigger, and I've only used DAQmx events once or twice.

 

I'm guessing a bit here as well, but your guesses sound like what I would expect- no events until the trigger condition is met, then 2 triggers then 1 more. I'm not near test hardware either, unfortunately.

 

Documentation for this event seems a little sparse and I can't find anything when searching regarding the behavior with it and reference triggers. Maybe someone from NI can chime in.

0 Kudos
Message 6 of 12
(285 Views)

sorry, I got all these controls in it and don't know how to just save them off separately.  But I'm getting all kinds of brilliant help from the others on the thread...

0 Kudos
Message 7 of 12
(258 Views)

Holy Cow! I'm growing new neurons! You've given me lots of new techniques to play with - very grateful! paul

0 Kudos
Message 8 of 12
(257 Views)

The idea of registering a new user event for the trigger occurred to me, I saw something like that at:

 

https://www.austinconsultants.co.uk/labview-tip-using-daqmx-events/

 

But I couldn't see a *simple* way to register an event from *INSIDE* an event structure.  That is, my little trigger process is already run by commands given from other processes via registered events.  I could easily imagine getting TOTALLY confused & bedeviled by weirdness... but maybe I'm being too timid!

0 Kudos
Message 9 of 12
(253 Views)

OK, I figured out how to make a snippet, here it is.

0 Kudos
Message 10 of 12
(251 Views)