How to stop a timer loop that is inside an event case?

[Jeff in Pleasanton]

My user interface includes a mm:ss "dwell timer" that updates once per second.  The timer starts at 00:00 in response to a TPC-2006 virtual "Dwell Mode" button push and stops incrementing when the operator pushes any other virtual button.  I want to put the timer loop in the "PDA-Dwell value change" event case so that the timer loop executes only in Dwell Mode, but I don't know how to handle stopping the loop when the operator presses another button.

The TPC-2006 vi is attached.

Suggestions?

Message Edited by Jeff in Pleasanton on 06-16-2006 10:34 AM

[jasonhill]

I am thinking that it would be easier to handle it in the case structure rather than have a separate timing loop.  With all the local variables and three independant while loops, you are asking for a race condition.  I don't know much about the PDA functions.  Do you have access to the timing vi's?  I think it would be easier to Get Date/Time and subtract some start time from it rather than maintain your own custom timer.

[Jeff in Pleasanton]

I'd love a single loop, but the PDA is so slow that the user interface response time was unacceptable with Tx/Rx, message encoding/decoding, and the dwell timer in one loop.  The best response to date has been achieved with independent TX and Rx loops.  The whole point of my question is to eliminate the indendent timer loop.

I gave up trying to get the PDA to format a clock-based timer display as mm:ss.  Converting an incrementing integer to a string gave me the requried display format.

I've replaced the division-based (quotient/remainder) timer scheme with a pair of incrementing integers (one for minutes and one for seconds) and some simple Boolean compares.  I'm hoping this will cut processor cycles.

[altenbach]

Why don't you use the timeout case instead?

I also cleaned up a few other things.

1. index array is resizeable so you need only two instances.
2. in the middle right case structure, you have30+ local variables, duplicated in each case. You need exactly (...drumroll...) none!
3. Use shift registers instead of hidden FP controls+locals to keep state information.

I am sure the timeout stuff needs a few tweaks to achieve the desired functionality. I cannot test, because I don't have your hardware. The attached should get you started.

[Jeff in Pleasanton]

Holy shorthand, Batman!  Thanks!  You used blocks I that wanted but couldn't find (or, like the Index Array, found but didn't think were going to do what I wanted).  Once I digest everything you've modified I may be ready for 2nd semester LabVIEW.

This forum rocks!

[altenbach]

Just a bit more cleanup and tips 😉 . You can eliminate a few logical_NOTs by inverting some inputs to compound nodes (they will show with a small circle). We also need to bypass the upper TCP node whenever a timeout occurred. For completeness, you should close the TCP connections at the end of the program. In the lower TCP, you might also want to ignore the output whenever a timeout occured and thus no new data has arrived.

See attached.