How to use the same buttons in different cases

[vindsan]

Hi,

I have a program with 4 different cases. I have to use the same buttons in every case. But I am not sure how to do that. When I tried to create local variable of the buttons, so as to use in all cases, an error is showing boolean latch action is incompatible with local variables.  So how can I use the same buttons in 4 different cases with mechanical action latch when released. Thanking You. 

[James.M]

The short answer: right-click the booleans and change their mechanical actions to Switching instead of Latching. This doesn't really solve your problem because this is going to introduce a bunch of race condition bugs in your code.

You don't want to split your buttons among your cases. You want a single case that handles the user events and the other cases can keep the values via shift register.

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. This is where you keep those booleans.
• 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.

[crossrulz]

Before we all jump to conclusions, perhaps you should share your code to show your exact situation.  There is a potential for a very simple solution or it may become complex.

[vindsan]

As said, I will share my code. The code is to back up data using tcp. There are mainly 4 cases all data, data younger than, data older than and defined data. I have used state machine for this I know about state machines. But then inside each case there is another state machine with 2 different cases, i.e copy and cut. For that I have used 2 buttons copy, cut and also a third button cancel, if i dont want to backup. Now this is where the problem arises. The 3 buttons I have now used in the 1st case All data, But I cant use the same in other cases. I have done things like keep the 3 buttons outside the case sturcture of the main state machine and tried to wire it into the second state machine. But that didnt work. The only way I can do it is using the 3 buttons inside the second state machine, But then I will be having this 2nd state machine in all 4 cases and I need to use the same button without chaning the mechanical action. So that is my problem. How can it be solved. Thanking You.

[James.M]

I'm still sticking with what I said above. You shouldn't try to access the same buttons from two different places. This is especially true if you have a state machine within a state machine.

When the copy/cut/whatver button is pressed, store the values in the form of a shift register (a cluster or array of booleans) and then use the value of that shift register in the other cases if needed. YOu already know how to store the state in a shift register, so do the same with other data.

[crossrulz]

Yeah, you definately should rethink your architecture.  Loops inside of a state machine are generally a bad idea.  And there is no reason for the block diagram to be so large (at least 4 of my screens!).

You should think about having multiple loops.  One loop can be for nothing but an Event Structure to handle any button presses etc. and then another loop to handle commands coming from the event loop.  Look into a Queued Message Handler to get a better idea of what I'm describing here.

[Alexander_Sobolev]

One of the goals of using states is not to have duplicate regions of code. You violate this: earlier than, older than, all data states are identical. I see 1 parameters that differs: list of files. Make one state "process" that accepts this parameter. Define list of files in Select state and pass it through the shift register for example. Or at least make this selection in the first part of case frame that lists all three states. SubVIs to generate / read data for single file will shrink your block diagram to 800x600

Queued state machines allow you to define multiple states to run from the very beginning. (Select files, process, delete - optional)

Please check LabVIEW style book, it is much better explained there.