01-08-2021 07:10 PM
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!
Solved! Go to Solution.
01-09-2021 06:58 AM
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.
01-09-2021 07:45 PM
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?
01-10-2021 06:49 AM
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
01-10-2021 09:31 AM
01-10-2021 09:51 AM
Hi Kevin,
This is really a delicate solution! It works!
Curious what the Wait Function does.
Thanks!
01-10-2021 09:53 AM
Tried it but didn't help. Thank you for your reply though!
01-10-2021 06:32 PM
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