Why not using LOCALs in LOOPs ?

[Ela]

Why avoiding LOCALs in LOOPs? (I saw some posts that suggest it).
In my case, I have one button (Stop) and I want to be able to stop the application along 3 different independent loops. How can I do it without locals ?
Thanks

[MichaelAivaliotis]

The situation you describe is a good one for using locals.

[megmond]

If you really want to do it without locals, you could try using a semaphore, queue or one of the other similar elements that are available (see Advanced -> Synchronization on the Functions palette).

Doubtful that this is more efficient than your locals though, but in a lot of other cases these functions are quite useful.

[Rob Cole]

The reason that most will give to avoid using locals in parallel loops is that you can not predict which loop will execute in what order. So if one loop is writing to the variable, you do not know if the value was written before or after another loop reads/writes to the variable.

In this case, where you are just reading the variables, I would use the local variables. Just watch that the "latch" function for a button is the default and is incompatible with using local variables. If you want to simulate the latch function, use the mode, "Switch When Pressed" and then turn off the button once all loops have been exited.

I know that it is controversial here, but this is a good case for a sequence. Put all of the parallel loops in the first frame and the "turn
off button" function in the next frame. Then ALL loops get a chance to read the stop button before it is turned off again.

Rob

[Labviewguru]

Sequence Frames???

I would suggest that, instead of sequence frames, a single sequence frame be used, and the output of all the loops be wired to the sequence frame, and the value of the stop be written back to true using that frame. As a rule, I try to avoid hiding code by sequences. Cases are an exception becuase they offer a choice, a path the user can follow through the code (though I have asked NI to allow all cases to be shown on the diagram...)

[Rob Cole]

When you print the panel, all cases are shown. Or do you not want to print all the panels? Of course, if there are multiple case structures then the printout itself can get confusing (and take a lot of paper).

Rob

[MichaelAivaliotis]

The use of a sequence you describe here is ok but I think the goal here is to initialize the local to a known state BEFORE you start reading it in the loops. After the VI has stopped there is no need to set the local false again. Cleanup is usually a waste of time since the VI is stopped anyway. Also for initializing a single local just follow the example attached...

[Rob Cole]

Except that, in this case, a "stop" button is being read. Since it is a boolean, it is already "initialized". I would prefer to turn off the button when the loops are completed so that I could just hit the "run" button again to test the program. Yes, one could initialize the button at the start of the program or loops, but this could be confusing to a user - starting a program with the "stop" button already set does not look good.

Rob

[MichaelAivaliotis]

Well, in user interface situations i don't open the front panel until the screen has been cleared or initialized so this doesn't come into play, but I can see your point.

Another scenario to consider is when (as a developer) you are debugging the program, there are many situations where you have to break-out of your program (stop button or control-period). In this case having the program reset itself upon start-up is usefull.

[JeanPierre]

For the purpose of stopping parallel loops across a diagram or VIs I have created a loop utility based on a notifier. It avoids the use of any local or global and thus allows the use of latch boolean buttons. See my web page LabVIEW Bestiary. Enjoy.
Jean-Pierre