Can I reset a control button programmatically? Specifically, I'm wanting to switch a Boolean button back to a false state in response to certain events/conditions.
For example, consider the attached VI. (It is un-finished, because I don't know how to finish it.) The user can make the counter count by clicking the count button. What I want to do is stop the counter at some number (10) and reset the count button, so the user has to re-click for a new count.
Solved! Go to Solution.
also, change the mechanical action of the count switch to "latch when pressed or released"
Check out "Create... > Local Variable"
...and then DON'T create one. Check out Apok's example instead...
I think he wanted the "Count" button to remain pressed in- and the counter to keep counting- until n=10, or whatever- and then have the count button pop back out. In which case, I think he'll want a local...
(Might be wrong of course..!)
This is one of those times some additional functions can be your friends.
Events, Property nodes and Feedback nodes should be loaded into any developer tool-box ready to replace the "Screw-Hammer" when a better tool exists.
Count Value change event selects either -1 or 100 for timeout
Stop value change sets the exit condition
I renamed Count (I32) to Counts since its not very good to have two objects with the same label
I think he wanted the "Count" button to remain pressed in- I read that too since the true string is "Counting" Still the Local is less desirable since a Val(Signalling) can be beneficial in this case
In that case, right-click on your "Count" button terminal, "Create...> Local Variable". That gives you a "second terminal" to your front-panel control... which you can either read from, at a different place on the diagram (sometimes saves messy wires), or in your case, you can change it (with a right-click) to write mode , thus allowing you to force a value to your front panel control.
BUT- huuuuge BUT!- be careful! Use of locals can give rise to race conditions, and all manner of bad things. (Additional copies of data is a common refrain, which would be heinous for a big array, but acceptable for a single boolean). Plus they tend to elicit strong reactions among programmers; along the lines of Dijkstra/ GOTO...
Undoubtedly- though I have only read the code, not run it (to paraphrase Knuth)
However, it's nothing like as transparent for a beginner to comprehend; and while we should encourage good habits (and discourage bad!), we don't need to intimidate.. ;-) (or optimise prematurely ;-D)