Notification uncanceled?

[Djovanny]

Hi!

I have noticed a strange behaviour in my VI. I have a VI that launches a daemon and communicates

with it (whose diagram is shown here) by notifications.  There are 2 references to the notifier: one in the

main VI, the other in the daemon VI, whose task is to run a sequence of operations, step by step.

When I want to skip one step, I send from the mian VI the notification "SKIP".

In the deamon, first poll the <<queued>> notification by a Get Notifier Status to see if I can skip before starting

a step, then handle the notification during the step run. If I the poll says "SKIP", I try to remove this notification

by Cancel Notification.

Strangely, the cancel operation des not occur. If I send from the main VI the "SKIP" notification, this remains in

queue thoughout the further steps, and I an suddenly at the end of my sequence, and not just leaped one step.

Any hints why does it happen?

[Dynamik]

Hi Djovanny,

The hidden cases - especially empty-string and Default cases, could be very important here.

I hope you won't mind a couple of questions(?)

Is the Loop supposed to iterate by-itself, without any notifications from caller?  It looks like, once the "daemon" is called, it will wait the "DELAY" timeout, then loop ("Get Notifier Status" executes instantaneously (i think)),  and repeat this until the loop-index-test goes FALSE - whether or not any notifications occur.

Will the while loop execute (1) too many times?  The loop-index-test (i < ( Length( [] ) ) isn't false until the loop-index is (1 element) past the end of array.

Cheers!

---

Djovanny wrote:

Hi!

When I want to skip one step, I send from the mian VI the notification "SKIP".

In the deamon, first poll the <> notification by a Get Notifier Status to see if I can skip before starting

a step, then handle the notification during the step run. If I the poll says "SKIP", I try to remove this notification

by Cancel Notification.

Strangely, the cancel operation des not occur. If I send from the main VI the "SKIP" notification, this remains in

queue thoughout the further steps, and I an suddenly at the end of my sequence, and not just leaped one step.

Any hints why does it happen?

---

[Djovanny]

---

@Dynamik wrote:

[...]The hidden cases - especially empty-string and Default cases, could be very important here.

[...]Is the Loop supposed to iterate by-itself, without any notifications from caller?  It looks like, once the "daemon" is called, it will wait the "DELAY" timeout, then loop ("Get Notifier Status" executes instantaneously (i think)),  and repeat this until the loop-index-test goes FALSE - whether or not any notifications occur.

Will the while loop execute (1) too many times?  The loop-index-test (i < ( Length( [] ) ) isn't false until the loop-index is (1 element) past the end of array.

Cheers!

---

The hidden cases were actually poorly wirtten, without notification waiting. However they never were into consideration in my tests and have no consequences (just tested putting a cancel notification operation). Same for the loop-end condition. Fixed. Thanks a lot!!!

The loop iterates by itself, it's right. The notification is used only for skipping steps upon user command. The "get notifier" is used in order to be able to skip before this latter starts, if there is a skip user command; otherwise the notification is waited during operation (some can be just a second, some other last for hours) by a "Wait for notifier". The notification is received by the instrument command subVI (where the "Wait for notifier" is run with a 100 ms timeout), but afterwards the "Get status" in the next steps still receives the "SKIP"/"STOP" notification, as if the "Wait for notifier" did not clear the notifier status.