Adding more dynamic events to registration refnum

[siadajpan]

Hi

I've got a wire that passes Event Registration refnum to my event structure. This wire is comming from VI, that I don't want to touch. It is passing registration for cluster of user events.

I'd like to add more dynamic events to this refnum (but not to the cluster), so I'd like to reregister with adding new events. 

When I'm passing this refnum to "Register for Events" block, LabVIEW doesn't allow me to make this block bigger and add new events, which I guess is understandable.

How can I add more dynamic events to this refnum?

[udka]

If Possible add vi or snippet.

-Disconnect event reg refnum out terminal of the Register For Events function from event structure.

-Try expanding now and adding new refnums and then reconnect there wil be broken wires i guess and you should be able to reconnect.

Edit: modify the event registration refnum to cluster of [Old cluster of event registration refnums]+new event.

[siadajpan]

Hi

I can't touch cluster of events, is it any way to add it to existing registration refnum?

snippet attached

[Bob_Schor · Accepted solution]

Close, but no cigar.  When adding User Events, you want to be sure each Event has a unique Name, so name your constants defining the Events differently (as shown here).

Bob Schor

[siadajpan]

Hi

I didn't want to add anything more to existing Register For Events block, I wanted to use refnum wire that comes out of it and then add new events again because this wire is going out of vi that I didn't want to change.

But I accept this as an answer. I guess that proper way of doing is to use as an output cluster with events instead of registration refnum, and register just before event case.

[Sam_Sharp · Accepted solution]

You can bundle the event registration refnums:

[siadajpan]

Cool! Didn't know you can do this. That's what I wanted

[Ben]

Well I'll be...

I never thought of trying to cluster them!

But in general...

I abandoned the idea of doing the event registration in a sub-VI becuase

1) it produces a cluster that I can not make into a type and therefore will always break the wire if I change it

2) It hides the registered events and I have to dig into the sub-VI to figure what they are

3) At one time (maybe fixed now) modifying the event registration wire could re-arange all of the events in the event structure

As shown above, putting the event registration node in front of the event structure gives a nice little summary of the events that are handled by the code without having to "poke-at-it" and inspect each event case.

Ben

[Sam_Sharp]

Ben, there is a use-case where being able to bundle the event registration refnums is useful - it means you won't miss a generated event.

If you want to create a library/toolkit that uses events, by having the refnum passed out from a SubVI to your code means that the event handler won't miss any events that occurred if you were to register for it later (for example, the toolkit might initialise itself and then send a 'I am initialised event'...if the event handler hadn't registered for that event yet it would get lost in the ether).

It also allows you to create multiple different types of user events and just pass out a single wire to register for.

In the example you posted - if you had user events generated elsewhere and some of them might be generated before your Analysis_Mode.vi has started and registered for the event. You would lose all of the events generated before you registered for them. If you register for the events in advance, then they'll go into the event queue and get handled once the VI starts up.

[stevem181]

Two things I'd like to mention in regard to Dynamic Events:

1. For efficiency, avoid registering for events that you will never respond to
2. The "Timeout Event" timer is reset by FP and User Events - inducing jitter

To overcome the impact of item #2, I create a User Event Timeout loop. This is just a very simple parallel loop that has a timer and a "Generate User Event" node.

steve