Suppose we limited 1 event structure per block diagram?

[Yair]

It came from the fact that LabVIEW registers the static UI events in a VI's ES'es at VI load time. This means that if you have the same UI event configured in two event structures on a BD, those two ES'es will register the same event refnum basically, even if these two event structures do not run at the same time. Same as forking the event registration refnum - a very bad idea.

 

Is it a fact? I understand how it that could be (we know that static events are registered as soon as the VI goes into run mode, so it would make some sense), but it would make just as much sense (more, in fact) to say that each event structure has a separate queue and uses the same mechanism that the VI would use to detect the transition to run mode and then registers separately. What makes you think that the VI has what is parallel to a single registration refnum?

Also, thanks for posting this. I spent a few minutes earlier today unsuccessfully looking for the code from Jack's presentation for something and I figured I would have to look at the video tomorrow to find the link to the code there. Now in looking over the first page of this thread I found the link.

[Steen Schmidt]

Is it a fact? I understand how it that could be (we know that static events are registered as soon as the VI goes into run mode, so it would make some sense), but it would make just as much sense (more, in fact) to say that each event structure has a separate queue and uses the same mechanism that the VI would use to detect the transition to run mode and then registers separately. What makes you think that the VI has what is parallel to a single registration refnum?

 

I didn't mean that the VI registering for UI events at load time was the same as when you fork an event reg refnum. I meant it was a similarly bad idea.

 

Actually forking the event reg refnum could probably be used for multiplexing event handling in some systems. It's just very particular systems this would benefit. And that is usually not the use case the programmer is trying to implement, when forking an event reg refnum ;-)

 

/Steen

[Yair]

I didn't mean that the VI registering for UI events at load time was the same as when you fork an event reg refnum. I meant it was a similarly bad idea.

 

Ah, I see. The phrasing was really confusing, because you made it sound as if it would behave in the same way. I personally think it's not as bad, if only because it wouldn't behave the same and that it does have a defined behavior. I wouldn't say I would recommend it, but it's not *as* bad.

 

 

Actually forking the event reg refnum could probably be used for multiplexing event handling in some systems. It's just very particular systems this would benefit. And that is usually not the use case the programmer is trying to implement, when forking an event reg refnum ;-)

 

I don't think I would ever do that, because as far as I can tell, the behavior there is undefined. You might figure out how it behaves and use it as a hack, but undefined behavior is not something I would rely on (and in the one time I needed to be hurt by this before figuring out I shouldn't do it, I actually saw that the behavior was not just undefined, but also inconsistent, at least in the way I wrote that specific code. And in that case, incidentally, I wasn't even processing the same events. I was processing different events from the same refnum in separate structures). I also expect that almost every single programmer who splits this wire does it because of ignorance of the consequences.

[Steen Schmidt]

I agree with you Yair, that forking an event reg refnum is worse than multiple ES'es with UI events in a VI. After all I do the latter occasionally, but never the former.

Forking the event reg refnum shows very consistent behaviour in my eyes though. What happens is exactly that, that whenever an event structure is ready to process one more event from that forked refnum, it gets the next one waiting in the queue - but it doesn't dequeue it, it just peeks it. Others are at liberty to peek this event as well. Whenever anyone *finishes* processing an event from that queue, that event is finally dropped from the queue.

This means that a slow iterating event handler will see fewer than all events from that forked refnum, and a very fast one might see all of them. Many events will typically be handled by more than one of the forks.

A type of system that could benefit from this behaviour is when you have multiple event handlers with highly fluctuating performance - for instance a number of event handlers that each runs on its own CPU, but also shares that CPU with other fluctuating processes. Then you get a natural load balancing behaviour. The only caveat is that your system must be tolerant of the same event being potentially handled multiple times occasionally (systems that are tolerant to this will have a fast way to identify and discard already processed events).

That is the observed behaviour of forking the event reg refnum, but as it is not supported officially, I don't use it either. I must do it the hard way and make a scheduler myself.

/Steen

Edited September 15, 2014 by Steen Schmidt

[Yair]

The behavior I saw was different, but it was on 7.0, which was  the first version to support dynamic registration, so the underlying code may have been different. I don't remember the exact details, and I don't feel like looking up the thread, but essentially it was something like "there are events waiting in the queue, but they're only processed after a timeout happens, even though the timeout case itself isn't executed" or "events sometimes disappear without anyone processing them". In short, inconsistent and unpredictable behavior, at least in that specific instance.

 

I believe there were also cases of events sometimes being processed by more than one structure (the peek behavior you mentioned) but sometimes disappearing without anyone handling them.

[Steen Schmidt]

