LabVIEW
Good way to "Interrupt" JKI State Machine
I know many around here are familiar with the JKI State Machine, and I enjoy it very much for its readability and use of macros. One thing that I run into is how to interrupt a process if something goes haywire. My current application ramps up the power according to a profile, and if something goes wrong (especially while they are still figuring out the profile) I want the user to be able to press abort. Of course, the JKI SM only looks for user events when the state machine is idle, so I have a couple of ideas. Please let me know if you have any others!
1) Set the timeout to 50 or 100ms. My ramp macro would look something like:
Set next power
Idle
Ramp macro
Concern: I don't like polling the event structure
2) I've also got a template where I take the event structure outside of the case structure. The timeout is set to 0 when there are states in the queue, and -1 when the queue is empty.
Concern: You can insert a state whenever you want, not just in the idle case, which could lead to race conditions. I would probably disable controls to address this.
Yes, i needed to do the same thing and didn't like adding an IDLE state to poll the UI either. I moved the event structure into it's own loop and using a queue, I send messages into the JKI statemachine to process the UI events. Inside this VI that I circled, i add the UI messages to the front of the remaining states so that it is processed immediately (for stopping a test, etc.)
THe good thing about this is that when the UI message is first handled in the JKI SM, it doesn't have to actually do the processing right away because you can prioritize the event to happen later. The UI is handled immediately but the event can happen later, at your own whim.
For your ramp up, you would not want to use a loop inside of your state, otherwise the UI event won't be processed until after the state completes. Just call the same state over and over until the ramp up is complete.
Yup with a single loop state machine, I handle it very similarly. I might have a VI that takes several inputs from the big cluster, or take the whole cluster itself and then type def it. Then using logic in the subVI I can determine what I want to set my timeout value to.
So lets say I have a loop that talks to some serial hardware periodically, but I don't want to poll that hardware unless the hardware has been initialized. I'll have a boolean in the cluster labeled "HW Initialized" and in the subVI if that is false then my event timeout is set to -1. But if that is true then I set it to something reasonable like 50ms. Then in my state machine if I close the hardware for some reason all I need to do is also set that boolean to false and now my polling stops. Some times a VI isn't needed and really I just need a select function, select -1 or 50.
Combining this with user events I don't really have a need to poll blindly, I only poll if a user event, or action from the user, did something that sets a variable, that then tells my event structure to perform periodic time outs. Not running a test? Well then hardware shouldn't be initialized, and no polling. Not logging to a file? Then there is no user event telling it to do stuff.
Additional logic can be used too. Like one of my logging modules is for TDMS and I wanted to periodcially defrag the file. So I have the timeout be small (if a test is running), but then in the timeout I have the elapsed timer which is only true if 10 minutes have passed. If it has been that long then go defrag. The reason I don't set this to a 10 minute timeout is because events will cause that timeout to reset, and to not happen.
