Wait on noification does not seem to work when wiring "ignore previous"

[Joseph_Loo]

I am using the Wait on notification vi. Basicaly i have multiple VI waiting for a single event to occur in Diff_Data (runs continously). Once the event has occurred, I want the other vi to start running (they have a wait for the notiiction)once the notification is sent out. If I start the VI after the notification, they just wait for the notification regardless of the setting of "ignore pervious" in vi. The only way to get the vi to proceed is to stop and restart the Diff_Data vi. Is there a special requirement in ist operation?

How much resource would be required if I keep sending the notification out every second or so?

[tst]

Are you sure you're doing this correctly?
I just tried in 7.0 and had no problem - I ran the VI which sends a notifier, than I ran 2 other VIs which wait for the notifier and they both got it. Which version are you using?
Can you post an example (the simpler the better)?

A modern computer should have no problem with a notification sent every second.

[Joseph_Loo]

Try this example. there are 3 vi's Alarm_hold_Not, alarm_hold_Not-1, and operation_info. Start Alarm_Hold_Not followed by Operation_Info. You will see that Alarm_Hold_Not will stop running right after Operation_Info. Next run Alarm_Hold_Not-1. That vi will keep waiting for the notification even though Operation_Info is running. It will never receive the notification. This represents a problem when you build an application where multiple VI run. The order they come up and run is critical in the receiving of notification.

[tst]

I used 7.1 and ran Alarm_Hold_Not, then Operation_Info and the first VI stopped.
Then, I ran Alarm_Hold_Not-1 and it did recieved the notification and stopped immediately.
Then, I used the stop boolean to stop Operation_Info.

So, either this is bug in 7.1.1 or we're missing something. Personally, I don't work too much with notifiers, so I'm not sure. Try using Release Notifier.

[Johnner]

With 7.1.1 (Windows XP), I see the same thing tst does: Alarm_Hold_Not-1 stops immediately the first time it is run as long as the notifier was already sent by Operation_Info and Operation_Info is still running (i.e. the notifier object has not been garbage-collected).

My sequence:
1. Run Alarm_Hold_Not
2. Run Operation_Info (Alarm_Hold_Not stops)
3. Run Alarm_Hold_Not-1 (it stops immediately)
4. Run Alarm_Hold_Not-1 again (it waits on the notifier)

Joseph, can you double-check what you see with your example? What's your OS?

Regards,
John

[Joseph_Loo]

I can get it do what you say. It seems to be a more erratic. I started operation_Info and waited for about 10 seconds and both waits. Other times it will immediately stop. But so far, starting and stopping it more than once seems to work consistently.

I run windows 2000.

[Johnner]

I'd like to see this in action on my machine. Some months back, I had a situation where I thought that the "ignore previous" input was being ignored in one of my apps, but it turned out that the programmer was actually at fault (the idiot! 🙂 ). It was a complex application, nothing like your simple setup.

Anyway, I suspect that others could verify the problem if you can create a recipe that reliably (say, at least 50% of the time) causes the problem to occur. If you can come up with such a recipe, then post a step-by-step description along the lines of what you did originally or what I followed up with, I'm sure others can verify or otherwise explain what is happening.

Regards,
John

[Ben]

HI All,

I do not have time to step and verify but...

I was convinced there was an issue with the ignore previous in LV 6.1(?).

I think it was dependent on what settings were set when and if it was copied from another.

So...

Do NOT rule out a bug and verify which version of LV.

Ben

[Joseph_Loo]

I have done 5 out of times the following manner.

1. Start alarm_hold_not
2. start operation_info
3. alarm_hold_not will stop
4. start alarm_hold_not will run continuously

[Johnner]

Joseph,

If I understand what you wrote, then my diagnosis is that LabVIEW is behaving properly in this case. Let me restate what you found, as I understand it:

1. Run alarm_hold_not.vi
2. Run operation_info.vi (result: alarm_hold_not.vi stops immediately)
3. Run alarm_hold_not.vi again (result: alarm_hold_not.vi runs indefinitely without stopping)

Is this an accurate restatement of your test? If so, I think this is actually the way LabVIEW should behave with your example VIs.

My understanding of "ignore previous" is that it actually means "ignore messages sent to this notifier since the last time this particular Wait on Notification node was called". In Step 3 above, there has been no new message since the last time the Wait on Notification node in alarm_hold_not.vi was called, so it behaves appropriately and waits for the next message.

It seems as if you think a FALSE input for "ignore previous" means that the notifier should return immediately if the notifier has ever been set at any point during the execution of the current process. I don't think that's the way it works, though.

Does this make sense? I'm open to correction if my interpretation of this setting is wrong, and, like Ben, I'm still interested in uncovering possible glitches in the behavior of notifers, though I have no evidence of my own that there's a problem.

Regards,
John