Question about the JKI state machine

[eberaud]

I downloaded the JKI state machine toolkit and it's quite neat. For eons, I have been using state machines following a very similar structure, but always with enums instead of strings. In simple state machine, each state would define the next one (no queue), and in more complex ones, a queue would be used to allow some states to enqueue several ones (and some wouldn't enqueue anything). But always with an enum or a queue of enums, since it seemed this would prevent typos, and allow renaming a state at only one place (the enum typedef).

 

However I am tempted to make the switch since I see the value in using a tool used by other advanced developer. Where do you stand on this? Is JKI's string-based design the best way for your state machines?

 

Thanks

Emmanuel

[crossrulz]

Who is to say that one way is the best.  It really depends on the developers and the requirements.  There are plenty of debates out there between using an enum versus a string.  But for a framework that is generic, you really have to use a string.

[hooovahh]

But for a framework that is generic, you really have to use a string.

Exactly.  JKI was delivering a framework that is meant to be light weight, flexible, and with as few dependencies and extra steps as possible.  Enums are great, but there is flexibility with strings that JKI wanted.  I don't use it often, but allowing for arguments to be passed is also a handy feature.  I can do something like "Wait >> 100" and have my state wait 100ms.  Or "Close References >> Shutdown" which will close some set of references, but ignore any errors, because we are shutting down and I don't want an error to interrupt the shutdown process.

 

Or how about the steps involved in adding a new case?  It isn't a ton of work with an enum, but it certainly is less work with a string based design.

[drjdpowell]

I used the JKI template for almost every project for about 5 years, till about a year ago when I replaced it with a new design that is very heavily influenced by it.  The new design retains the strings.

[eberaud]

Thank you all for your feedback. I believe using strings require one thing at least: being diligent when naming the states correctly at their creation, since renaming them would require modifying several string constants --> bigger effort and error prone.

 

I'll try to use it in my next state machine! 

[infinitenothing]

And since you don't have type safety, if you have multiple state machine threads, you have to be careful to keep your queues straight and not send your message down the wrong pipe.

[jcarmody]

Thank you all for your feedback. I believe using strings require one thing at least: being diligent when naming the states correctly at their creation, since renaming them would require modifying several string constants --> bigger effort and error prone.

 

My CaseSelect Quick Drop plugin helps manage the JKI State Machine, and it includes a 'rename' function that'll go through your VI and update every instance of the old name.

 

https://decibel.ni.com/content/docs/DOC-24058

[drjdpowell]

Thank you all for your feedback. I believe using strings require one thing at least: being diligent when naming the states correctly at their creation, since renaming them would require modifying several string constants --> bigger effort and error prone.

Or you could just use Find/Replace...

[Ryan Podsim]

Just be careful of spaces! More then once I have found errors in my string based SM due to an extra space in the middle or ,more importanly, at the end of the state name; both in the case structure and the constant defining the next state.

 

Over all though, the JKI SM is a handy too;  but remember it is just a tool, not a end all, be all method.

[MarkCG]

Exactly.  JKI was delivering a framework that is meant to be light weight, flexible, and with as few dependencies and extra steps as possible.  Enums are great, but there is flexibility with strings that JKI wanted.  I don't use it often, but allowing for arguments to be passed is also a handy feature.  I can do something like "Wait >> 100" and have my state wait 100ms.  Or "Close References >> Shutdown" which will close some set of references, but ignore any errors, because we are shutting down and I don't want an error to interrupt the shutdown process.

 

Or how about the steps involved in adding a new case?  It isn't a ton of work with an enum, but it certainly is less work with a string based design.

 

I never use enum state machines anymore. Just too much aggravation to edit the enum for me. Any typos are caught pretty quickly by error handling during testing.

[jgcode]

I would say the most important thing is to give it a go and find out

As for me, I find it easy but more importantly fun to use!

Also, I like creating an API that uses the event structure to communicate with a process and this compliments it well 

