Some User Events Are Not Triggering Across Different LabVIEW Libraries

[rolfk]

To be able to say anything conclusive we would need to be able to see your actual code including subVIs, not just an image.

You create quite a few objects here. The path DVR for instance is wired to 3 subVIs. Maybe two trigger it and the other registers on it to receive it but we can't say. Then you create another DVR that is also again passed to 3 subVIs. An Error Queue is created too and wired to all and then a user event. For this last one you create a single user event registration that is wired to all these subVIs too, but you also wire the event itself to each of the subVIs. To say that you created a chaotic event messaging structure between these 3 subVIs is not really exaggerating. I would loose the overview in this very quickly and have to reinvestigate every time again when working on this VI.

So yes if that last registered event is indeed waited on in multiple VIs and triggers more than one event handler per event, something seems off, and that might be a race condition in the event registration handling. However with such a criss cross wiring of events and other asynchronous objects between these three subVIs it is a lot more likely that your programmed VIs are not performing the way you think you programmed it.

And as Yair pointed out, wiring an event registration to multiple event structures is discouraged even in the documentation. The documentation only explicitly states the fact that an event will not be received by all the event structures in such a case, but also nowhere makes any guarantee that it will be always received by exactly one event structure only.

[Intaris · Accepted solution]

---

@akash_maxeye wrote:

Thank you for the explanation. I have one point I'd like to clarify.

If multiple Event Structures truly share the same Event Registration Refnum, I would expect each generated User Event to be dequeued by only one Event Structure.

However, in my application, I can see that the same User Event is handled by multiple Event Structures, while a few Event Structures never receive it.

---

This behaviour is shown int he video I provided a link to earlier in the thread.

The system behind the scenes is not designed for this kind of usage (as the code is pretty old at this stage) and so the behaviour slips into "kinda works, but kinda doesn't".  There is no guaranteed 1:1 event handling, but there's also no guaranteed 1:N event handling. What you get is something in between. Unless something major has changed int he last few LabVIEW versions, I would expect this to still be the observed behaviour.

For any given event, use one registration refnum for each event structure.

[Yamaeda]

A User event registration is basically a queue. You can have several consumers, but the first one that grabs an event will get it and the others not. The solution is easy, have 1 registration per consumer, assuming that's not the behaviour you want. 

(you can e.g. have several consumers for performance reasons)

[tst]

---

@Yamaeda wrote:

A User event registration is basically a queue. You can have several consumers, but the first one that grabs an event will get it and the others not.

---

No, you should not treat it as a queue. As pointed out multiple times in this thread, the behavior is effectively unpredictable. Events may be consumed multiple times or not at all. I believe this is still the case with modern LV.

You are correct that the solution is not to use the same registration for more than one consumer.

[Intaris]

---

@tst wrote:No, you should not treat it as a queue. As pointed out multiple times in this thread, the behavior is effectively unpredictable. Events may be consumed multiple times or not at all. I believe this is still the case with modern LV.

This is very important to note. Event registrations are like thread-unsafe Queues. Technically Queues, but not implemented in a way that guarantees operation over multiple threads. Therefore always use a 1:1 registration refnum to event structure arrangement.

[Yamaeda]

---

@tst wrote:

---

@Yamaeda wrote:

A User event registration is basically a queue. You can have several consumers, but the first one that grabs an event will get it and the others not.

---

No, you should not treat it as a queue. As pointed out multiple times in this thread, the behavior is effectively unpredictable. Events may be consumed multiple times or not at all. I believe this is still the case with modern LV.

You are correct that the solution is not to use the same registration for more than one consumer.

---

No, you shouldn't treat it as a queue, but it has many similarities is what i meant. If several event structures listen to 1 registration it'll only be 1 that executes it, must like with queues, right? Or can it randomly go to all listeners and be consumed several times? I might have misunderstood some things.

As some clever person put it, Queues are Many-to-One, Events are One-to-Many.

[UliB]

---

@Yamaeda wrote:

---

@tst wrote:

---

@Yamaeda wrote:

A User event registration is basically a queue. You can have several consumers, but the first one that grabs an event will get it and the others not.

---

No, you should not treat it as a queue. As pointed out multiple times in this thread, the behavior is effectively unpredictable. Events may be consumed multiple times or not at all. I believe this is still the case with modern LV.

You are correct that the solution is not to use the same registration for more than one consumer.

---

No, you shouldn't treat it as a queue, but it has many similarities is what i meant. If several event structures listen to 1 registration it'll only be 1 that executes it, must like with queues, right? Or can it randomly go to all listeners and be consumed several times? I might have misunderstood some things.

As some clever person put it, Queues are Many-to-One, Events are One-to-Many.

---

See tsts answer if you use one Event Registration for multiple Event Structures: [...] the behavior is effectively unpredictable.

And there is a difference between Event and Event Registration. A generated Event will go to every Event Registration it is registered for. If you use each event registration only for one event structure, all registered event structures will receive the event.

But if you use one Event Registration for multiple Event Structures: the behavior is effectively unpredictable.

[JÞB]

I alluded to the Event Inspection Window in my early post.

NOW I would state that some of my fellow Champions and Knights should USE that tool! Casting shame

[tst]

---

@Yamaeda wrote:

---

If several event structures listen to 1 registration it'll only be 1 that executes it, must like with queues, right? Or can it randomly go to all listeners and be consumed several times? I might have misunderstood some things.

---

Just to be explictly clear, the answer to first question is no and to the second is yes (where randomly is a key word and several is between 0 and N, but I don't know what N is. Note that this means an event might be consumed by multiple consumers or might disappear without being consumed and you have no way to predict the behavior that I know of). There were links to details on this earlier in the thread.

This behavior is why you want to have no more than one consumer per registration, so that you have predictable behavior. It's also important to note the distinction that UliB made (which can be easy to miss): This discussion only applies to the registration reference, not to the event reference. An event reference can be registered for multiple times without concern.

[Intaris]

---

@JÞB wrote:

---

---

And here is why.  Each Register for user Events creates exactly 1 Event Queue Reference.   Similar to creating a filter Event that always discards Events across every Event Structure registered for that Event.  The User Event will be processed EXACTLY ONCE across all Event Structure that share the User Event Refnum. 

,,,,

I won't go so far as to say "Never branch a User Event Refnum Wire!"  There may actually be times when you want a single User Event to take an if, then Else action so, LabVIEW allows this syntax.

---

Given the current weather here in Switzerland, I'll gladly stand in the shade.😀

This is actually not true as far as I know unless something has changed in the newer versions of LabVIEW or I have fundaementally misunderstood something.

This directly contradicts other information (which can be demoed) which details that the handling of registered events from a single Event registration refnum across MULTIPLE event structures is NOT deterministic. "this syntax" you refer to is not reliable. Has this been changed in new LabVIEW versions?