Q's about Notifier behavior with re-entrant vi's

[TG]

Hi guys,

Im trying to get to the bottom of this notifier mystery I am encountering

to learn the tricks of the trade with them and (also) event structures which I view as being earily similar to notifiers.

Ive made an investment in using them for a messaging mechanism in my project

It involves re-entrant clone VIs launched with Vi server invoke nodes. It is not too easy to make an example.

A few Questions come to mind, most of them may be not specific enough

because Im not really super keen on notifiers yet. How they relate to re-entrant vis launched with Vi server

is new to me so here goes..

Is it a sensible 'use case' to send messages with notifiers

using a one way downstream channel 'cmd' and then using another notifier for

the upstream channel 'ack' for replies.

WHen creating a notifier reference and carting it around various VIs does the notifier reference sometimes go invalid?

What would be the condition for that happening (if any)?

If the VI that initialized the notifier (originally) was not idlie but sitting in an event structure timing out in a polling loop

and a notifier reference was 'obtained by name' in another re-entrant vi for messaging could the

Notifier reference (on a wire) in the original vi possible go idle? Is there any condition that could kill that

notifier on the wire in the original Vi?

Can notifiers and event polling run in parallel ok?

Example

In a section of code

A notifier 'A' awaits a message while a lower loop polls in parallel.

The lower loop will (before exiting) send a nofification to "A" letting it continue.

Notifier "A" can recieve a message from the lower loop or from an external section of code (another re-entrant Vi )

WHen notifier "A" triggers (gets msg) it enables code to shut down the lower loop should it still be executing (then other things)

Is it ok to do this when both vis are re-entrant?

