How to reset a switch (boolean) once command is initiated

[Flutfy]

Hi all,

Does a switch (boolean) set to a mechanical action "switch until released" keep a "true" value after the command initiates a specific case structure?  I'm developing software to control an existing instrument whose front panel switches have different purposes depending on what part of the menu is active.  As such,  I'd like to reset a switch as soon as the command initiates a specific case structure, so as to keep using it deeper into the menu...  Would I need to use a property node?  Anyhow, if anyone could point me to an example VI or have any suggestions it would be appreciated....  Thanks in advance, Fred

[James.M]

You usually don't want to use a front panel control / button to store a value through multiple parts of your code. Ideally, you can use the event triggering of the button press to set a boolean value within a data cluster or variable that makes its way through your code.

"Switch until released" will stay True until the use un-clicks the button. This is usually only used when you want to allow the user to hold down a button for a period of time and the amount of time they hold down the button directly affects the application.

Please include a Snippet of your code, or attach your VIs, so that we can better assist you.

[GerdW]

Hi Fred,

to reset the switch you can use a local variable.

But the UX is quite annoying when you press a button and it depresses while you still hold it...

[Flutfy]

Thanks for the fast reply James.

I'm just beginning the coding and thinking about the approach.  Would there be a way to "disable" a specific case structure?  That might provide the functionality of the same front panel switch being used for different purposes. I'm thinking indexing would allow different parts of the case structure/code to be disabled or enabled.

[James.M]

Without seeing your current attempt or fully understanding what you're trying to do, you probably can use one of the simple architectures commonly used in LabVIEW to do what you want.

The Simple State Machine template that ships with LabVIEW is really the best way for new developers to get familiar with LabVIEW while utilizing a semi-scalable architecture.

Here's a broad example of how a state machine works:

• States: Init, Idle, Exit, DoThing1, DoThing2, DoThing3
• Each state contains code that might take some time. Ideally, not too long because that's how long your code could be unresponsive.
• The Idle state contains an event structure for all user interaction.
• The front panel has a button that says "Do Thing 1".

1. Loop Iteration 0: Application begins, first state is Init. The Init state does some initialization stuff and tells the application to go to the Idle state when finished.
2. Loop Iteration 1: Application goes to Idle state. It sits there, waiting at the event structure.
3. Time goes by, then user presses button "Do Thing 1". There is no code, or minimal code, within this event case. The output of this event state tells the application to go to the DoThing1 state.
4. Loop Iteration 3: Application goes to DoThing1 state. There is code here that does some stuff. The output of DoThing1 state tells the application to go back to the Idle state.
5. Loop Iteration 4: Application goes to Idle state where it waits at the event structure again.

• Each of the states can tell the application to go to any state they want. Want to reinitialize? Go to the Init state again. Want to end the program? Go to the Exit state. Want each state to trigger another (like a sequence)? Have DoThing1 output DoThing2, which outputs DoThing3,  which outputs Idle.

The Producer/Consumer architecture is based on a producer loop adding data to a queue and the consumer loop dequeueing the data. The process-intensive or time-hogging code goes in the consumer loop to free up the producer loop to run at the speed you need it to run.

For example, you have code that acquires data every 100ms and needs to write that data to file. It takes 50ms for the acquisition code to run and 80ms for the write-to-file code to run. Uh Oh! You're now taking 130ms per loop and your application is backing up. Now you move the write-to-file code to a consumer loop and enqueue data to it from your producer loop. Voila! Your 50ms code and 80ms code run in parallel and can both keep up with the 100ms period.

More information here.