10-17-2008 04:51 PM - edited 10-17-2008 04:53 PM
I did use a buffered sm once. I created one VI that is very usefull. The VI
takes the states, and a new state, and two booleans. The booleans are called
"Add before?" and "Add after". The name should explain enough. The (very
simple) vi makes it very easy to add cases based on a condition. It really
clear up the diagram. Perhaps you already have something like it, but I
didn't see it in the video.
Hi Wiebe,
Here is how we handle this with the JKI State Machine:
With the JKI State Machine, appending or prepending an empty string has no effect. So, we can use the Select function to route conditional work into the Add State(s) to Queue function. I can see how it would be useful to encapsulate this logic (conditional) into a single function. Perhaps we could achieve this by adding a Boolean input to the top of Add State(s) to Queue.
-Jim
10-17-2008 07:31 PM
Update: We've recently posted another video showing how to use the JKI State Machine to refactor sequencial code:
Cheers,
-Jim
04-26-2010 03:06 AM
I decided to use the JKI State Machine for one of my applications.
It has caused continual crashes of LV 2009 Service Pack 1. The result has been that I have lost work.
Is there a solution to this problem?
04-26-2010 07:54 AM
BTW I want to state that the JKI state machine is a great tool, and I think, better than enum state machines. I will post the error codes etc from the crashes with LV 2009 SP1.
I also have a question:
How do I flush the queue?
I have a series of states which are appended to the queue. At an intermediate state there is an error. This causes the execution to proceed to the error handling state and the error is currently cleared. The problem is the following states which are still in the queue continue to execute afterwards.
04-26-2010 08:47 AM
The queue is effectively the string that is leaving the case structure, you can in case of an error just sent en empty string (or a more appropriate action) to the shift register.
It's quite strange you get errors, since the code in the helper VIs is basic LabVIEW
Ton
04-26-2010 09:29 AM
battler. wrote:I decided to use the JKI State Machine for one of my applications.
It has caused continual crashes of LV 2009 Service Pack 1. The result has been that I have lost work.
Is there a solution to this problem?
I haven't seen this issue but would be interested to learn more and take a look at any details you have. If the crash is reproduceable, please post a VI that demonstrates it, so that we can try to get NI to see what's wrong.
Thanks,
04-26-2010 05:58 PM
TCPlomp wrote:The queue is effectively the string that is leaving the case structure, you can in case of an error just sent en empty string (or a more appropriate action) to the shift register.
But this string may comprise several actions which are fed in succession to the case structure, not all at once. Correct?
I have read in the JKI docs that passing an empty string to the "enqueue" does nothing. Does it clear the queue (string)?
It's quite strange you get errors, since the code in the helper VIs is basic LabVIEW
I had several errors and have noticed strange behaviour surrounding the JKI state machine. For example, when I add a new state (case) and adjust the case text I lose text focus. For some reason I have avoided any more crashes by continually (after ever single change) saving. LV made a log file of the previous crashes but I havent dug them out. The worst thing is the crashes were unrecoverable.
04-27-2010 03:55 AM
battler. wrote:
TCPlomp wrote:The queue is effectively the string that is leaving the case structure, you can in case of an error just sent en empty string (or a more appropriate action) to the shift register.
But this string may comprise several actions which are fed in succession to the case structure, not all at once. Correct?
I have read in the JKI docs that passing an empty string to the "enqueue" does nothing. Does it clear the queue (string)?
Yes it clears the queue, the string contains or is the queue. Sending an empty string is like flushing the queue.
Ton
05-06-2010 06:28 PM
Hi all,
I have an application consisting of 4 sub-apps and 1 main app which calls the 4 sub-apps via subpanels. See this thread.
I have converted the 4 sub-apps to use JKI string-based state-machine (SM). The main reason was because of the handy >> Argument statements.
I now realise (and I hope I can be proved wrong) a major disadvantage of not using a standard queued SM.
I need to be able to send commands to the 4 sub-apps from the main app. I want to enqueue commands into their queue (i.e. to get them to close, update their associated action engines etc).
If my sub-apps have a named queue then I can enqueue elements into their queue from the main app. How can I modify the JKI SM to allow me to do this?
Your help is much appreciated.
Battler.
05-07-2010 12:27 AM
There is no limitation at all.
Lots of ways to skin the proverbial cat:
One way is to create a User Event and use dynamic events to communicate to the Event Structure (this is my preferred method).
Another way is to periodically check a State (e.g. Idle: Event Timeout Case) that polls a Traditional Queue that could read in a Command/Data.