State Machine Queue's and Events

[bluesky]

The state machine solves a lot of the most common problems encountered by Labview developers and will be very helpful in developing new vi's.. I am interested in how you expand this structure to handle queues and front panel events.

[Omar Mussa]

I am interested in how you expand this structure to handle queues and front panel events.

 

I'm not sure I understand what you mean by 'handle queues'. In terms of handling front panel events, there is a case "Idle" in the template that has an event structure to handle front panel events. In applications where we've created custom user events, we tend to add a category called 'Events' and add 'Events: Register' and 'Events: Unregister' cases.

[bluesky]

Omar,

 

Thanks for the quick reply,

 

In regards to front panel events, since the front panel event structure only runs during the idle state doesn't the user experience a visible response lag if the previous state(s) require a considerable amount of time to run? ie: The state machine doesn't enter the idle state because its still busy processing. Isn't it better, from an end users point of view, to service the front panel with its own dedicated State Machine or event structure and then enqueue the user commands / data to other state machine(s) for processing? The processing time of the additional state machine(s) then do not interfere with front panel response times.

 

As to queue's: I have a rather large vi that uses queues to transfer data between multiple while loop structures. Is there a way to extend the State Machine to allow for passing data via queues between multiple State Machines?

 

Thanks,

[Omar Mussa]

Omar,

 

Thanks for the quick reply,

 

No problem, thanks for your interest in the JKI State Machine

 

In regards to front panel events, since the front panel event structure only runs during the idle state doesn't the user experience a visible response lag if the previous state(s) require a considerable amount of time to run?

 

That's an architectural/design question really. At JKI, we tend to use GOOP architectures (we have many flavors we've used) and we generally use an asynchronous process spawned by a GOOP object to handle heavy duty processing. This prevents our users from experiencing 'Lag'. Generally, if the states can execute in an event driven way -- with as little polling (if any) as possible, the UI will feel responsive.

 

As to queue's: I have a rather large vi that uses queues to transfer data between multiple while loop structures. Is there a way to extend the State Machine to allow for passing data via queues between multiple State Machines?

 

First, you might want to consider using LabVIEW User Events for passing data instead of queues, that way your UI will never be polling. That being said, if you do use queues, generally you check the queue for new elements in the 'Timeout' frame of the event structure. If data is on the queue, you extract it and push it into your application data cluster and/or send your state machine to a state based on the queue data.

[crelf]

The state machine solves a lot of the most common problems encountered by Labview developers and will be very helpful in developing new vi's.. I am interested in how you expand this structure to handle queues and front panel events.

The JKI State Machine is based on a state machine architectural pattern, but I'm sure that it's not the only pattern that JKI uses. Your application might not be appropriate to be implemented using a state machine pattern, and might fit better into a producer/consumer pattern (that may, by the way, include the state machine pattern within it, or be part of one ).

[Omar Mussa]

The JKI State Machine is based on a state machine architectural pattern, but I'm sure that it's not the only pattern that JKI uses. Your application might not be appropriate to be implemented using a state machine pattern, and might fit better into a producer/consumer pattern (that may, by the way, include the state machine pattern within it, or be part of one ).

 

You are correct on all points (per usual ).

[Jim Kring]

Omar,

 

Thanks for the quick reply,

 

In regards to front panel events, since the front panel event structure only runs during the idle state doesn't the user experience a visible response lag if the previous state(s) require a considerable amount of time to run? ie: The state machine doesn't enter the idle state because its still busy processing. Isn't it better, from an end users point of view, to service the front panel with its own dedicated State Machine or event structure and then enqueue the user commands / data to other state machine(s) for processing? The processing time of the additional state machine(s) then do not interfere with front panel response times.

 

As to queue's: I have a rather large vi that uses queues to transfer data between multiple while loop structures. Is there a way to extend the State Machine to allow for passing data via queues between multiple State Machines?

 

Thanks,

 

