08-01-2009 12:02 AM
I changed my code by giving each event structure its own dynamic event refnum as recommended by tst. This seems to have fixed my problem(!). Thanks for all of the helpful responses on this thread, I was really going in circles on this problem.
If I can get up the energy I will try to make a comment to NI about this bug, the way that it works intermittently can hide the fact that it is in fact broken, and this could make for a really nasty bug.
08-01-2009 01:39 PM
08-01-2009 03:46 PM
I agree, it's not a bug, you're doing things wrong.
If you think about it, REGISTERING for the event is the important part, it tells the event handler how many recipients to send the data to. If you have more waiting for the event than are being triggered, then it's obvious that some are going to miss out on some information.
Shane.
08-01-2009 07:22 PM
08-02-2009 03:41 AM
The problem (at least in my case) was that I was NOT waiting on the same event. The event structures were handling different events from the same refnum, but one was occasionally clearing the events for the other. Even worse, it would occasionally get "stuck" - seemingly waiting on a timeout even though it had events in its queue. The behavior is definitely buggy in the "it acts weird" sense. NI has covered itself by saying "don't do that, it wasn't designed to work like that", but they're not really saying it loud enough.
Intaris wrote:If you have more waiting for the event than are being triggered, then it's obvious that some are going to miss out on some information.
08-02-2009 03:50 AM
"The event structures were handling different events from the same refnum"
I don't understand this part. One refnum = One event. How can you have multiple events on a single refnum?
An Event is the "trigger" caught by the event structure, so this would mean you are overloading an event refnum? Never heard of that.
I certainly DO agree that there are several things needing upgrades when dealing with Events in LV, but I don't see the problem here at the moment.
Shane.
08-02-2009 04:41 AM - edited 08-02-2009 04:43 AM
I don't understand this part. One refnum = One event.
Well, we're getting sloppy with terminology here.
There are EVENT refnums, which do correspond one-to-one with events created with CREATE USER EVENT.
And then there are EVENT REGISTRATION REFNUMS which refer to some sort of LabVIEW record and might represent one or a hundred events.
The rule seems to be (and this was news to me, though I had never tried it before) that if you have two EVENT structures in parallel that you must register TWICE and attach the EVENT REGISTRATION REFNUMS separately to each EVENT structure.
You may NOT register ONCE and share the EVENT REGISTRATION REFNUM with the two EVENT structures, or you'll have missing events as described here.
If I think about how it has to work internally, I suppose it must be this way.
< SHEER SPECULATION warning >
If I was writing the internals of this, I suppose I would:
1... Have a central Event manager.
2... CREATE USER EVENT tells the event manager that this event carries a record of two I32s and a BOOL (or whatever your DATA TYPE is). Event manager assigns this a number #1.
3... REGISTER USER EVENTS creates a new record that says we're interested in event #1 and #5, and #16 in an event structure in frame 2 of case FALSE in VI MyWonderfulVI.vi.
4... This registration record is given to the event manager.
5... Remember that this is PUSH technology, not PULL. It's not the EVENT structure that says "What do I do next?" - it's the event manager that says "Who do I pass this event to?"
6... When an event happens, the event manager has to decide what to do with it. It looks in its registration records and finds ONE record that says frame 2 of case FALSE in VI "MyWonderfulVI.vi" wants this event.
7... If triggers the appropriate case of that event structure.
8... When the event stops executing, the registration record is withdrawn from the event manager (it's done its job). The next time through the loop you might re-attach it, but for now, it's forgotten.
9... If you attach the same EVENT REGISTRATION RECORD to the events manager TWICE, only the last one takes effect.
10.. With two loops running, the event goes to one or the other, but which one depends on random timing factors.
11.. But if you register TWICE, there are TWO EVENT REGISTRATION RECORDs, and the event manager knows to trigger the event TWICE, if it's in both records.
< / SHEER SPECULATION warning >
Blog for (mostly LabVIEW) programmers: Tips And Tricks
08-02-2009 07:39 AM
08-02-2009 10:18 AM
Ah, refnum referring to the registration refnum. Now the fog is lifting.
Shane.
08-02-2009 10:22 AM - edited 08-02-2009 10:23 AM
CoastalMaineBird wrote:
< SHEER SPECULATION warning >
If I was writing the internals of this, I suppose I would:
.....
8... When the event stops executing, the registration record is withdrawn from the event manager (it's done its job). The next time through the loop you might re-attach it, but for now, it's forgotten.
9... If you attach the same EVENT REGISTRATION RECORD to the events manager TWICE, only the last one takes effect.
.....
< / SHEER SPECULATION warning >
Message Edited by CoastalMaineBird on 08-02-2009 04:43 AM
The registration for that specific INSTANCE of the event is cancelled (if that description has any relevance whatsoever to the actual implementation), but not for the Event istelf. This would lead to some ugly timing issues resultingin occasional missed Events.
I could imagine that a single "register for events" creates a cluster which results in a SINGLE piece of communication which means ALL or NONE of the events within that cluster go to one event structure or another and they don't get split up at all. Is this similar to the problem you were having Tst? I don't have LV in front ofme at the moment.
Shane.