LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Ending 3 parallel loops off one "Emergency Button"

I have been trying to figure out how to end all 3 of these loops with one user click on an "emergency stop" button. The emergency stop button event needs to cycle through several messages to safely shut down equipment. Then at the end all 3 loops need to end. I keep having one loop hang without closing.

 

My very tired brain has attempted to leave comments to ease understanding. Any help is appreciated.

0 Kudos
Message 1 of 3
(697 Views)

Two of your loops have this in them:

Kyle97330_0-1670017401779.png

Because of dataflow and the fact that this has zero input wires, it reads the Boolean immediately at the start of each loop, and not after it finishes a case.

 

So if your exit Boolean is set to True, the loop will only end at the end of the next completed loop instead of the current one.

 

As a general recommendation I would set it up so that your "Exit" case(s) in any given loop outputs a True constant to the Stop button and every other case uses the "use default if unwired" option to not stop the loop. 

 

I'd also set it up so that whatever code currently sets the Boolean to True, instead is set to send a message to one of those exit cases, possibly with a priority message (i.e. enqueue at opposite end, or generate user event with the optional input set to high priority).

Message 2 of 3
(666 Views)

Hello, CatDoe.  LabVIEW Giveth, and LabVIEW Taketh Away (but, fortunately, Asynchronous Channel Wires can "come to the rescue").

 

One of the great strengths of LabVIEW is that the principles of Data Flow programming allows and encourages programs to have loops running in parallel.  The problem then becomes getting them to stop in an orderly fashion.

 

You seem to be using the Queued Message Handler template (which I personally found too confusing, so I constructed a simpler Queued State Machine that I migrated to use Messenger Channel Wires when LabVIEW 2016 introduced this (wonderful) feature (I called this pattern a Channel Message Handler design).  Stopping then became quite simple:

  • The Event Loop processes the Stop Button (Value Changed) and Application Instance Close? events by generating a "Stop Main" Message to the Message Handler Loop, and also wiring a True to the Event Loop's While (so this stops the Event Loop).
  • The State Machine's "Stop Main" state is "carefully" coded to stop hardware that needs to be stopped (knowing that there might not be any more Events coming in).  It then calls its "Exit Main" final state.
  • "Exit Main" now shuts down all the other loops running in parallel.  "Just in case", it sends a "Stop" to the Event Loop (either by a Tag Channel that takes a Boolean in an otherwise empty 500 msec "Timeout" case and wires it to the Event While's Stop terminal, or uses an Event Messenger Tag to stop the Event Loop.  Note if it's already stopped, it doesn't matter.  To stop any other parallel loop, I usually use a Tag Channel Wire carries a three-state Enum I call "Wait-Run-Exit", where the Wait case is a Stall for, say, 100 ms (or whatever time seems appropriate), the Run case processes whatever the Loop is waiting for, with a Timeout if there are no data to process (so we don't get stuck "waiting to Run"), and an Exit that simply exits the parallel Loop.  One of my current routines has Wait-Run-Exit stopping 5 parallel loops.

Hope this gives you some ideas.

 

Bob Schor

 

 

 

Message 3 of 3
(620 Views)