Tie Stop Terminal of a While Loop to a different Loop

[FlamingYawn]

How often are your main while loops designed to stop together?  There are numerous ways to do this, most of them painful.  Wouldn't it be nice to be able to set the stop condition for a loop to stop when another loop stops?

 

               Current                                                   Proposed

[tst]

I don't like this for a number of reasons (such as the dependence on loop names) and there are pretty simple alternatives.

For example, here's a simple VI with 2 inputs (and you can see what its icon looks like):

The first call (or the Reset input) resets the flag and any call in which Stop is T will raise the flag. If you place this VI before the stop terminal of each loop, it will affect all of them. And one other nice feature is that this allows you to choose the stop condition in any loop.

Incidentally, this is just a simple example. There are more complex ones where you can create groups of loops by name, etc.

[muks]

Intresting idea......

[Mark_Yedinak]

I don't like this idea. I think it should be the programmer's responsibility to explicitly control their application. By adding shortcuts like this I can easily see folks new to LabVIEW heavily relying on this crutch and not spend enough time thinking about the best ways to control parallel tasks such as using notifiers/queues or some more generic message passing scheme.

[FlamingYawn]

LabVIEW is all about removing "artificial complexity".  Most applications stop all loops with a single user action (stop button, file>>exit, or red x).  So why not have a simple way to handle this common use case?  If this is what you want to do, then why add overly complex clutter such as notifiers, queues, the example above, local variables, or any other method?  How is simplicity a "crutch"?

[Tom_Hawkins]

I'm all for reducing complexity but I don't think this idea does that - instead it creates a 'behind the scenes' solution to a limited problem. If your use case is the simple one that one stop button should stop more than one loop, what's wrong with a local variable - it's one of the simplest LabVIEW concepts and takes next to no time to wire up. If you are doing anything more complicated than that then you need a more sophisticated solution anyway. Should the data acquisition loop keep running until the UI loop has asked the user whether they want to save the data collected so far? Should the UI loop keep running until the data acquisition loop has shut everything down and exited, or the file I/O loop has finished writing all data and closed the file? There's no one-size-fits-all solution.

I don't know exactly what you mean by 'most applications stop all loops with a single user action'. If you mean commercial applications, I think you'll find most of them actually trap the window close or File>Exit event and do some fairly complex decision making about what to do next - does the user need to be asked about unsaved changes, do open files need to be closed, and so on.

[AristosQueue (NI)]

> instead it creates a 'behind the scenes' solution to a limited problem.

Yeah, but it is a *really common* limited problem. 

I don't like this particular solution, but I kudos'd it because I think that "something like this" would be a good idea.

[tst]

> I think that "something like this" would be a good idea

How about shipping a VI along the lines of the VI I posted as part of vi.lib? This type of VI has an additional advantage (which some might consider a disadvantage) in that every loop calling using it can trigger the stop condition. You simply place the VI on the boolean going into the stop terminal.

[AristosQueue (NI)]

Tst: My problem with your posted VI is there's no easy way to clone that VI -- if I have two top-level VIs in my system and both of them have dual loops, I need may want one stop condition for all four loops or I may want a stop condition for each top-level VI. If someone else used that subVI in their module and it happened to run along side my module, there would be issues. 

Because this issue frustrated me so much while prepping for the Certified LabVIEW Developer exam, I've given it a lot of thought. I don't have any good answers, but I can tell you the aspects of a solution that I'd like to see. I would want some syntax element that is

* easy to use when loops are on the same diagram

* looks/feels/reads the same when loops are not on the same diagram, though it may take more editor clicks to set this up

* can be restricted such that it doesn't become a global VI that just anyone can set -- I need to be able to say "these loops on these diagrams, and these ONLY"

* Works with "Find Instances"

* has a concept of "Master Loop" so that one and only one loop is capable of saying "I am the one that decides when we stop". If two loops are equals, the mechanism should be reconfigurable so that multiple loops can issue the stop instruction, but I'd recommend that be the non-default configuration. Even when there are multiple equal loops, there may still be a third loop that may be listening for the stop command but not able to issue the stop command. By having a clear master, the mechanism reads like dataflow (this bit originates in Loop 1 and flows to loops 2, 3, etc).

* know how to handle restarting. In other words, suppose VI A has an outer loop and an inner loop. The inner loop is the master loop. On VI B, there's another loop listening for that stop. I would like the mechanism to guarantee that the loop in VI B got the command to "stop" before the inner loop executed again (which, presumably, would reset the stop signal). Tst's suggested VI has a problem with this use case. 

* [optional] can communicate a reason for the stop -- perhaps we might use this mechanism to cut down on the Merge Error calls after parallel loops?

*should be easy to use, obvious to read and feel like a natural part of a LabVIEW diagram

[tst]

You are correct that the VI I posted is very simplistic (that was on purpose) and lacks a lot of functionality.

The points you brought up are generally correct, but because the architectures for different programs are often different, I do find myself sometimes re-solving this problem on an ad-hoc basis (which isn't necessarily bad, even though it's annoying).