What is the preferred way to stop multiple loops?

[Norbert_B]

Recommended methods are multiple depending on the architecture of your application. This can be easily seen in the posts which have been written up till now.

I just want to add two things:

a) You mentioned valid methods of stopping an application. But you also mentioned one i would never recommend: Variables (local or global does not matter!). This is ok for very small two loopp architectures but even there, it can lead to bad issues. So this is not recommended. 

b) Regarding the posts of shutting down using the queue/notifier release (closing consumer using the error cluster). I know that this is common in NI examples and the frameworks. But i would not do it in this way since you loose all queue elements which are currently enqueued. So the consumer sometimes "stops out of context". Therefore i prefer sending a "stop command" using the queue and releasing the queue in the consumer. But i assume that this is more a personal reference.....

Norbert 

[F._Schubert]

My code is mainly based on the arcitecture I presented in this Community nugget. You will find the Exit discussed at the very beginning.

If I use a queue based P/C design, I also use the error wire to close the consumer. But there are several issues with this:

* Loss of data: I poll the queue for elements and only release it when it is empty (or on a timeout for the case the consumer stopped due to an error)

* If you use multiple staged P/C, stopping all loops if there is an error in one of them takes some extra effort, especially if you want to preserve the error code.

I was planning  to share some tricks I developedas a Community nugget, but didn't get the time to do so.

Felix 

[aeastet]

I always ues the event based commands to shutdown. This way I can send different commands to dirrfent loops to shut everything down properly. I am sure that you can do the same thing with a queued system too.

[Broken_Arrow]

One thing that shouldn't be a matter of opinion - using the STOP function (a programmatic abort) or hitting the Abort button. How many times have you seen this in "real" programs?

[johnsold]

Nickerbocker,

Jeff and Diane expressed very well the reasons for using typedef enums.  I often find that I need to add a command or status message to those already defined for my queues and using typedefed enums simplifies things.

Lynn 

[Bob_Schor]

What I've done is to create a "Functional Global" (or a VIG) called "Global Stop", whose icon is a Stop sign, and "sit" it on the error line near the loop exit.  Besides the error line, it has one other input (called "User Stop") and one other output (called Stop or Error).  Set up an uninitialized boolean shift register (which will have the default False value) and wire it to the Stop/Error output.  If the Error line indicates an error, set Stop/Error true; if User Stop is true, set Stop/Error true.

Now place this VI on the error line of all of your loops.  If you wire a "stop" to any of them, the VI will "latch" it, and when each loop hits it, a True output (wired to the Stop conditional of the loop) will stop the loop.  It also has the effect of shutting down all of the loops if an error occurs on any of the error lines on which it sits.  By making the icon a stylized Stop sign (I think mine has a big Question Mark in it), it has mnemonic value, as well.

Bob Schor

[hecmar.arreola]

---

Jeff Bohrer wrote:

What is the purpose of the type-def'ed enum?  I'm not sure I understand why you would want a simple U16 value type-def'ed.  I don't see the bennefit in doing that.  Maybe if the properties (like the strings[] one) of the enum automatically updated to controls and constants that reference the type-def.  

Message Edited by Nickerbocker on 12-07-2009 04:59 PM

---

Whoa!

Create a Strict Type def of an enum.

Add an item to it

Select File: Apply changes:

All controls, indicators and CONSTANTS in memory are updated!

Any that are not in memory will * when you open them (since they refer to the type def) and saving updates them as well.

A Type def'd enum is pretty darn powerful

---

How interesting.  That does work.  Sorry, I was mistaken.  However, it doesn't appear to work with Text Rings, only Enums.  So let me update my opinion: Not all properties in a type def control will autoupdate to controls that reference the type def.

[JÞB]

---

Nickerbocker wrote:

How interesting.  That does work.  Sorry, I was mistaken.  However, it doesn't appear to work with Text Rings, only Enums.  So let me update my opinion: Not all properties in a type def control will autoupdate to controls that reference the type def.

---

Don't discount the text ring either...While it is a bit more problematic to update I have several uses for them that make it indespensable.  For instance I use a type def Text Ring as a Result element in my test actions.  Since Text Rings allow non-sequential values I pass the string as the result (e.g. Fail, Pass, Done.. etc... ) and the value as the background color (0xFF0000, 0x00FF00, 0x0000FF etc...  )  Makes the UI pretty with reuaseable code between projects. 

[blawson]

---

Nickerbocker wrote:

---

How interesting.  That does work.  Sorry, I was mistaken.  However, it doesn't appear to work with Text Rings, only Enums.  So let me update my opinion: Not all properties in a type def control will autoupdate to controls that reference the type def.

---

more to the point: changing a type defined control updates the values of the instances' data type.  So the strings of an enum will update, the strings of a ring control's item names will not.  (This is from the first paragraph of the help file.).  Some things will not: labels, default values, data ranges, etc.  My point is that what does and doesn't update is clearly defined and not hard to research for a particular control type (search for "data type" and the control name).

back on topic, though: I've stopped a queued (consumer) loop before by wrapping the dequeue element function in a subVI that handled the 1122 error case to select an enum for the main state machine.  Works well, doesn't put extra error cases out on the main VI, etc.

[Mark_Yedinak]

I prefer to use an explicit command sent via a queue. As others have indicated this gives me the flexibility to issue different types of messages such as a "Stop", "Exit" or "Error" event. This allows different processing to occur depending on the event.