LabVIEW
emergency button during time delay
Hi Laurent,
you wildly mix (unwired) terminals, "value" property nodes and local variables - WHY?
Your vi will not work properly as long as you want to check the stop button in the event loop while locking the front panel while execution of the event structure!
You should separate front panel handling (i.e. event structure) and execution of (long lasting) measurements into their own loops, connected by message queues. This way you can always react to user interaction...
One more flaw: in your current implementation the "stop"-local is (probably) read before/at the start of the execution of the 20sec delay. You cannot stop the delay in between.
To break the 20sec delay you should create a while loop running 100 times waiting for 200msec. In each iteration you can check the stop button and end the while loop...
you wildly mix (unwired) terminals, "value" property nodes and local variables - WHY?
Your vi will not work properly as long as you want to check the stop button in the event loop while locking the front panel while execution of the event structure!
You should separate front panel handling (i.e. event structure) and execution of (long lasting) measurements into their own loops, connected by message queues. This way you can always react to user interaction...
One more flaw: in your current implementation the "stop"-local is (probably) read before/at the start of the execution of the 20sec delay. You cannot stop the delay in between.
To break the 20sec delay you should create a while loop running 100 times waiting for 200msec. In each iteration you can check the stop button and end the while loop...
Message Edited by GerdW on 09-18-2007 09:52 AM
There is one very ellegant way to do this that you can easily include in any Producer/Consumer framework (and derived architectures!). Here is a screenshot of the "schematics" of the solution:
hope this helps,
Norbert B.
hope this helps,
Norbert B.
Message Edited by Norbert B on 09-18-2007 03:08 AM
Hi Laurent,
it is often said in this forum not to execute time- consuming code inside an event case. This can cause the user interface not to behave as expected (e.g. no reaction on mouseclicks at all). The other thing is the design of the state "signal RF ON", which has a time delay of 20 secs. In this time the program can't react on your button inputs. One soution could be, to add another state, let's say "keep RF ON", loop this case 1000 times with 20ms delay and every loop count the button is polled.
It could look like this:
Hope this helps,
greets, Dave
it is often said in this forum not to execute time- consuming code inside an event case. This can cause the user interface not to behave as expected (e.g. no reaction on mouseclicks at all). The other thing is the design of the state "signal RF ON", which has a time delay of 20 secs. In this time the program can't react on your button inputs. One soution could be, to add another state, let's say "keep RF ON", loop this case 1000 times with 20ms delay and every loop count the button is polled.
It could look like this:
Hope this helps,
greets, Dave
P.S. to examine the execution of your program use the little lightbulb from the button bar and activate in the option dialog at the "debugging"- page "Show data flow..." and "Auto probe during...". This often give you a good impression, how the program works.
Message Edited by daveTW on 09-18-2007 10:24 AM
Hi Laurent,
you should:
- rtfm
- look at the LabView examples on (message) queues
- look here in the forum on "queues" or "master-slave"
you should:
- rtfm
- look at the LabView examples on (message) queues
- look here in the forum on "queues" or "master-slave"
