LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Stop button does not reset after each start of program

Solved!
Go to solution

Newbie here, So when I start the program with the Ni start arrow, my start button is always in the correct position but the stop button is not. How do you reset the user contols to defaults like the stop button.

0 Kudos
Message 1 of 18
(6,441 Views)

It would be very helpful if you could upload your VI so we can see. If you mean that you have a "stop button" on your VI (not the red stop sign abort button, which should never be the designed end of your program), then it is possible that you want a different latching mechanism. If you have it set to "switch when pressed" then it will not return to its original state after being read. If you set it to "latch when pressed" then it will return to it's original state. If you really need it set to "switch when pressed" then you could set its value to False at the beginning of your program through a local variable, but it's better to find a solution where latching works in my opinion.

 

Edit: I don't know if you had that attachment and I just missed it, or if you added it after my post. Either way, could you post for LV 2012 or sooner? You can do this using File >> Save for previous...

0 Kudos
Message 2 of 18
(6,437 Views)

Wrong mechanical action on your stop button.

 

It should be "Latch WHEN Released".  You have it "Latch UNTIL Released".

 

Also, I don't understand all of your boolean logic for that button, the feedback node, and the start button.  Just wire up the Stop button to the Stop terminal of the loop.  Get rid of everything else around it.

0 Kudos
Message 3 of 18
(6,429 Views)

Hi rr,

 

So when I start the program with the Ni start arrow, my start button is always in the correct position but the stop button is not. How do you reset the user contols to defaults like the stop button.

Set the switching behaviour of both buttons to "Latch when released", then set the correct default button state. Then save your VI…

 

Why did you change the switching behaviour?

Why do you read the start button before the event structure - but not inside?

Why do you use this complicated boolean logic with a feedback node to stop the while loop?

Why do you use StripPath/BuildPath in the event case?

Why do you use a case structure to decide on open or create of the file? Why don't you use OpenFile with option "open or create"?

Why don't you use a single FormatIntoString in the FOR loop without the ConcatString afterwards?

 

Your signature is getting boring - but I think you heard that before… 😄

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 4 of 18
(6,426 Views)

@Gregory wrote:

It would be very helpful if you could upload your VI so we can see. If you mean that you have a "stop button" on your VI (not the red stop sign abort button, which should never be the designed end of your program), then it is possible that you want a different latching mechanism. If you have it set to "switch when pressed" then it will not return to its original state after being read. If you set it to "latch when pressed" then it will return to it's original state. If you really need it set to "switch when pressed" then you could set its value to False at the beginning of your program though a local variable, but it's better to find a solution where latching works in my opinion.


Hello Gregory,

I did up load it and just downloaded it, is there a setting in this labview forum at allows others to see my uploaded VI? I'll do it again with this post maybe it just took a really long time. Our network has been sluggish this morning.

 

I have tried a few properties and now it's Latched until release but it still comes op off when if in the previous session one clicks the off button

0 Kudos
Message 5 of 18
(6,423 Views)

@RavensFan wrote:

Wrong mechanical action on your stop button.

 

It should be "Latch WHEN Released".  You have it "Latch UNTIL Released".

 

Also, I don't understand all of your boolean logic for that button, the feedback node, and the start button.  Just wire up the Stop button to the Stop terminal of the loop.  Get rid of everything else around it.


Hey RavensFan,

Latch when released has the same effect, if you start the program with the NI -> button then set a file and click start then click stop and go back to start the program again with the NI -> button then the stop buttom remains in depressed mode and the program only runs once when you hit the start button.

 

Hopefully that all makes sense 

0 Kudos
Message 6 of 18
(6,413 Views)

Hi rr,

 

then the stop buttom remains in depressed mode and the program only runs once when you hit the start button.

- The button returns to FALSE (when using Latch when released)…

- The loop stops because of your dreaded boolean logic - as you would recognize by starting to debug your VI…

 

There is one more big failure: because the event structure is not in a loop your VI becomes unresponsive when you click the start button two or more times… 😞

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 7 of 18
(6,404 Views)
Solution
Accepted by topic author rr1024

No. It does not have the same effect.  They are completely different actions.  If they were the same, then NI would have never created the second one.  I have never seen a practical use for "Until Released".  Read the help files on the mechanical actions to see the difference.  It is a real tricky, subtle difference.  But it is a difference.

 

If you clean up the boolean logic, and put the start button in the event structure.  It runs just fine.  See attached.

Message 8 of 18
(6,400 Views)

@GerdW wrote:

 

There is one more big failure: because the event structure is not in a loop your VI becomes unresponsive when you click the start button two or more times… 😞


That is true also.

 

But the OP has been told about this a few times before in previous threads and has failed to fix that problem.  In the modifided VI I attached, I fixed that be turning off the front panel lock for that event.

0 Kudos
Message 9 of 18
(6,399 Views)

@GerdW wrote:

 


Why did you change the switching behaviour? Because I was tying ot get it to work properly 

Why do you read the start button before the event structure - but not inside? Because the UI seems to freeze when I put the start button inside the event structure and we don't want that to happen do we? If you have a better why please show me

Why do you use this complicated boolean logic with a feedback node to stop the while loop? Because I want the user to be to stop and start the program, with one button or two but I couldn't get one button solution to work. If you have a better why please show me

Why do you use StripPath/BuildPath in the event case? Because without the strip path in place I have to provide a static file name an I want the user to type the file name in when they click the file icon. If you have a better why please show me

Why do you use a case structure to decide on open or create of the file? Why don't you use OpenFile with option "open or create"? I can go back at check to see if that works

Why don't you use a single FormatIntoString in the FOR loop without the ConcatString afterwards? because I need a specific format of the data for import into another program and I couldn't get formainto string to output it in the format  I needed but I could give that a try again

 

Your signature is getting boring - but I think you heard that before… and yours is not? what is your point 😄

0 Kudos
Message 10 of 18
(6,386 Views)