Stop worker loop in CMH design pattern

[Quiztus2]

I was wondering if there is a smarter solution to stop a heavy lifting loop in a cmh state machine.

So far the best solution I can think of is polling the stop button every or maybe every e.g. 100th iteration in the working loop.

I can imagine that there is a smarter solution incorporating the channeled messenges sent by the event handling loop.

Any suggestions?

[billko]

Instead of doing stuff in that FOR loop that makes it difficult to stop in the middle, why not make a state that keeps calling itself until it's done?  That way you can easily encode an exit message in case of emergency.  It takes a bit more "imagination" to do, but if you understand state machines already, you should be able to easily handle this.

[Bob_Schor]

Yes, I completely agree with @billko.  I started using the CMH before there was a CMH module (in fact, I may have invented this term, for all I know).  I wrote two sub-VI, "Send Msg" (which takes an Enum that I call "State" and a variant that I call Data, bundles them into a Cluster I call "Message", sends it to a Write Messenger Channel, and outputs the Channel Ref) and Receive Msg (which does the opposite, inputs the Messenger Channel, reads the Message, unbundles it, and outputs "State" and "Data").  The Event Loop mostly looks at Front Panel button presses, and uses them to "Start" or "Stop" processes.

The main Loop is the State Machine.  It has a While Loop inside of which there is a Case Statement.  It expects a Messenger Channel to come in and go to the (only) Receive Msg VI, whose State output goes to the Case Selector.  I usually have a Send Msg sitting just to the left of the State Machine sending in the "Init" State.  At the end of each State, the State Machine needs to decide what to do next.  Sometimes, it is "Do nothing, wait for another Button Press", so you "do nothing".  Other times, it is "OK, you've done A, now do B", so you have a Send Msg VI with "B" as the next State going out of the State Machine and looping around back to the beginning. 

Sometimes, it is "Keep doing the same thing unless it is time to do something else" (which is your situation).  Simple -- have a "Pause" button (and maybe a "Resume"?) on the Front Panel.  When Pause changes (do not make it "Latch" control, as you want to turn it On and Off), send the State Machine the Message "Do Pause", passing the Pause Boolean value as Data.  This will fire off the Do Pause State, which takes "Pause" and puts it in a Shift Register running along the top of your State Machine (you can also simply put  Pause in a Global Variable in the Event Loop, but that's not as much fun as having States interact).  Now you modify your "Looping" State to check for Pause being set -- if it is, you do not call the State again, in fact, you don't call anything (and therefore you "Pause").  How do you restart?  When Pause goes False, and is detected by the Event Loop, if can restart the Looping State (by calling it at the end of the Pause State if Pause is False, or if you are using Globals, call a "Resume" State if you need extra processing or simply call the formerly-running State.

It may sound complicated in words, but if you try diagramming it out (which is fairly simple to do), I think you'll quickly see the logic to this.  [I actually had a simple demo of this, but I misplaced it ...].

Bob Schor

[Quiztus2]

I exercised the idea of chunking the work into pieces and followed the path down where the worker  frame calls itself until its done.

If I press STOP, all remaining messages get read.

I am not super happy with this so far, but I will check how far one can get with this approach.

[Eric1977]

Can you upload your VI? Not only do we want to see what you've done, but forum members can send back suggestions to you via the VI with a slight naming change.

We can offer other things as well besides what you already have.