State machines and controls/indicators

[VeeJay]

Hi there,

I have been using State machines a lot and I get the concept of using them. But, my code looks very clumpsy in that where do I place the controls and indicators when they are being used in most states?

Currently, I have them outside the main while loop and if any state wants to update the indicator or take a controls value, I use property node. This makes the code clumpsy and with lotsa wiring. Please provide an example on how to make the code look professional. Thanks!

[Ben]

I use a GUI controller to store the control refs as shown in this thread.

I have actions to Init, and Get and if there are functions that I need to use over and over I create a special action for those situation that handle all of the controls ref at one shot.

Ben

[SimonH]

I've approached this several different ways.  

In simple state machines I'll often have one state called "Update Display" and keep any state or data information in shift registers so that when this state is executed it has all the information it needs.  I keep all indicator terminals in this state.

In more complex applications I don't like having specific ties to my UI in a state machine who's primary purpose is not controlling the UI so I'll use queues and notifiers to send messages and data to a separate state machine/loop that handles the display.  This way various states just need the appropriate queue/notifier message. Queues ensure all commands get handled, notifiers allow my UI to always display the latest data and not unduly stress the system (and more important loops such as the logging loop) trying to display every point.

The separation also makes it easy to have multiple UIs for the same application since the actual logic can be put in subVIs and passed the appropriate queue references.

~Simon