Interruptible timer

[RBalthazor]

I'm struggling to get to grips with a vi that does the following:

1. When a switch is turned 'on', a timer starts, measuring seconds.

2. After x seconds (x ~ tens of seconds), a local variable latches true and stays true indefinitely until the switch is turned 'off'; the timer can (probably should, for CPU cycles' sake, stop at this point).

3. When the switch is turned 'off' even if it is turned off before the x seconds has elapsed the timer stops (if it hasn't already) and the local variable, if true, becomes false.

I'm struggling with putting it all together - I can do all but the interrupting in mid-timing-sequence using a wait-ms vi, or I can use the elapsed time express vi with the interrupt but I can't figure out how to latch it at the end, and my vis are getting uncomfortably bloated and layered for what seems to me to be a simple task.

Any pointers gratefully appreciated.

[johnsold]

I am trying to understand exactly what you are trying to do. The part about the local variable is especially confusing. Local variables in LabVIEW are linked to a control or indicator and are not separate entities. Further, local variables are often used in such ways as to produce race conditions. Most experienced LV programmers rarely use locals, and then only under carefully controlled conditions.

Let me try to clarify what I think your design requirements are:
The front panel has a boolean control (A) which you refer to as a switch.
A numeric input (or constant) (x) defines the delay in seconds.
The output is a boolean (Y).

When A changes from False to True, start a timer.

When elapsed time is > X and A = T, stop timer and Y = T.

When a changes from T to F, regardless of elapsed time, stop time and Y = F.

Is this what you are asking?

What else is the program doing while the timer is running or while Y is True and the switch A is still True?

Lynn

[RBalthazor]

Your interpretation of the requirements is spot on.

The uber-program is monitoring and controlling (via a 6020E DAQPAD) a whole bunch of hardware.   It consists of two 'infinite' while-loops operating in parallel; one while-loop contains the hardware control set of booleans driving digital i/o driving external relays driving hardware, and the second while-loop contains a sequence interrogating various 6020 analogue-in and RS232 lines that do the hardware parameter monitoring.

My problem area is in the control side of things, and derives from the following "real world" requirements: valve V and pump P are both controlled via booleans (and right now are controlled independently).  valve V can only be opened if pump P has been operating continuously for > 30 seconds; pump P can be turned on and off at will, and if pump P is turned off when valve V is open, valve V must be closed immediately.

Hope this clarifies; thanks again!

[johnsold]

Here is a little Interruptible timer VI. It is for illustrative purposes. It probably would not work directly as a part of your larger program.

Your overall program description sounds like a good candidate for a Producer/Consumer state machine architecture. Put all the user interface into one loop with an event structure. It would send commands and receive data from the I/O loops you already have. Exchange data among the loops with queues or Action Engines. If you have time consuming calculations, save to file operations, or other things which might produce delays, an additional parallel loop for those might help.

Lynn

[RBalthazor]

Thank you - just what I was looking for, and far simpler than my spaghetti.

I will go take a look at the Producer/Consumer architecture examples - knowing the right keywords is half the battle.   Many thanks again.