Good way to "Interrupt" JKI State Machine

[mcduff]

If execution speed is a problem, then make the wait small. There is a queue for events and once its in the queue it will execute immediatley when it goes to the idle state. The only reason to have a longer wait is if you are waiting for someone to press something in the 50ms in between states, or something else to trigger.

I like using the JKI state machine in an "Instrument loop". Since there is an event case there, you can add DAQmx events, which can be extremely useful. I use a change direction event for Digital lines or a buffer full event for AI events.

Cheers,

mcduff

[aputman]

---

@Gregory wrote:

Hi all, thanks for your feedback.

It seems the consensus is that there's nothing wrong with polling the event structure for ~50ms if it fits with the program. This time around I've already started putting my instrument communications into a separate loop with a queue, but I do not like relegating the JKI SM to hardly more than a UI loop, especially with the ability to make macros and the great addons from carmody and bobillier. (Check out CaseSelect and State Editor quick drop plugins if you haven't seen them).

Aputman, you've got a lot going on in that picture! It looks like you modified the "Add State(s)" VI. Does it have an event structure inside?

---

Sorry for the busy BD.  I was trying to show how I handle events with JKI.  My event loop is on the lower edge of the screen.  In it, I send message thru a queue to JKI.  Inside of the circled VI (no, I did not modify the Add States VI.  I created another VI and copied the icon), I am reading from the queue and adding the state at the beginning of the remaining states list.  From there the event is immediately handled by the state machine (assuming there are no long running states, which there are none).  In this way, I don't have to poll the event loop continually using the IDLE state.  

[Gregory]

One thing I thought of instead of directly calling the "Idle" case is to have some string which gets enqueued in the timeout case. Change it to the macro you want called again and again until some condition is met, then change it back to "" (empty). This does mean that the "Add State(s)" VI is called every single timeout, which is not necessary, and you have to make sure that some event isn't happening faster than the timeout rate, otherwise timeout is never called.

[jozeywhales]

Someone asked almost this exact question on another thread:

Emergency Stop During Wait

http://forums.ni.com/t5/LabVIEW/Emergency-stop-during-Wait/td-p/1134638

I have also attached the example code.  Hope this helps

[freemason]

Hi Aputman,

I ran into the same problem.

is it possible for you to attach your code or a sample with event processing separated from JKI SM

Thanks

[aputman]

[Hooovahh]

Oh neat.  Inserting a high priority queue (or user event) state seems like a cool addition to a standard state machine (QMH).  But one consern would be to try to use this feature seldomly.  When you have too many high priority messages pre-empting each other you have a very hard time debugging it.  Still I like it.

[aputman]

Yeah, I don't use it that way very much but it does afford you that opportunity.  I disable/enable controls so that I can control which events can be fired.