I see, really nasty behavior (I don't think I investigated this before LV 2010-ish). And that potentially changing behavior is the danger - might as well see that as definetely will change. So no need to speculate in (mis)using forking the event reg refnum unless it becomes a supported (or at least stable and documented) feature.

 

/Steen

Edited September 16, 2014 by Steen Schmidt

[drjdpowell]

Steen’s understanding of how multiple Event structures act with a branched Event Registration matches mine.  Not the most useful of behaviors, but you could use it in a “worker pool†system as long as you layer in a way of preventing duplicate handling (like passing a single-element queue in the User Event so only one process can actually get the data).  

[Yair]

Steen’s understanding of how multiple Event structures act with a branched Event Registration matches mine.

 

And the documentation for LV 2013:

 

 

If you wire the event registration refnum to more than one Event structure, each Event structure handles dynamic events out of the same event queue. This can occur if you branch the event reg refnum out output of a Register For Events function to another Event structure. This causes a race condition, because the first Event structure to handle the event can prevent the other Event structure from receiving the event if it completes the event case before the other Event structure executes.

 

So this also refers to the single queue and the peeking and doesn't mention other issues. I don't know if this changed at some point after 7.0 (e.g. in the 2013 refactoring) or if back then it was simply buggy. I agree that this doesn't appear to be as undefined as it used to be, but I still doubt I would go near it (unless perhaps it was an extremely simplistic case of something like multiple consumers configured to only handle event X and a stop event and even then probably not).

[ShaunR]

And the documentation for LV 2013:

 

 

So this also refers to the single queue and the peeking and doesn't mention other issues. I don't know if this changed at some point after 7.0 (e.g. in the 2013 refactoring) or if back then it was simply buggy. I agree that this doesn't appear to be as undefined as it used to be, but I still doubt I would go near it (unless perhaps it was an extremely simplistic case of something like multiple consumers configured to only handle event X and a stop event and even then probably not).

 

I think event refnums are fairly well documented and there was a good presentation by Jack that demonstrated the issues.

 

What is not clear and unintuitive is what happens if you place two event structures and connect them to the same FP control. This is THE rookie mistake, after all, I just wanna add another function to operate in parallel when I press that button, right?

Edited September 16, 2014 by ShaunR

[drjdpowell]

What is not clear and unintuitive is what happens if you place two event structures and connect them to the same FP control. This is THE rookie mistake, after all, I just wanna add another function to operate in parallel when I press that button, right?

Does that not work!?!

[Steen Schmidt]

I think event refnums are fairly well documented and there was a good presentation by Jack that demonstrated the issues.

 

In the presentation I saw, Jack didn't explain what happened with the forked event reg refnum, merely that it displayed odd behavior and thus was discouraged ;-) Not to take anything away from Jack at all - he's a top guy, and I'd attend any presentation he hosts even when I know the subject inside out - just to point out that there is a difference between what he disclosed and what we're discussing just now. Now I hope he didn't update his presentation to include this info, in which case I'm just embarrasing :-)

 

/Steen

Edited September 16, 2014 by Steen Schmidt

[shoneill]

What is not clear and unintuitive is what happens if you place two event structures and connect them to the same FP control. This is THE rookie mistake, after all, I just wanna add another function to operate in parallel when I press that button, right?

That works fine.  The static events do not share Event Registrations if they are in different structures.

 

It all depends on what the functionality is.  If both try to affect the control based on a new Value for example then you have a race condition but otherwise it works fine.

[Steen Schmidt]

What is not clear and unintuitive is what happens if you place two event structures and connect them to the same FP control. This is THE rookie mistake, after all, I just wanna add another function to operate in parallel when I press that button, right?

 

That is quite clear what happens, unless there is a bug I'm not familiar with? Both event structures will receive the event, so you better be prepared to handle that event at both structures :-)

 

What can really make things odd is when "Lock panel (...) until the case for this event completes" is enabled in an event structure that doesn't run, and it receives a UI event. Even though that ES isn't running it'll still lock the FP from seemingly far away... There's no way to probe your way into this. I set up stuff like that to test potential employees, to see if they have the LV skills to fix such a bug.

 

/Steen

[shoneill]

What can really make things odd is when "Lock panel (...) until the case for this event completes" is enabled in an event structure that doesn't run, and it receives a UI event. Even though that ES isn't running it'll still lock the FP from seemingly far away... There's no way to probe your way into this. I set up stuff like that to test potential employees, to see if they have the LV skills to fix such a bug.

 

Now that's frustrating behaviour.  I ran into this once.  Once.  Never again.

[drjdpowell]

What can really make things odd is when "Lock panel (...) until the case for this event completes" is enabled in an event structure that doesn't run, and it receives a UI event. 

Not really "odd"; that's exactly the stated and desired behaviour.  The event locks the panel until it is handled.  If you don't handle it, then it remains locked.

[shoneill]

Yeah but the setting is made in the STRUCTURE which is not yet executing but still blocks the UI thread.

 

I wish the Event structure had the option to ignore events which are raised before it actually starts executing.

[GregFreeman]

I was thinking about it and I wonder if when LabVIEW first introduced event structures, if people had one event structure for each control.  Certainly not knowing the intended way to work with a tool is a common way to use it improperly, and generally speaking having multiple event structures is a red flag for this.  But when advanced users know what they are doing, powerful things can be done with these tools.

I know this is old but I couldn't resist. The answer is yes. The person that did it: me, even when the ES was no longer new (although I was new at this time). I had no knowledge of right clicking and adding event case.

 

http://forums.ni.com/ni/attachments/ni/170/363372/1/VI.PNG

Edited September 29, 2014 by GregFreeman

[hooovahh]

We need to have like a self confession thread, where we post code we are ashamed of.  I haven't looked at any of my old code on my site, and I'm going to pretend that site doesn't exist except once a year when I have to pay the fee to keep it up.

[David Boyd]

I might have a tactical advantage there... who would bother to load up on old LabVIEW versions just to look at my rookie LV4.0 code.  (Now, where's that chart Scott Hannahs did that shows the last version that'll open 4.0...?)

 

Actually, I have plenty of much newer code I'm ashamed of, so who am I kidding?

[shoneill]

Lots of my code has a developer it's ashamed of.....

[hooovahh]

I might have a tactical advantage there... who would bother to load up on old LabVIEW versions just to look at my rookie LV4.0 code.  (Now, where's that chart Scott Hannahs did that shows the last version that'll open 4.0...?)

This chart is always a pain to read but I think 8.2 is the newest version that can open 4.x version. 

 

EDIT: Oh and by the way I started in the 6.x era so I think my code can be opened in modern versions.