Jump to content
aputman

Processing events in JKI state machine

Recommended Posts

I really like this template. It works great, is easy to use, easy to debug, keeps things well organized, etc, etc, etc. The one issue that I have with it is how it processes events. I do not like the event structure being inside the idle case. This one particular app I wrote runs test sequences consisting of multiple states back to back (essentially a macro). If the user presses the ESC key, they can interrupt the test sequence and skip to the end. To implement this, I had to poll the IDLE case in every one of the states of the test sequence to see if this event had happened. I didn't like doing that so I removed it and I thought I would share how I did it. I like this method much better because it will process the events as they happen but can also, in a way, prioritize the events.

 

So obviously, I had to pull out the event structure and place it in its own process loop. You'll notice the UI Event queue for passing states to the state machine.

post-28989-0-41210800-1435069862.png

 

Next, I create a VI that reads from the queue, with a very small timeout, and adds the event state to the front of the JKI state queue.

post-28989-0-56709400-1435070308.png

 

This VI goes in front of the Parse State Queue VI so that the event is added to the font of the state queue. And within the state machine, I added a UI: Process Event state that accepts two arguments: first is the control and the second is the value associated with the control action. This works for my application but may need to be changed for other needs. Within the state, I can now determine whether to process the event immediately (as in the case of the ESC button scenario that I mentioned above) or I can choose to add another state to the end of the queue to be processed after the current queue is empty.

post-28989-0-72145100-1435070044_thumb.png

 

I think this method keeps the UI responsive and doesn't require the additional requests to the IDLE states scattered throughout your program. I would definitely suggest enabling and disabling controls to only allow events to happen that make sense at that point in time. This would prevent a flood of events being added to the front of the queue if the user decides to go on a clicking spree.

  • Upvote 1

Share this post


Link to post
Share on other sites

Note that if you do this you are committed to making sure that any sequence of “states” you call must be able to handle any possible external interruption at any point. In other words, you must be super vigilant against race conditions. With the “idle” method, one can choose where in a sequence of steps one will accept outside input.

 

For example, if you had the macro:

 

Take Data

Analysis Data

Save Analysis

 

and also a “Set Parameter” event that changes a parameter used in Analysis and Save, then you have a race condition where the analysis may be saved with a different parameter value, if the “Set Parameter” happens between Analysis and Save.

  • Upvote 1

Share this post


Link to post
Share on other sites

aputman,

 

Thanks for summarizing your observations and the solution that helped leverage JKI State Machine architecture to meet your needs.

 

As drjdpowell pointed out, there are certain tradeoffs as well. So, it all depends on the use case.

 

Certainly, your suggestions will be useful for many JKI State Machine users in similar situation.

Share this post


Link to post
Share on other sites

Hello, I'm also dealing with this. Could you share an example of how to do it.

Other feature I think is missing,  is to have an optional timer around  ( just like events).

 

JKI State Machine Timer.jpg

Share this post


Link to post
Share on other sites
23 hours ago, Tomas said:

Hello, I'm also dealing with this. Could you share an example of how to do it.

Other feature I think is missing,  is to have an optional timer around  ( just like events).

 

JKI State Machine Timer.jpg

Hi @Tomas

Can you explain what, in particular, your "dealing with"? I'm curious about the challenge your experiencing.

Also, the timer is interesting. What do you use it for? It looks like it's a shift register with the time the JKI SM started running? Any reason not to put this into the main data (cluster) shift register?

-Jim

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.