Race condition question

[bilgetea]

This is probably a naive question, because I am a beginner.
I have a front panel cluster (custom control) which contains various
elements, including buttons which need to be popped back up under
program control. In some program states nothing at all is done to the
cluster; it is passed through the case structures and subvis unchanged
in what amounts to a control wired directly to its own local variable.
The result is a race condition. While the VI is running, the user
tries to push the buttons, and they refuse to stay down (or come back
up)! This is true of other elements in the cluster, such as numeric
controls, that aren't even wired to anything yet - they refuse to
change, but once in a while, if you click enough, a chang
e will get
though.
What is the proper way to wire a front panel control through some
process (subvis etc) and back to itself without causing a race
condition?

To get an idea of the situation: create an infinitely executing while
loop. Put a numeric control inside. Create a local variable for the
numeric control (write mode), also inside the loop, and wire it to the
numeric control. When you run this, it resists all efforts to change
the control.

Thanks in advance for any help!

---------------------------
Dan Greenspan
Mail Stop 14-707M
Johns Hopkins University
Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, MD 20723-6099

240-228-7490
daniel.greenspan@jhuapl.edu
---------------------------

[Albert.Geven]

The easiest way to prevent this problem is not to write to a control at all. But an alternative is to write only to the control when you have changed the contents programmatically.
Your problem seems to be related to booleans that have to be reset when handled. This looks like you could be helped by not writing these booleans but simply change their mechanical action to "latch when ..." This forbids the use of locals so maybe you have to remove the booleans from the cluster !

[Dan]

If you just need the booleans to reset after being set and read, try
changing the latching action by right clicking on the control. You could
also try adding a wait function so the user has time to change the value
before the program overwrites his input.

Dan

"Dan Greenspan" wrote in message
news:3AA42AD8.EF20FF04@jhuapl.edu...
> This is probably a naive question, because I am a beginner.
> I have a front panel cluster (custom control) which contains various
> elements, including buttons which need to be popped back up under
> program control. In some program states nothing at all is done to the
> cluster; it is passed through the case structures and subvis unchanged
> in what amounts to a control wired directly to its own local variable.
>
The result is a race condition. While the VI is running, the user
> tries to push the buttons, and they refuse to stay down (or come back
> up)! This is true of other elements in the cluster, such as numeric
> controls, that aren't even wired to anything yet - they refuse to
> change, but once in a while, if you click enough, a change will get
> though.
> What is the proper way to wire a front panel control through some
> process (subvis etc) and back to itself without causing a race
> condition?
>
> To get an idea of the situation: create an infinitely executing while
> loop. Put a numeric control inside. Create a local variable for the
> numeric control (write mode), also inside the loop, and wire it to the
> numeric control. When you run this, it resists all efforts to change
> the control.
>
> Thanks in advance for any help!
>
> ---------------------------
> Dan Greenspan
> Mail Stop 14-707M
> Johns Hopkins University
> Applied Physics Laboratory
> 11100 Johns Hopkins Road
>
Laurel, MD 20723-6099
>
> 240-228-7490
> daniel.greenspan@jhuapl.edu
> ---------------------------

[bilgetea]

Thanks to all who sent helpful hints. The best (and the working)
solution is to use a state machine - this eliminates the race condition
(I used an executive-style state machine, as per the book "LabView
advanced programming techniques" written by Bitter et al).

The only down sides of this method is that it's more complex (but if it
works - how can you argue?!) and it seems to limit your ability to move
the state machine to a subvi, since it uses local variables from the top
level.

---------------------------
Dan Greenspan
Mail Stop 14-707M
Johns Hopkins University
Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, MD 20723-6099

240-228-7490
daniel.greenspan@jhuapl.edu
---------------------------