LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2012 SP1, Can't get correct mechanical action on boolean buttons

Solved!
Go to solution

I am trying to use boolean buttons and events to programatically change the properties of a graph.  I basically want to click a button on the FP, and have the graph change the desired property.  All the property changing is fine, but I am really struggling with the mechanical action of the buttons.

 

I'll preface this by apologizing that I cannot post my code, as the computers with LV installed are isolated. My code is basically OK buttons, a while loop, and an event structure with a value change event for each button.

 

I want the user to click and release the button. After the click and release, I want the button to be in the same state it started, and I want the value change event to only trigger once.  Sounds to me like I want the Latch When Released mechanical action.  The problem is that this isn't working.  I cannot create buttons that behave like this.  None of the 6 mechanical actions exhibit the desired behavior.

 

To make matters worse, I have two OK buttons both set to Latch when released.  Both buttons are True before the click. One button behaves as intended (button is true again after the click and release) and the other button doesn't switch back.  I tried to copy the correctly working button, but still the copied button does not work the same as the original.  Both buttons fire a single value change event, dispite behaving differently.

 

To answer the question "Where did I get the working button from?"  A while back I made a simple button test vi that tested all 6 of the mechanical actions and kept track of how many times they fired a value change event for a single click.  My buttons worked when I made this vi...eventually, i remember having trouble with this back then too.  The results of that trouble had me using switch until released buttons with mouse down events for a long time, until I got the button test VI working properly and learned how buttons actually work. But now buttons are being funny again.  I tried to copy working Latch when released button into my current program, but for some reason only one of the two copied buttons work as intended, despite them being copies of the same button.

 

Is there some bug in LV2012 SP1 (64 bit) where mechanical actions don't work consistently?  Am I just being dumb?  I'm sorry I can't post the code.  I have this issue on both Windows 7 and Linux.

 

A bit more info, as I wanted to make sure I tried eveyrthing before posting.  I tried to make a new button test VI.  The old one still works, but I cannot get the buttons in the new button test vi to behave the same as in the old one I made.  In the new one, Latch when pressed behaves the same as switch when pressed, and latch when relased behaves the same as switch when released.  Switch until released and latch until released behave slightly differently.  They both fire two value change events, but SuR actually switches twice (there and back again), where LuR just switches state once but still fires two value change events anyway.  I have checked to make sure the mechanical actions are set properly at least a dozen times.

 

Pretty confused over here.  My old button test vi works as I expect it to, and the Latch when released button works like I want, but I can't for the life of me reproduce it.

0 Kudos
Message 1 of 7
(3,560 Views)

I've never heard of this, and find it extremely hard to imagine how it could happen.  Two "pale pink" (as opposed to Red) flags were raised by your post -- using Mouse Down events and using LabVIEW 64-bit.  I would try to eliminate Mouse Down events if possible, and if not, make a tiny test VI to see if this code is possibly producing the strange behavior.  You mention two OK buttons (OK, three pale pink flags) -- why two?  How are they different?  Is there something "strange" about the (almost identical) OK button that fails?  Is it in the same VI as the one that works?  Oooh, do you have more than one Event Structure in your code?  This can sometimes work (which, I hope, implies that it can sometimes do weird things).

 

Finally, why LabVIEW 64-bit?  LabVIEW 32-bit is considered far more robust (most of us run it on 64-bit Windows).

 

Bob Schor

 

P.S. -- Can you reproduce this behavior on another PC that is not restricted?  You don't need to reproduce all of the code, just enough to show the behavior.  If so, it would really help to post a simple test VI that demonstrates the problem ...

0 Kudos
Message 2 of 7
(3,541 Views)

To Bob_Schor

I realize the folly of mouse down events, and I'm trying to move away from them.  I originally started using them because I couldn't get the desired button behavior out of value change events and any other mechanical action.

 