[karolek]

I was using JKI state machine for automated testing tool for other labview applications. I made an application which was reading text files with testcases and put them in the jki queue. In that case I could add/edit testcases using just notepad which was extremely effective and easy to use by someone that doesn't know labview.

Here are my tips and things to remember:

1. Put Dialog box in every "Default" case, saying that there is no command like "..." and add Stop to the front of the Queue. App stops and you can just Ctrl+F to find that typo.

2. In the end your main.vi can be looking like massive case structures with a lot of cases. Navigation through them can be tough. Add some empty cases to create comments for some 'sections', or think about grouping cases to have case structure inside another case structure that pointing to some section.

3. Make more ">>" than just one. Create some vi that strip those arguments and pass them further seperately

[hooovahh]

Feedback on the JKI State Machine would probably be better heard on the JKI forum.  As for your comments

 

1. I think the "Default" case could be made to exit.  The only time you should see that error is during initial development, when you try to go to a case that you haven't written yet.  In this case going to exit is not a bad thing because I'm going to want to stop my software anyway to fix the typo or write the case that I meant to have.

 

2. The JKI State Machine already has several sections, for Core, Data, Macro, UI, and even has a template category.  I've seen some others add a "Decision" category and try to limit decision making to go in those types of cases.  After re-reading your comment I see you are talking about cases in cases.  I think this could get confusing.  But honestly I have done it in the past for a group of cases that are similar like "Defer Panel" and "Undefer Panel" but really arguments could be used here..

 

3. This is probably a good idea, but I'd argue that the majority of the time a case has no arguments, let alone N arguments.  The extra overhead of using something like Spreadsheet String to Array on every call of Parse States seems unnecessary.  I'd recommend making a subVI that just takes the scalar string of arguments, then uses Spreadsheet String to Array with the delimeter being ">>" then return the array with white space removed.  Then you can call this VI in the cases where you know you entered more than one argument.

[Chris Davis]

I've used a && between arguments as a delimiter.

[hooovahh]

I've used a && between arguments as a delimiter.

Whatever I guess, I just assumed that you'd continue to use the JKI delimiter of >> Something like:

 

Enable Control >> Save Button >> Exit Button

 

Where this case "Enable Control" could enable a set of controls, but I suppose && could be used just as long as it is clear that is how this N arguments works.

[hooovahh]

Okay attached is a VI that can be used to parse the arguments into multiple arguments.  By default the delimiter is && but another one can be provided.  Saved in 2013.

Parse Multiple Arguments.vi

[Chris Davis]

I would have sworn that I couldn't use >> as a separator for a second argument, but I just did a quick test and it works just fine.  One could also use a comma to separate the values too.

 

I've used the second argument as a modifier for the first i.e.

• Set Disabled Property >> Start && ENABLE
• Set Disabled Property >> END && DISABLE

This kind of capability has allowed me to use a Macro case to enable and disable controls on the front panel via state machine cases.

 

I usually broke apart the argument list using the OpenG Split String and a pair of trim string subVIs.  This subVI is much more generic and can be used with an infinite number of arguments.  Thanks Brian!

[skinnedknuckles]

On 4/21/2015 at 1:43 PM, drjdpowell said:

I used the JKI template for almost every project for about 5 years, till about a year ago when I replaced it with a new design that is very heavily influenced by it.  The new design retains the strings.

What new design did you switch to from JKI State Machine?  Do you like it better?  Why?   I'm currently considering adopting it or Actor Framework or Aloha or DQMH.

[drjdpowell]

17 minutes ago, skinnedknuckles said:

What new design did you switch to from JKI State Machine?  Do you like it better?  Why?   I'm currently considering adopting it or Actor Framework or Aloha or DQMH.

I have my own package called Messenger Library, which is an alternative to those other frameworks.  Within that, my template of a message/event handler is called the DEV Template.  There is a video on the DEV on the Wiki.