LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Resetting a variable in an event structure (dynamic event)

I'm working on moving an event structure into a sub VI. This means I have to register dynamic events. 

The event structure is handling some button clicks. The state of the button (mechanical action = latch when released) resets itself automatically as long as the variable is placed within the value change case.  Leaving the button in this case is not possible when the event structure is put in a sub VI and the variable is located in the parent VI.  How do I make sure the button unlatches after clicking on it?  I have attached an example where all the code is in one VI (the local variable must be moved outside the event structure in order for it to be moved into a sub VI).  Any ideas?

 

If you open the VI and run it, you can click Start which will cause the counter to start incrementing.  The button only unlatches as long as the variable is located in the value change case.

 

(Btw, how do you put images inline in a post?)

Rob
Download All
0 Kudos
Message 1 of 4
(2,972 Views)

The first thing that comes to mind is to just switch the control to "switch when released" and have the event structure set it to false via a control reference. You could also palce its indicator or a local in a loop that runs regularly in the main vi (how long it takes to unlatch would depend on when its value is read).

 

To attach images you edit the post, copy the url of the image's attachment. Then use that url with the insert image button.

Message Edited by Matt W on 09-24-2008 08:25 PM
0 Kudos
Message 2 of 4
(2,969 Views)
That seems to work, almost.  Btw, I assume it is safe for a sub Vi to modify local variable in parent VI...(via reference)?  (I might be worrying about this without reason as I am used to text based programming...)  It works fine in this test app, but when I try it in my actual app, the pointer starts to flicker after each button click (that is, switching from pointer to wait cursor to pointer again several times. Which would look odd to the user...)
Rob
0 Kudos
Message 3 of 4
(2,958 Views)

Race conditions are the primary reason not to do that. But since your treating your variable as a latch, I doubt your using the value you read from it anywhere, and in that case it can't create a race condition. There's also the possibility that the control's reference could become invalid. But since this is a sub VI of the control's VI that can't happen (even if it could you can check the error out of the value property node to see when it happens and deal with it).

 

I'm not sure about the flickering, Since I can't seem to duplicate it with a simple test case on my machine. It might related to whatever else you're doing in the event apart from reseting the value to false.

0 Kudos
Message 4 of 4
(2,950 Views)