Multiple event structures using same boolean

[kbauman]

Hello,

I am programming a motor to run various tasks, but to rerun a task / enter a different mode when commanded by a Boolean input on the front panel. In a state machine, two different states are action driven commands that enter the "Run" phase when the "Run" boolean is commanded. However, when the "Run" button is changed in the first state, the code runs, etc, then enters the next state, the "Run" change value prompts that state to automatically enter the "Run" state again. How can I use the same Boolean on the front panel, but have the action only affect the loop when it is changed in that state? Or is there a way the event structure can "forget" any previous value changes? Should I use a local variable or producer-consumer structure? Anything would be helpful. Thank you!

[Gregory]

 Can you post your code for this one? It's very hard to visualize with text only. Thank you

[JensG69]

Judging from the title of the thread I'd say the OP uses several event-structures with-in several states of a state machine - and links the same button to several event structures.

@kbaumann: Don't do this! Do not use several event-structures within 1 VI. Read the caveats and hints for usage of the event structure in the help file. To avoid any problems with possible lock-ups of the front-panel I usually recommend to use only 1 event-structure in 1 VI. Everything else just causes headaches at some point.

Regards, Jens

[crossrulz]

In this situation, I like the idea of putting the case structure for the state machine inside of the timeout case of the Event Structure.  Then you are constantly checking for button presses and can react based on what state you were supposed to be going into.

[RavensFan]

---

jg69 wrote: 

Read the caveats and hints for usage of the event structure in the help file.

Here's the link:
Caveats and Recommendations when Using Events in LabVIEW - LabVIEW 2016 Help

[Mark_Yedinak]

---

@crossrulz wrote:

In this situation, I like the idea of putting the case structure for the state machine inside of the timeout case of the Event Structure.  Then you are constantly checking for button presses and can react based on what state you were supposed to be going into.

---

Ugh, that turns the event structure into a polling architecture. Whenever possible I try to avoid polling. It is hard to visualize what the OP is working with or trying to do but my first thought would be to define user events to be used in the state machines. One event structure would be dedicated to the UI actions and based on state information would fire the appropriate user events to trigger actions in the state machines. Queues could also be used. I'm not a fan of splitting up processing of the UI in multiple places, especially UI input events.