(I'll try to make an example if it is not clear.)

I've noticed notifiers and event structures can sometimes give unpredictabe results even when the rules of use are (apparently)

being followed. For example, when connecting to a notifier input terminal on a subVI (a typedef'd notifier ref) in some cases there

is a coercion. I can create a typedef constant from the vi terminal then convert it to a control then conect it to the (same)

terminal and a coersion dot appears. I cannot explain this.

Another way to explain strange behavior is a usage where two re-entrant Vis are messaging in a master slave setup where Vi 'A' is sending cmds and the vi 'B' is setup to acknowledge the commands.

vi 'A' sends a notification on 'msg' channel to vi 'B'

vi 'B' replies with its own notification on 'ack' channel back to vi "A".

Each Vi obtains the proper notification "by name" 'msg' and 'ack' before then exchange messages.

Normally one would expect this to work flawlessly, however sometimes it doesn't and it drives me nuts why it isn't more stable.

(no significant change in code just stops working for unknown reasons) it is almosyt as if LabVIEW is losing track of things which i know is not the case

because it is far more likely to be me!

I wish I could be more specific but it is troubling me that I

cannot even pin down what is happening. :headbang:

How often must LabVIEW be restarted when developing and testing notification messaging with re-entrant vi's.

During development is it possible that one or two (non graceful)

aborts could trigger such odd behaviour with notifiers especially?

I do not see unstable behavior with queues, semaphores or any of the other functions and I assume we all hit the abort button during

development phase of untested code. I only see weird behavior with notifiers and event structures.

Anyway I was running into strange timeouts that i dont understand today and would appreciate

any second opinions.

Thank You

[Tomi Maila]

Hi,

I'm just quickly browsing the messages at LAVA. First events had some major problems before was it LV 8.0. or LV 8.20 so if you are using old version of LabVIEW, upgrade.

Also there is odd notifier behavior that is explained in the Notifier Signals Missed thread. Basically a single wait for notification node (WfN) instance can only be used to catch notifiers from a single source safely. If you use a singe wait for notification instance to catch notifications from multiple sources then you may or actually will encounter problems. You should browse trough this thread if you are using notifiers.

[TG]

Thanks Tomi

I'm using 8.2.1

Let me look this link over.

I appreciate the quick response.

Edit1: So far I only looked at your excellent first example and in 8.21 It has problems if you make more than 5 or 6 iterations.

This seems to be almost if not exactly what I am experiencing. Your response has value to me thanks. At the very least least it seems to

illustrate a real problem with these creatures since your usage seems to be quite reasonable.

Edit2: Oh boy, As I read further and see where the discussion is heading I am appalled at the complexity of this issue.

This is going to take a month of Sundays to figure out what you guys are talking about in that thread.

[Tomi Maila]

I use both queues and events for notifications. I've not encountered any problems with either of them

With events you must register the events so that you have a unique event registration refnum for each event structure. Event registration refnum is like a mailbox that you cannot share with your pal.

Queues can be used instead of notifiers as well although the logics of queues is a little different. Queues can be easily used for asynchronous messaging, especially for one-to-one messaging. To send a message, enqueue the message to the queue. To catch the message, preview or dequeue it. When the queue is empty i.e. it contains no message the dequeue operation waits until timeout. The things become more complicated when you need to send a message to multiple receivers. You can then create a queue for each receiver separately and enqueue the message to all these queues. You can also create a proxy VI that takes care of multiplying the initial message so that each receiver gets one.

Tomi

[TG]

QUOTE(Tomi Maila @ Sep 30 2007, 06:52 AM)

I use both queues and events for notifications. I've not encountered any problems with either of them

Thats encouraging!

QUOTE(Tomi Maila @ Sep 30 2007, 06:52 AM)

With events you must register the events so that you have a unique event registration refnum for each event structure. Event registration refnum is like a mailbox that you cannot share with your pal.

I think I understand.

Let me ask this quick Q : True or false?

[ When launching multiple re-entrant *instances* (lets call em Slaves) it is possible to use event registration for signaling a single *instance* in the group

as long as the registration refnum sent (from the Master) to each *instance* is unique. ]

QUOTE(Tomi Maila @ Sep 30 2007, 06:52 AM)

Queues can be used instead of notifiers as well although the logics of queues is a little different. Queues can be easily used for asynchronous messaging, especially for one-to-one messaging. To send a message, enqueue the message to the queue. To catch the message, preview or dequeue it. When the queue is empty i.e. it contains no message the dequeue operation waits until timeout. The things become more complicated when you need to send a message to multiple receivers. You can then create a queue for each receiver separately and enqueue the message to all these queues. You can also create a proxy VI that takes care of multiplying the initial message so that each receiver gets one.

Tomi

That is the best help answer for my plight. Thanks Tomi! Your answers are always the best ones.

PS: My bad for taking a chance with notifiers again. They seem to work so well at first.. and then.. missed notifications

out of nowhere - no easy way to track down the cause... I always think it is somehow my own mistake. Now I know better.

Your original example is a valid and reasonable use case and it simply does not work reliably with re-entrant vi's .

I won't use them anymore for fancy stuff. I don't care what the experts say.

TG

[Tomi Maila]

QUOTE(TG @ Sep 30 2007, 09:19 PM)

[ When launching multiple re-entrant *instances* (lets call em Slaves) it is possible to use event registration for signaling a single *instance* in the group

as long as the registration refnum sent (from the Master) to each *instance* is unique. ]

True. But I would recommend normally not to pass event registration refnums around but instead pass user events around and register the events just before the execution of the actual event structure loop. This way you don't accidentally use the same event registration refnum multiple times. Don't forget to unregister the events so that they don't consume system resources when you don't use them anymore.

So the program flow I recommend would be something like:

Master: Create user event

Master: Start Receiver process

Master: Pass user event reference to Receiver for example using a named queue

Receiver: Register user event

Receiver: Send initialization status to Master (usually OK)

Master: Start Sender process

Master: Pass user event reference to Sender for example using a named queue

Sender: Send initialization status to Master (usually OK)

Sender: Generate user event

Receiver: Catch user event using event structure

Receiver: Before exiting unregister user event and exit

Master: Before exiting, destroy user event

And this program flow would allow you to have as many senders and as many receivers as you would like for the single user event reference. Then all the receivers would listen messages from all the senders. All the receivers would handle all the messages.

[TG]

QUOTE(Tomi Maila @ Sep 30 2007, 10:03 PM)

True. But I would recommend normally not to pass event registration refnums around but instead pass user events around and register the events just before the execution of the actual event structure loop. This way you don't accidentally use the same event registration refnum multiple times. Don't forget to unregister the events so that they don't consume system resources when you don't use them anymore.

So the program flow I recommend would be something like:

Master: Create user event

Master: Start Receiver process

Master: Pass user event reference to Receiver for example using a named queue

Receiver: Register user event

Receiver: Send initialization status to Master (usually OK)

Master: Start Sender process

Master: Pass user event reference to Sender for example using a named queue

Sender: Send initialization status to Master (usually OK)

Sender: Generate user event

Receiver: Catch user event using event structure

Receiver: Before exiting unregister user event and exit

Master: Before exiting, destroy user event

And this program flow would allow you to have as many senders and as many receivers as you would like for the single user event reference. Then all the receivers would listen messages from all the senders. All the receivers would handle all the messages.

Excellent advice. Really appreciated.