I use LabVIEW 64 bit because I was hitting the RAM limits with the 32 bit version.  I hit the limit when I try to plot a great deal of data in 3D, which I do fairly often. I get away with this because I don't interface with any equipment or use any of the specialized modules, but maybe I should consider only using 64 when it's absolutely necesary and get 32 bit on there as well.  But I have the same issue on Linux, which only has a 32 bit labview version (still 2012 SP1)

 

There is only one event structure in the program.  I have two buttons because I'm just using them to fire two separate events.  My current situation is that I am plotting 9 plots on a single graph.  One of these buttons is a "check all" button for the visibility check boxes.  I click the check all button, and all 9 plots become visible.  The other button is an "Uncheck all" button, which does the opposite.

 

That's for my current program.  I also have a button test vi which has 6 boolean buttons, each set to a different mechanical action.  A single event stucture in a while loop has a value change event for each button.  I made this so that I could see for myself how the buttons worked (i.e. I see that the switch when released mechanical action produced two value change events.).  I have an old version of this program which works as I expect it to.  This morning I tried to remake it (it's very simple) and it does not behave the same, despite the block diagram being pretty much identical.  I described the differences in the OP.

 

I can reporduce the behavior on a second computer that is restricted.  Which is 32 bit labview for Linux. I don't have an unrestricted machine with LabVIEW installed.  If I did, I would have tried to rebuild my button test VI  (again) to see if it works.

 

At it's most basic, create an OK button on the FP and set in the True state.  It defaults to the Latch when released mechanical action.  Throw an event structure in a while loop.  Give the ES a value change event for the button.  In this even just increment some counter to indicate how many times the value change has been triggered.  I did this using a shift register.  Run it.  For me, when I click the Latch when released button it fires one value change event and doesn't reset to true when after the click.  I can change the mechanical action of the button, and none of the 6 give me what I want.

 

So my issue just boils down to Latch when released not behaving properly.

 

In my original button test vi (which was this with 5 more buttons and 5 more value change events in the ES), the latch when released button DOES reset to true after my click.  Copy and pasting this button creates a new button which does not behave the same way, despite still being set to latch when released.

 

My problem is not so much with the events, but the behavior of the button.  Am I correct that Latch when released is what I want?  A single click, and the button fires one VC event and returns to the same state before the click?

0 Kudos
Message 3 of 7
(3,525 Views)
Solution
Accepted by topic author Verywiseguy

Do you have the button terminal located in the Value Change event associated with that button? 

Capture.PNG

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 4 of 7
(3,520 Views)
Solution
Accepted by topic author Verywiseguy

Latch when released—Changes the control value only after you release the mouse button within the graphical boundary of the control. When the VI reads it once, the control reverts to its default value. This behavior works in the same manner as dialog box buttons and system buttons. You cannot select this behavior for a radio buttons control.


Description from help file.  If your button terminal is outside the main while loop, it never gets read again.  You can throw the terminals into the timeout frame but there will be a delay before the button changes back, depending on how long it takes to complete your Value Change event.  It only makes sense to me, however, to keep the button terminal with the button event. 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 5 of 7
(3,501 Views)

That's the danger of being self taught I guess.  I had only read in passing to include the terminal for the boolean in the event, and I had no idea why that was.  I assumed it was just a convention, and didn't usually use it because it seemed to go against the "controls of the left, indicators on the right" that perhaps is not as sacred as I thought.  I didn't understand that just by including the terminal somewhere in the event, it gets "read" and that the mechanical action actually depends heavily on that fact.  I also would have thought that the "NewVal" terminal in the event structure could have been considered a read, but it is clearly not.

 

Including the terminal in the event case fixed the problem.

 

TIL.

 

Thank you.

0 Kudos
Message 6 of 7
(3,469 Views)

For latch action booleans, it is imporatant where you place the terminal.

 

For other control types, placing th terminal in the associated event case lets you double-click the control on the FP and find the correct event case quickly and easily.

 

Just my 2 cents,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 7 of 7
(3,464 Views)