aputman Posted June 23, 2015 Report Share Posted June 23, 2015 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. 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. 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. 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. 1 Quote Link to comment Share on other sites More sharing options...
drjdpowell Posted June 24, 2015 Report Share Posted June 24, 2015 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. 1 Quote Link to comment Share on other sites More sharing options...
Ashish Posted June 25, 2015 Report Share Posted June 25, 2015 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. Quote Link to comment Share on other sites More sharing options...
Tomas Posted March 8, 2018 Report Share Posted March 8, 2018 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). Quote Link to comment Share on other sites More sharing options...
Jim Kring Posted March 9, 2018 Report Share Posted March 9, 2018 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). 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 Quote Link to comment Share on other sites More sharing options...
himanshu Posted November 4, 2019 Report Share Posted November 4, 2019 Hi aputman, I am new to LabVIEW and JKI and I have the same issue. If possible can you share the VIs(modified JKI and the one that puts states in front) Regards Himanshu Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.