LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to use the Stop Button in a While Loop to end a daq vi where there is a DAQmx Trigger vi

Solved!
Go to solution

Would like to acquire multiple hammer force data using a While Loop. Data acquisition is triggered using a DAQmx Trigger VI with hammer force. Problem is when the Stop Button is pressed the VI won't end until after 2 more hammer strikes. 

 

Hardware is NI-9205 with a cDAQ-9171 chasis.

 

Thanks a lot!

0 Kudos
Message 1 of 8
(2,589 Views)

I can explain at least *half* the problem.  Due to dataflow, your "Stop" button is being queried at the very beginning of your loop iteration, while you're trying to configure triggering and before the task even starts.  The new True value won't be seen until the next iteration.  That can easily explain why you get 1 more hammer strike before the loop terminates.

 

But with some more careful thinking, maybe I can explain why you (often) get 2 more hammer strikes. Whenever it is you happen to click "Stop", it's almost certain that the pre-click False value was already read for whatever iteration you're in.  And it's also very likely that *most* of your loop time is spent waiting for the triggering event.  Your 200 kHz sample rate and <1000 total samples means that the acquisition itself won't take long at all *after* the triggering event is seen.

   So, you click "Stop" while your task is waiting for the triggering event.  The pre-click False value was already read from the button for *this* iteration.  So you'll get the hammer strike for this iteration and then continue to the next.

   Then on the next iteration you'll read the post-click True value for Stop.  But the loop won't terminate until all code runs, including your task that will wait for a 2nd hammer strike.

 

 

-Kevin P

 

There's also 

  You'll have to wait for the next iteration to read the new True value.  Then the loop won't terminate until the task runs to completion.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 8
(2,540 Views)

Thank you Kevin for your reply! Your explanation makes sense. Would you happen to know any way to fix it except for the built-in "Abort Execution" button?

0 Kudos
Message 3 of 8
(2,518 Views)
Solution
Accepted by LabLearning

The call to DAQmx Read can't be interrupted gracefully from the outside.  Once you make the call, you have to wait for it to finish.

 

Presently, you've given the call an infinite timeout (this is the special meaning of the -1 value).  It can't return until you generate the triggering conditions that allow the acquisition to finish.

 

A relatively easy workaround would go like this:

- put another while loop inside the existing one

- put your stop button in it

- put a short wait function in it too, let's say 100 msec

- query a DAQmx Read property node for "Available Samples Per Channel"

- terminate this inner loop when the stop button becomes True or when all your desired samples are available

- after the loop, skip the call to DAQmx Read if it was the Stop button's value that terminated the loop

 

I had a little time to tidy up the code, make the mods I mentioned, and back-save to LV 2013.  See attached.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 4 of 8
(2,509 Views)

Change your mechanisms of UI from "Latch when release" to be "Latch when press".

This will help.

please set this as ANSWER or KUDO this post, if it help you.


0 Kudos
Message 5 of 8
(2,500 Views)

Hi Kevin,

 

This is really a delicate solution! It works!

 

Curious what the Wait Function does.

 

Thanks!

0 Kudos
Message 6 of 8
(2,494 Views)

Tried it but didn't help. Thank you for your reply though!

0 Kudos
Message 7 of 8
(2,493 Views)
Solution
Accepted by LabLearning

The Wait function is just to avoid burning CPU unnecessarily.  No need to query the task or the Stop button thousands of times a second.  100 msec was chosen as a value that's pretty much imperceptible to a human user.  It'll still *seem* like an instantaneous stop.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 8 of 8
(2,479 Views)