LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event error1

I'm trying to get around the fact that XControls don't react to user events they are registered for and I thought I had a owrkaround up and running.

 

I am using a VI (non-reentrant) to create the event refnums and am using this in my testing program (to trigger the events) and my XControls (To register for the events).  Each XControl launches a small parallel routine to actually subscribe to the user events, which in turn ping the XControl allowing it to react accordingly.  The parallel VI is started when the "Exec change" changes from "idle" to "running".  The parallel VI is closed when the "Exec change" changes from "running" to "idle".

 

Problem is that is only works once.

 

I have several XControl instances on my FP (of the same type) which all register to the same broadcast event.  This works fine the first time I execute the test program.  As soon as my testing VI goes into idle however, the Events I am using give me Error 1 when firing.  I've probed them adn they're not NULL, they retain the same value as they did originally and this also matches up with what is in the XControl.....

 

How are my events losing validity?  I don't understand the current behaviour.

 

Shane.

 

Ps Here's a ZIP with a project illustrating the problem.  I have two XControls on my tester FP listening to the same event (I want a method of system-wide update of important variables).  First run is OK after opening the tester VI but the second run (after stopping the tester VI without closing the FP) doesn't work.  Help?

0 Kudos
Message 1 of 3
(2,545 Views)
0 Kudos
Message 2 of 3
(2,517 Views)

I agree that it's a race condition, but I don't think the description in that article is fully relevant for this case since it's slightly more complex.

 

The reference is created in the hierarchy of the tester (the value change event VI runs from the tester VI first), I'm assuming because the Xctl takes some time to run the exec state change event. That means that when the tester VI stops running the ref is automatically destroyed, but because the Xctls keep running, next time you run the VI the first call primitive returns F and you get the old event ref, which is no longer valid.

 

One (bad) way to handle this is to put a wait before the VCE call in the main VI. This will "ensure" that the VI is called in the facade VI first. You could probably secure the wait by calling a property like the article suggests, because I assume the ESC event will happen first, but that's just a guess.

 

Another way might be to pass calling the VCE VI to the init of the Xctl, but I'm not sure that will work, because the init VI will probably be the top-level VI, and it still won't work.


___________________
Try to take over the world!
0 Kudos
Message 3 of 3
(2,508 Views)