Hi bluesky,

 

Putting UI event handling and work sequencing into separate while loops means that you cannot easily share statefulness between the two loops (using the shift register of state machine data). Generally, this statefulness is important when processing UI events. But, this does introduce the problem of work that takes a long time. There are a couple ways to deal with this:

 

1) Put the work somewhere else: maybe into another asynchronous while loop, as Omar suggested.

 

2) If you are building up a long sequence of work (multiple consecutive states), interleave some "Idle" states in there to service the Event Structure. Note that this requires that you have an Event Structure timeout other than -1 (Wait Forever) so that if there are no UI events your state machine will keep processing commands.

 

In either case, you may want to implement some user interface interlocking (disabling of certain UI controls or all UI controls via setting the cursor to busy), which will lock out certain UI elements until the work is complete.

 

We'll create some other examples, soon, that demonstrate how we recommend handling such things.

 

Regarding your specific question about queues, one way that we can do this is to service a queue periodically inside the Event Structure's "Timeout" case, as shown below (note that this requires making sure that the Event Structure does not wait forever):

 

 

But, as Omar also mentioned, at JKI we prefer to use User Events. We've got some interesting examples/templates that do this, too. Expect more exciting things to come!

 

-Jim

[crelf]

You are correct on all points (per usual ).

[Jim Kring]

Hi Jim,

 

Great example of a state machine, and good for general sub vi tasks.

 

In the past I have used similar state machines to implement user interfaces, but I am now tempted to try a producer/consumer architecture.

Can you highlight some of the advantages/disadvantages of each approach/architecture?

Does JKI use producer/consumer architectures for programming? Are you willing to share these with us?

 

Thanks in advance for your help

Cheers

Ian

 

Hi Ian,

 

Thanks for taking the time to try out the JKI State Machine and for your feedback!

 

The (relatively) short answer to your question is this...

 

Think of the JKI State Machine as a foundational, fundamental structure that you can use to implement higher-level patterns. Sure the string-based state "queue" can be thought of as being produced and consumed by the JKI State Machine, but let's just ignore that for now and think about how we could use this structure for higher-level messaging between JKI State Machines. For example, we could use the JKI State Machine to create the following different structures:

 

UI Event Consumer - In the JKI State Machine, subscribe to UI events, by registering for implicit events (in the Edit Events dialog) of controls on the Front Panel of the VI that contains the JKI State Machine.

 

User (Dynamic) Event Producer - In the JKI State Machine, call Generate User Event to produce (publish) an event that one or more User Event Consumers is registered to receive (using a Register For Events function).

 

User (Dynamic) Event Consumer - In the JKI State Machine, call Register For Events and the Dynamic Event Terminal to register the JKI State Machine's Event Structure to subscribe to User Events that are generated by some User Event Producer (or other location that might generate the event).

 

If needed you can also uses Queues and Notifiers, rather than User (Dynamic) Events, to deal with the limitations that LabVIEW has in managing the UI Event and User Event "queues", such as the inability to flush or limit the size of the event "queues". Side note: IMO, this is a huge limitation that, if addressed, would make User Events much more... er... usable.

 

One point that we should mention is that one JKI State Machine might fall into more than one of the categories, above.

 

It should also be noted that these various JKI State Machine incarnations (above) can be encapsulated inside GOOP (object-oriented programming) or other by reference (including singleton) class/component design patterns.

 

We'll be talking more about this, in the near future.

 

Thanks,

 

-Jim

[benhysell]

Hi Jim,

 

Thanks for the reply.

 

I look forward to seeing more information/examples in the future, particulary regarding GOOP encapsulation - something else I have been considering trying to implement.

 

Cheers

Ian

 

 

+1

[Jim Kring]

+1

 

Thanks for the ping on this topic, Ben. I'll try to get the JKI Team to put out some JKI Software Blog articles on tips, tricks, and design patterns for the JKI State Machine.