0018 - GUI Button State Machine

This post will share a design pattern that can be used in a serious GUI based application where several events must occur based on button presses. While LabView does have an event handling structure, this state machine can contain states based on button presses, but can also be extended to contain other cases (states) which execute in sequence as specified.

For this post, rather than show the details of every menu, here is the finished block diagram:

This follows the state machine design pattern. The state is tracked with a string via a shift register passed to the case structure each iteration of the while loop. The output tunnel will contain the state chosen for the next iteration. In this example, 4 buttons have been placed on the front panel, and there is a state called "Idle" which should be called when nothing is taking place. In the idle state, the 4 boolean buttons are built into an array which is searched for a "True". Since the Search 1D array function (found under the array menu) will return -1 if no "True" elements are found in the array, the "Idle" state continues until a button press is found (indicated by a search return value >= 0). When this happens, a new state is indexed from the string array constant and passed out of the Idle state on the output tunnel. You can place whatever code you like in the various states for your button presses.


Simon H said...

I love your site but I had a question regarding this template.

Why would you take this approach rather than a producer/consumer approach using the event structure to populate a queue of states which are then executed in another loop?

This way you avoid the CPU drain of polling in the idle case and you are guaranteed to not miss any button presses.

Anonymous said...
This comment has been removed by a blog administrator.
Tony Young said...

The producer / consumer approach would work very efficiently. This post is not yet aiming for efficiency, but just simplicity and understanding of LabView at a basic level. To that end, I have avoided queues and event structures to this point in the lessons.

I think I should start to bring queues and event structures into the lessons moving forwards and perhaps contrast this state machine to its more efficient producer/consumer counterpart.

Of course, you could enhance the efficiency of this example by placing a wait VI call in the idle state, allowing at least 50 ms of non-blocking execution at the OS level between iterations of the idle state.

moose said...

Great site! I'd greatly appreciate reading about queues and event structures. I'm pretty sure I need to learn them from the ground up because right now they puzzle me.

sec said...

I love your site and I want to ask for a help if you can that I have a problem with matrix in LabView.The elements in that matrix is varying with time and how can I create it?I want to input to that matrix from some block output and can I wire to it?

Anonymous said...

Wouldn't it be better to use an Enum rather than a String Array for the cases in the Case Structure? That way it's easier to double check you've covered all your cases and you don't need a default case.

Instrumentation Project said...

I appreciate your blog to share wonderful content that can be very useful.

There was an error in this gadget