Switch returns to true after Property node Value(sig) sets to false.

[Munchuk]

Evening All,

The attached Vi is being used to move a XYZ stage.  I have implemented a feature where a while loop (one without the event structure) checks the encoder values on the axis, and will set the control for the movement to False if the limit is exceeded. The limits are set to stop the axis from running into the end of the travel.  The Vi works well, can move the stage around and stops when the limit is exceeded. The Dialog box pops up saying that the limit has been exceeded, and I can see that the Control is set to False. This triggers the event loop and the command is sent to turn the motors off.

After I accept the dialog box, I get another dialog box popping up that is triggered from the event loop also saying that I have hit the limits. It is only possible to get this dialog box when the control is true. (I have had to put this into the event structure so that the motors will not start if the axis is already at the end of its travel).  I have looked at my debug string output and see that the control goes True (when i first click the control), False, True, False.  I am at a bit of a loss as to where the next True, False events are triggered by.

My thoughts so far is that I never let go of the control, it has been set False by the property node, and then when i accept the dialog box, the program reckons I am still holding the button down, but then immediately release it as I am now longer clicking the mouse.

Any other thoughts?

Thanks in advance.

Mark

[Bob_Schor]

Do you know about the Mechanical Action property of Boolean Controls?  There are six in all, but three will illustrate the differences:  One is "Switch When Pressed" -- each time you Press (push) it, it changes from True to False, or from False to True.  To change it back, you need to press it again.  Another is "Switch Until Released" -- this is a Push Button that stays "switched" until you release it, at which point it switches back.  This is the "Doorbell" option, True (or False) as long as you are pressing it.  The most unusual, and probably the most useful, is "Latch When Released" (which is what you want for Event Loops) -- this doesn't switch until you "release" the button, but then it stays switched until you read its value, at which point it returns to its default value, which for Booleans is False.

If you make your Up, Right, etc. Controls have the Latch When Released Mechanical Action, you don't need to use a Case Statement -- if the Event Fires, you must have pushed/released the Control, it should be Latched (and, unless you do really weird things, On = True), so just execute whatever code you want to run in that condition.  But be sure to have the Boolean (which doesn't need to be wired to anything!) inside the Event Case so that it will reset.

Try this with a simple Boolean Control.  Note that the OK, Cancel, and Stop buttons all have this Mechanical Action property by default (think about it, and you should agree that this is a very good idea).

Bob Schor

P.S. -- Of course, I didn't carefully pay attention to the Subject Line, so I'm writing a PS.  Latch Controls cannot be used for Value Signalling!  There are (again) good Design Reasons for this restriction.  There are usually better ways to do "Whatever you Think You Want to Do" than this particular type of Value Signalling.  

[altenbach]

Don't over-engineer things!

Your buttons are "switch until released" (car horn), so in order to acknowledge the dialog, you need to take the mouse off the button anyway. It also means that only one single button can be true at any given time.

You probably could get away with a single event frame and none of these value and value(sgnl) property nodes.

You event frames have inner FOR loops and such, but you lock the front panel until the event completes.

Maybe all you need is one event frame for all the directional boolean changes which sets the timeout to finite whenever one button is TRUE and a timeout event to move according to the current state. Coerce the location to the given limits when out of range and set the timeout to infinite (-1) when an out of range situation occurs.

[Munchuk]

Thanks for your suggestions.

I need to use switch until release buttons because I need to start movement when the button is pressed and  stop movement when the button is released. I have had a good play with all of the mechanical actions today and switch until released is the only button that can do this.

I have finally got it working and replicating the behaviour I want. Crux to this was removing all of the property nodes. 

So thanks for your suggestions and getting the grey matter to think about the problem.