07-11-2016 11:42 AM
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.
Solved! Go to Solution.
07-11-2016 11:58 AM - edited 07-11-2016 12:06 PM
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...
07-11-2016 12:05 PM - edited 07-11-2016 12:06 PM
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.
07-11-2016 12:06 PM - edited 07-11-2016 12:13 PM
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… 😄
07-11-2016 12:07 PM
@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
07-11-2016 12:12 PM
@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
07-11-2016 12:17 PM
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… 😞
07-11-2016 12:23 PM - edited 07-11-2016 12:40 PM
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.
07-11-2016 12:25 PM - edited 07-11-2016 12:35 PM
@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.
07-11-2016 12:38 PM
@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 😄