LabVIEW
Can I use a global variable to stop a while loop in a subvi?
@vitoi wrote:
sholm,
A global variable is perfect for your application - it works and it's simple.
Even if it does work if implemented correctly (and thers no garuntee It has been implemented correctly since the OP is asking) The notifieris vastly easier to scale to a coordinated exit command when discrete state based clean-up routines get into the requirements. Perhaps the OP's code will never need expansion- But if sholm learns how and why- there are positions where such skill is rewarded.
@sholm wrote:
I have Labview 2010 SP1 installed, so it's not letting me look at the examples. I tried using a notifier but have the same problem as with the global variable - i never get the change at the subvi once inside the while loop. I will download 2011 tonight.
You'll need to read the variable inside the loop, else you'll only ever read it once.
Good ways to stop sub-vi's:
- Global variable, just be careful and try to only have 1 writer is possible
- Notifiers
- Events (my favorite when system gets larger)
/Y
Hi Vito,
Certainly you have some valid points. I actually find notifiers to be just as simple as globals, probably because I use them all the time. I also find that they preserve dataflow (I pretty much never name them -- you are quite right in that if you use a named notifier, you won't get the dataflow advantage, which is why I use the connector pane to transmit the reference). I don't think "the additional clutter", as you refer to it, increases the chances of mistakes -- by contrast, you can see where the notifier reference is going, which to me would actually decrease the likelihood of mistakes. Finding the writer(s) and readers of a global can be a major challenge, precisely because there are no wires (clutter?) leading to them. That makes code much more difficult to debug.
One advantage that a notifier has over a global is actually illustrated in this thread. The OP's global was set to "latch when pushed". This can -- and apparently did -- lead to a condition where the global's readers didn't register the change to "T", since it was momentary. By the time the global was read, it had returned to a "F" value...and so none of the subVIs stopped.
This won't happen if you use a notifier. The boolean won't return to a "F" state until it has been read by the notifier. The notifier will then transmit the "T" state to all its listeners, and the subVIs will stop...i.e. things will work as expected, even if the button is set to a latch action. To me, this is a pretty big advantage...and a more reliable way of doing things.
So...a notifier will handle either a "latch" action or a "switch" action in a reliable way, whereas a global will not. Notifiers use dataflow, which allows you to see where the reference is going, whereas globals do not.
I agree that you have some valid points, such as needing to put a timeout on the "Wait on notifier" function so that your loop will continue to execute, ideally only having a single writer, etc...nonetheless, I still find notifiers to be more reliable, a better fit with the paradigm of dataflow, and more scalable for large applications.
Shall we agree to disagree? 
@DianeS wrote:
Hi Vito,
Certainly you have some valid points. I actually find notifiers to be just as simple as globals, probably because I use them all the time. I also find that they preserve dataflow (I pretty much never name them -- you are quite right in that if you use a named notifier, you won't get the dataflow advantage, which is why I use the connector pane to transmit the reference). I don't think "the additional clutter", as you refer to it, increases the chances of mistakes -- by contrast, you can see where the notifier reference is going, which to me would actually decrease the likelihood of mistakes. Finding the writer(s) and readers of a global can be a major challenge, precisely because there are no wires (clutter?) leading to them. That makes code much more difficult to debug.
One advantage that a notifier has over a global is actually illustrated in this thread. The OP's global was set to "latch when pushed". This can -- and apparently did -- lead to a condition where the global's readers didn't register the change to "T", since it was momentary. By the time the global was read, it had returned to a "F" value...and so none of the subVIs stopped.
This won't happen if you use a notifier. The boolean won't return to a "F" state until it has been read by the notifier. The notifier will then transmit the "T" state to all its listeners, and the subVIs will stop...i.e. things will work as expected, even if the button is set to a latch action. To me, this is a pretty big advantage...and a more reliable way of doing things.
So...a notifier will handle either a "latch" action or a "switch" action in a reliable way, whereas a global will not. Notifiers use dataflow, which allows you to see where the reference is going, whereas globals do not.
I agree that you have some valid points, such as needing to put a timeout on the "Wait on notifier" function so that your loop will continue to execute, ideally only having a single writer, etc...nonetheless, I still find notifiers to be more reliable, a better fit with the paradigm of dataflow, and more scalable for large applications.
Shall we agree to disagree?
I rarely use FGV but often use Action Engines almost exclusivly in wrappers.
FGV have the same issue of race conditions as globals and locals.
A stop AE could have a stop method that does will set the run boolean false and the Run method would first check the sate of that boolean before forcing it true.
When wrapped-up in a proper wrapper the error cluster will enforce data flow.
Trouble shooting is eased by the wrapper since search on the "Stop wrapper" will show every place the AE is called with a Stop method. Doing the same with notifiers the best you can do search on the function for the notifer and search through all of the places it is used. Sure you could wrap-up the notifer in a wrapper.
the other plus for the AE is you can wathc it in execution highlighting probe etc. That type of troubleshooting can get diffcult when you wnt inside that Notifer ref. THe AE will alos let you determine the call chain at the time the AE is called so you can spot who is doing the wrong thing at the wrong time. Agan challenging with Notifiers.
Whre do Notifiers shine?
When you want to share the Stop but it has to be selective (stop some stuff but leave the rest going) where a AE would have to get smartened up to work. But then again... If you want to stop an RT Real-time loop running on another platform, notifiers will not work (the ref will not be valid on the other mahcine) but a AE accessed via VI-Server call by ref will work.
Where do I avoid AE's?
Whenevr a queue can move the data faster. i.e. large amounts of data coming in fast going only one place.
I may have gotten some of that wrong so question if it sounds wrong.
Ben
