LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI does not recieve dynamic user event

Solved!
Go to solution

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.

0 Kudos
Message 11 of 24
(939 Views)
You should note that NI does not consider this a bug. You can read this thread for more details.

___________________
Try to take over the world!
0 Kudos
Message 12 of 24
(923 Views)

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.

0 Kudos
Message 13 of 24
(916 Views)
Rather than bug, I should say LabVIEW is not sufficiently protecting me from myself:smileytongue:.  They need a big flashing WARNING sign in the documentation.  Intermittent bugs are always the toughest to fix, so this one can be nasty.
0 Kudos
Message 14 of 24
(906 Views)

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.


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.

___________________
Try to take over the world!
0 Kudos
Message 15 of 24
(897 Views)

"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.

0 Kudos
Message 16 of 24
(897 Views)

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 >  

 

Message Edited by CoastalMaineBird on 08-02-2009 04:43 AM
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 17 of 24
(890 Views)
"Same refnum" = "same registration refnum", just like Steve said. The Register for Events node is expandable, so it can include more than one event in the same reg refnum. If you'll look at the link I gave earlier, there's a simple (well, relatively simple 😉 ) example demonstrating the issue very well.

___________________
Try to take over the world!
0 Kudos
Message 18 of 24
(881 Views)

Ah, refnum referring to the registration refnum.  Now the fog is lifting.

 

Shane.

0 Kudos
Message 19 of 24
(872 Views)

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.

Message Edited by Intaris on 08-02-2009 10:23 AM
0 Kudos
Message 20 of 24
(871 Views)