LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Update value numeric control in event structure

Hi all,
 
I have the following (small) problem. In my application I have a numeric controller and a boolean button. I change the value of the controller by typing a number (but do not press 'enter'). Then I press the boolean button which triggers an action in an event structure. In this event structure I read the value of the numeric controller. However sometimes it happens that the value of the numeric controller is not updated yet. So it seems that the event was started before the value of the numeric controller on the front panel was written to the variable. When I press 'enter' after changing the numerical controller and before triggering the event of course no such race problem happens.
 
Question is now: how to avoid this? I do not want to rely on the fact that users should press 'enter' after changing the values. Should I added a short delay before I read the value of the numeric controller? Or are there other 'cleaner' solutions?
 
Ture
LV 8.2
0 Kudos
Message 1 of 10
(4,622 Views)

Could you post an example VI of this problem?

I can't duplicate it, but I may not be understanding your VI configuration correctly.

Ed



Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 2 of 10
(4,616 Views)

I was probably not very clear.

Here a test vi that shows the problem.

Ture

LV 8.2

 

0 Kudos
Message 3 of 10
(4,610 Views)
See if is some like this
0 Kudos
Message 4 of 10
(4,610 Views)
Yes, that's it.
0 Kudos
Message 5 of 10
(4,605 Views)

Couple of notes just for, "Good information to know".

You should always try and put the control you are reading inside the event case that it is configured for. This way, it's value is not read until you actually change the value. If the control is outside the event case, it's value will be read before the event fires and you will not get the new value. There is a "New Value" terminal inside the event case you can use if you can't put the terminal in that case.

You should never use a property node or local variable to pass a value when you can use a wire. These causes copies os the data to made in memory and in the case of the property node, a switch in execution engines. With the Event Structure, if you have to put the control outside the structure, use the "new Value" terminal as stated above. Of course in your case, that would not work because the event case you're reading the control in configure to the boolean button and it will return the boolrans value.

See attached.

Ed



Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Message 6 of 10
(4,595 Views)
Find the difference...
If you look at the 2 VIs Untitled_MOD and at TestEvent and modify TestEvent (remove timeout, put Start action boolean in event loop) then they look basically the same. But when changing the numeric control (not hitting enter) and clicking the boolean, Untitled_MOD behaves correctly (returning the updated value) and TestEvent doesn't (it returns the old value). Does anybody know where this different behaviour comes from?
Daniel

0 Kudos
Message 7 of 10
(4,585 Views)

After making the changes to TestEvent, I get the new value when clicking the OK button.

The difference I see is that TestEvent is firing the Event Structure from the "Mouse Down" event and Untitled_MOD is using the "Value Change" event of the button. This really should only effect the way the button reacts. With the Value Cahnge, the event isn't fired until the user release the mouse button because the value of the button doesn't change until the button is released. Since the buttons mechanical action is set to "Latched When Released", the button will stay down until it is read inside the event case. When it is read in the event case, it is reset to its False state.

With the "Mouse Down" event, the event case fires as soon as the mouse button is clicked. So the front panel control is still being help down when the event fires and can't be reset till the next loop iteration.

Ed



Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Message 8 of 10
(4,578 Views)
Ah, thanks... didn't notice that TestEvent uses the Mouse Down event... i never even thought about this as this seems quite special for boolean controls.
@ture: that's the point... just change from mouse down to value change event.
Thanks, Daniel

0 Kudos
Message 9 of 10
(4,571 Views)
The 'mouse down' event was indeed the problem. Changing to 'mouse up' also helps 🙂
 
Thanks!
 
Note: when using 'value change' events one has to be carefull to select the correct mechanical action for the boolean. E.g. in case of 'latch until released' you can create two events when pressing long enough ...
 
Ture
LV 8.2
0 Kudos
Message 10 of 10
(4,562 Views)