How do we link multiple stop buttons to make one master stop button?

[DGCH]

I think I'm just confused by the "Wait (ms)" in the example.  I am running a Timed Loop for my master notification loop, so I don't want to add a "Wait (ms)" to it.  Are you saying that "Wait on Notification" will not delay the slave loop while waiting for a new notification?  If the slave loop will still run its other functions as fast as possible but will only update the notification when the wait period is over, then I can use "Wait on Notification" instead of "Get Notifier Status."  Certainly open to suggestions, as I'm new to notifiers!

[SteveChandler]

Also make sure you wire something reasonable to the wait on notification timeout. If you wire 200 then your loop will never execute faster than 200mS. That is fine if your loop speed needs to be throttled down anyway. If it needs to be fast then wire a 0 to it so it returns if there is no new notification. Notifiers are the way to go. Since you are new you might want to check out this micronugget I wrote about stopping multiple loops. It uses a functional global which is something you should definately learn about.

One more thing. Using a notifier even with a 0 for the timeout will slow your loop. If you really need speed then use a local or global variable.

[DGCH]

Sorry, Steve, still confused about the previous question: Will "Wait on Notification" pause a loop it is contained within until it receives a notification or times out, whichever comes first?

Additional question: What is the advantage to using "Wait on Notification" over "Get Notifier Status"?

I will look more closely at your micro nugget, especially when I move to using multiple VIs.

Thanks!

[nathand]

The Wait (ms) in the upper loop of the example is to prevent that loop from spinning as fast as possible.  A Timed Loop is fine too, but they have some disadvantages.  A timed loop is a single separate thread, so all actions inside it execute sequentially even if they have no data dependencies.  In a standard while loop, functions contained in it can execute in parallel.

Your choice of phrasing for the first post was confusing; I think I better understand now what you are asking.

---

@DGCH wrote:

Sorry, Steve, still confused about the previous question: Will "Wait on Notification" pause a loop it is contained within until it receives a notification or times out, whichever comes first?

Additional question: What is the advantage to using "Wait on Notification" over "Get Notifier Status"?

---

Wait on Notification will prevent a loop from proceeding to the next iteration until either a new notification or a timeout.  If you don't want to wait, set the timeout to 0 and do not use the "Ignore Previous" input (which would prevent you from ever receiving a notification).

The advantage to Wait on Notification is specifically that it does wait, so that you do not need to poll to find out when there is an update.  It signals that new data is available.  If you only intend to use Get Notifier Status, you might as well use a global variable (I wonder what the speed comparison is, I suspect they're both fast).

[SteveChandler]

The wait on notification will block until a notification is received or there is a timeout, whicever comes first. By default it will never time out so your loop will iterate once then not do anything until told to stop There is a boolean output from wait on notification that tells if it timed out.

As for your second question, the best way to think about it is to think about reading a local variable. You can only tell if someone wrote a different value from the one you last read. That is, if it is a boolean and you read a false, is this the same false you just read or did someone write two falses in a row? There is no way to tell. So wait on notification will tell you every time someone writes a false. Notifier Status is like reading that local variable. You don't know if it is two falses in a row or three or just one. This is the problem of "stale data".

[SteveChandler]

---

@nathand wrote:

If you only intend to use Get Notifier Status, you might as well use a global variable (I wonder what the speed comparison is, I suspect they're both fast).

---

I just tested this. I looked at the iteration count of three loops after one minute. One loop with nothing but wait on notification with timeout set to 0, a loop with nothing but a local wired to stop, and a third with nothing but a global wired to stop.

The results are as I suspected:

• notifier 13,799,248
• local 845,188,073
• global 844,288,373

I didn't check with the functional global but I do know that globals drastically outperform them. In fact I have created some "functional globals" that don't use shift registers but instead use globals.

Edit: Anyone notice the weird coincidence with the local and global results? They both end with 88073!

[nathand]

Just for fun, you might do a fourth comparison with Get Notifier Status instead of Wait on Notification.  I assume (but don't know for certain) that functions with a timeout operate like the Wait (ms) function, in that even if you wire 0 they still give the scheduler a chance to run some other task.  Get Notifier Status does not do this so I would expect that it will run much faster.  It would also be interesting to see if Get Notifier Status is affected by whether a notification has been sent.

[SteveChandler]

You are right, it is faster.

But the local still blows away either of these. I have never considered using notifier status instead of wait on notification for something like this. But if I were making a decision based on high performance I would not use notifiers. Queues are just as bad. I will stick with a global variable to pass data between loops that need all the iterations I can give them (rare by the way). They are about the same speed as a local but my loops tend to be in different subVIs.

That said I don't want to scare anyone new to LabVIEW away from using notifiers! Globals have implications and should be used with caution and only when you really need the speed. Always put them in a library with the modules that need them and mark them private.

Here is the code. I did not try messing with the execution environment, priority or debug settings.

[SteveChandler]

Too late to edit but I did another experiment. Guess what? A local is (slightly) faster than a wire! I suspect they are really the same speed and the slight difference has to do with how the code happened to be compiled this time.

Also, nsimmon2, I am sorry for hijacking your thread, but I think your question was answered. Use a notifier. Do not be encouraged to use locals or globals by any of this. For most applications notifiers are way faster than they need to be and are always a more robust solution.

And that abort thing in the diagram below? You never saw it. Don't think about using it. Using will cause all the side effects that all the drug commercials warn about combined plus all the ones they are covering up and even the ones they have not yet discovered. You have been warned.

[DGCH]

Thanks all for the explanations!  I will stick with Get Notifier Status for now and switch to a global variable if I need faster iterations (unlikely).