Multifaceted elapsed time control, reset, pause, etc dilemma.

[Ralph@NES]

Hello all,

In the past week or so I've been challenged to improve upon my existing (only two week old) VI for taking temperature readings, writing an output file, and controlling physical relays via NI-SWITCH.

Attached is the VI in its' current state of development.  In lieu of the thermocouple data from the DAQ assistant, I've got a random structure generating the correct number of signals (24) and the NI-SWITCH outputs have been replaced with boolean LED indicators so this VI can be run on any computer sans hardware.

On the front panel you'll see a checkbox for 'start/stop timer' and a boolean button for 'reset timer' on each bank of 4 signal displays.  This does a handy job of starting/stopping the timer and resetting, but I have an odd quirk that I need to work in;  The timer, at this point, when re-enabled (checked to restart) will pick up at actual elapsed time since it was initially started.  I need for the time to PAUSE at a point when it's unchecked, and then restart at that same time when re-checked--Not at absolute time since it was first checked/started.

I've found a couple threads and VI's dealing with pausing timers, but none of them worked in the 'reset to zero' function as mine has, and I'm also unsure how to make the setup work with my loop.

I've only been on labview for about three weeks now, so please be kind if I'm missing something obvious.  I'm fairly certain my elapsed time express VI's will have to go away, but what to replace it with I have no clue.

(BTW, the huge case structure for the 'write to file' vi is since it will soon be replaced with an updated write to spreadsheet setup)

[JLS]

Hello,

It sounds like you're looking for a "stopwatch" VI.  I have attached such a VI, as well as an example which uses it.  The stopwatch VI use shift registers, which is a structure which can be added to loops in labview to store data across iterations.  In this case, I have used the shift registers in an uninitialized form - that is, they are not set to a value outside of the loop.  Using them in this way will cause the data in the shift register to be stored across instances/calls to the subVI - the subVI can remember information about the last time it was called.  You'll notice that the stopwatch VI uses a while loop, but has a constant wired to the loop condition so that it only ever runs once - the while loop is there only to get the shift register.  Using an uninitialized shift register in a subVI to retain values across distinct instances/calls to the subVI is often called a functional global variable or a labview 2 global.  Take a look at the stopwatch VI to see this, but I think it, along with the example VI that shows how to use it, will give you the functionality you are looking for.

Best Regards,

JLS

[Ralph@NES]

I like that functionality very much.

Two questions:

1.  Is there any way to format the elapsed time into HH:MM:SS?

2.  The enum that controls the cases...  Is there any way to make that a more user friendly selector?  3 position switch or something?  I'm afraid my guys will be hitting reset when what the need to do is pause, etc...  Thanks very much for your help so far!

[Ralph@NES]

Oh yes, and it also needs to be able to be 'shut off' with a boolean input as well!  Case structure perhaps?

[Ralph@NES]

Clarifying that--it needs to be PAUSED with a boolean condition; Not shut off.  I can kill the loop with a boolean but I need to enact the pause state somehow with a local variable (when a temperature indicator goes above a certain value, it would pause until user input would restart it).

[johnsold]

Ralph, AKA Confused,

Here is a demo showing how to use either Tick Count or Time Of Day for elapsed time. It also shows the use of an Enum or Radio Buttons for the control. In addition there is a separate Pause boolean. Perhaps this will help reduce the confusion. The Resume conditons could use local variables or property nodes to reset the control to the Run position, but I did not include that.

Lynn

[Ralph@NES]

That's a nice multifaceted control and I like the radio button functionality, however I'm not sure how it would further my 'pause until resumed by operator input' issue.  If pausing with a boolean, the timer restarts as soon as the boolean condition changes.  I must be able to have the following functionalities:

1.  Start timing at operator input (checkbox, etc)

2.  Time until either an operator pauses/resets/stops it, OR a boolean condition is passed indicating that a temperature limit was exceeded, and, in either case:

3.  Remain in pause state until an operator has decided to restart it.

That's the kicker that's really got me confused.   The method to go about keeping it paused until someone decides to restart it.

Background:

I've got some bearings being spun by electric motors.  The bearings have thermocouples on them.  We're timing an endurance test on the bearings, and temperature spikes are what we use to shut the system down before catastrophic failure when we're not here monitoring.  The temperature rises above a preset limit, click, relay shuts that motor off and a boolean condition pauses the timer on the VI.  As those thermocouples cool off, the boolean condition changes back to 'false' or whichever but the motor is not restarted.  I need that timer to pause at the time the motor is shut off and not restart until someone tells it to.  If the timer is restarting, it's losing our 'total runtime' data and compromising test integrity.

I appreciate all your input guys!  I just need to get around this one element of functionality and the system will be user friendly enough to be used by general personnel on a daily basis.  Thanks for 'bearing' with me and any ideas are welcome!

[johnsold]

Ralph,

I think a state machine would do what you want. Check the examples and search the Forum for more details. Inside each state a decision is made about the next state. From the Run state several conditions would be OR'ed together to select the Pause state. From the Pause state only the specified Operator action would allow return to the Run state. You could also have an Overtemperature Error state which might be different from the Operator selected Pause state. Stae machines cna be fairly simple or as sophisticted as you need them to be.

Lynn

[Ralph@NES]

Just started looking at state machines and my head is swimming.

[Ralph@NES]

Here's the structure I'm fond of (has the three states I need user controlled; Start, Pause, Reset in a handy 3-position slider).  I'd like to incorporate this into a state machine that has a boolean input for the 'fatal error' which would enable a fourth state, another 'pause' if you will, that would not restart unless a button was pressed AND the boolean condition was reset to false.

Can someone give me some detailed guidance?  My back is to the wall and I've been chipping away at the big picture for over a month now.  I really need to get this implemented and don't have the time left to truly learn shift registers and the other things needed for a state machine...  Help...  Please....