Boolean event driver failing to toggle

[JeffOverton]

Hey again everybody,

Just a quick one today:  My front panel has about 20 boolean controls, all of which drive value change events, and for safety purposes some of them have to be enabled/disabled based on the states of the others.  When I was doing this in a much more basic (and incorrect) way, I noticed some double toggling, but that's bounce and I can accept it.  However, now that I've added a bunch of complexity, sometimes the boolean will toggle internally and trigger the event without ever toggling on the front panel.  For instance, after attempting to toggle a control to false, while the front panel says True, the cache says False and the Boolean:Value Change event triggered for a False new value.

Any ideas?

Jeff

[johnsold]

Jeff,

Can you post a simple example which demonstrates this behavior?

Without seeing your VI I can only guess, but my guess would be that you have a race condition. Are you using local variables or property nodes to change the value of the boolean?

Also recall that the front panel only updates at the display frame rate, usually in the 75-85 Hz range. The program could change the value many times between screen updates.

Lynn

[altenbach]

---

JeffCWRU wrote:

For instance, after attempting to toggle a control to false, while the front panel says True, the cache says False and the Boolean:Value Change event triggered for a False new value.

---

If you toggle a control to false, the new value should be false, so that seems OK.

What is your definition of "the cache"?

Can you show us some simple code to explain the problem more clearly?

[JeffOverton]

I'm honestly not sure if I could recreate the problem without breaking the company's IP policy

I'm probably safe saying that it's a system of valves all controlled through FieldPoint, and they are all controlled through an event structure inside a while loop.  Data readback on the valves is performed at every iteration and other data is read at a 10 ms timeout, and all open/close happens at the user's request.  None of the valves or control booleans are programmatically altered by read-in data.  And since there's no programmatic possbility of opening and closing immediately, it probably isn't the refresh rate.  Also, the way I have it set up is that every valve toggle has to go through a subvi (which actually writes the data to the valve) which should delay it longer than mouse bounce.

Also odd is that the situation is only partially repeatable.  I can make it happen maybe once in twenty tries, and I have no idea what that means.

edit - Sorry altenbach, I didn't see you had posted.  The control is visually true, but a false has been passed into the internal workings.  Or, in so many words, it's displaying that the valve is open when it has already ordered the valve to close.  I have it set to blink if this is the case, but with some of the situations that will need to be handled, you don't really want to have to click twice to close or open a valve.

Message Edited by JeffCWRU on 01-04-2008 03:08 PM

edit again - could it be that the mouse bounced, signaled the front panel to toggle the boolean twice, whereas the first event was still processing and didn't acknowledge the second hit?

Message Edited by JeffCWRU on 01-04-2008 03:10 PM

[TCPlomp]

So you are absolutly positive you don't use 'Value(SGN)'?
If you think you have a bad mouse behaviour, apply 'lock panel' in the event properties.

Ton

[Gabi1]

---

JeffCWRU wrote:

I'm honestly not sure if I could recreate the problem without breaking the company's IP policy

---

make a demo vi, whit this boolean and the same number of locals/value property nodes and events call to the boolean.

i suspect the simplest possible reason is the right one: you call a change of state of your boolean trough a local variable (therefore not simultaneously displayed on front panel)

[Matthew_Kelton]

How are you getting the value that you are saying is incorrect?  If you're using the evnt structure, are you using the New Value property of the event or are you reading from a control?  If you're reading from the control, is the control inside or outside the event structure?  If you do not have a timeout event and the control is outside of the event structure, then the control value will be one iteration behind, as the value would be read form the control before the event structure sits to wait for an event.  Although, I would expect that you would see more deterministic behavior if this was the case.

[JeffOverton]

Thanks for the replies, everybody.  I appreciate the help.

Ton:

I only use Value(SGN) once, and that's in a subvi to trigger an event that enables or disables a valve based on other valve states.  There isn't any data writing to the actual valve, it just changes a hidden control to trigger the event.  Also, locking the panel would create other safety concerns, so unfortunately that's not an option.

Gabi:

It would take hours to make a demo vi, just based on all the logic behind it.  If I just removed the actual calls to the valves and sensors, that would make the program completely different, because I have had to program in some curious ways to account for physical delays in the valves.  It does seem like it would be pretty easy to have the control written twice, so I'll look through the code for that.

Matthew:

I use the NewValue in the event structure to capture the intended state of the control.  All my controls are outside the event structure, but inside the main while loop.  Also, I use my timeout to gather data from the sensors to make basically a continuous data read unless the user acts.

I can't shake the suspicion that the control is just accidentally being hit again while the first event is still executing.  I am not 100% sure if my memory is correct, but I am pretty sure that when I had a slower, less efficient valve disabling scheme, and it checked after every potential troublesome valve to see if others needed to be disabled or enabled, the double-toggles happened more often and were easier to recreate.  Then, when I simplified the scheme, they became less frequent but still annoying.  Is it even possible to toggle the control while its event is still executing, or am I just way off base?

[TCPlomp]

---

@JeffCWRU wrote:

Is it even possible to toggle the control while its event is still executing, or am I just way off base?

---

Yes, that's why there's a mark 'Lock front-panel until the event case for this event completes'.
Maybe an idea to disable the control directly when entering it's event (disabled state 1) and re-enable when the event handler is finishing (disabled state 0).

Ton

[JeffOverton]

That sounds like a really good idea.  How efficient is the enable/disable control execution?  Would it add noticeable delay to the program?