The JKI State Machine makes it’s public debut

[Jim_Kring]

I’m very happy to announce that JKI has released the JKI State Machine™ to the public as a free download.  This is the very same template that is used by the JKI team, nearly every day, in our products and various projects.

This tool is the direct result of putting some of the best LabVIEW minds together for several years, tasked with the challenge of creating a LabVIEW architectural design pattern that would allow easy coding, readability, and maintenance.  As you might imagine the JKI team has created something truly special that we hope will have a significant impact on LabVIEW users everywhere.

This has been in the works for quite some time and we’re excited that the time has finally come to share this tool with you, now.

Please take this challenge:

1. Download and install the JKI State Machine.
2. Watch this great video tutorial.
3. Take a look at how we refactored the 3-button dialog (VI that ships with LabVIEW) using the JKI State Machine.
4. Tell us what you think.

Thanks!

-Jim

[programmindragon]

Thanks Jim for the free software.  I was recently introduced to state machine programming and am about to use it for the first time in my current project.  After reveiwing this software and the tutorial, it looks as if I might change direction and use this version instead of the generic state machine.  I would, however, like to get other opinions on this version.

Thank you again, Jim.

[Jim_Kring]

---

programmindragon wrote:

Thanks Jim for the free software.  I was recently introduced to state machine programming and am about to use it for the first time in my current project.  After reveiwing this software and the tutorial, it looks as if I might change direction and use this version instead of the generic state machine.  I would, however, like to get other opinions on this version.

Thank you again, Jim.

---

Hi,

You're very welcome.  I'm happy that you're interested in using the JKI State Machine.  I'm certainly interested to hear your feedback, after you've had a chance to use it on a project.  And, I'm interseted in hearing other people's oppinions, too.

Like most things, one solution isn't the perfect fit for all problems.  For example, the JKI State Machine is not designed to be run on LabVIEW FPGA.  It is also not designed to be a real-time solution (it's fast, but not designed for real-time systems).  That said, it performs very well and is extremely flexible and easy-to-use.  It's a great fit, for 99.9% of the use cases that JKI encounters on a daily basis.

Thanks,

-Jim 

[Wiebe@CARYA]

Jim,

Nice template. I would really mis the development time error checking that
you get when using type deffed enums though.

I always try to prevent jumping to several states from one state, since it
is hard to document in a flow chart. How do you do that?

We use our own templates. They are more like application frameworks, in
stead of a vi template. But this state machine will be great for
intermediate users. We finally can reply with a link to something, instead
of saying "use a state machine"!

Regards,

Wiebe.

[Ray.R]

Thanks Jim.

I will certainly have a look at it. 

Good idea Wiebe.  I'll put a tag and point people to this thread..

R

[smercurio_fc]

---

Wiebe@CARYA wrote:

We finally can reply with a link to something, instead
of saying "use a state machine"!

---

There has always been this: Application Design Patterns: State Machines.

The design of this state machine looks very much like the string-based state machine that I had designed back with LabVIEW 4. Same operation, same features. But then, state machines pretty much operate the same anyway. When queues were brought out I changed it to use queues. I am curious to find out if you a specific advantage was seen to use EOL-delineated strings as opposed to a queue. 

[Jim_Kring]

Hi Wiebe,

You're right that you don't get edit-time type checking with a string-based state machine (as opposed to an enum-based state machine) -- the up-side is that you get a much faster/flexible way to work on the state machine (such as having the ability to comment out state strings by prefixing with a "//" or "#", as our state string parser allows).  Also, we do have a special "Default" frame to catch states that are miss-spelled or not in defined in the Case Structure -- this will present a dialog and raise and error, by default.  And, it's possible that we could create some tools to do edit-time checking of the state strings against the Case Structure frames.

Regarding state flow, there is the possibility of creating tooling that helps visualize state flow.  In a post on LAVA, Mikael Holmström posted an example of using the Endevo GOOP Development Suite to reverse engineer a state machine.

 

This doesn't completely work, but it shows an interesting possibility.

Thanks for offering to refer people to the JKI State Machine.

Cheers,

-Jim

Message Edited by Jim Kring on 10-15-2008 09:40 AM

[F._Schubert]

Thank you for sharing Jim

As a fan of the enum based design, I won't start using it rigth now, but the design considerations are really woth a look. I really like the comment states to have the case-selectors more readable, and that's doable with enums as well.

I want to share some of my ideas on the string vs. enum topic (being an enum fan myself as said before).

On an (old) post someone shared the idea of using strings for plugin applications. If the string is not defined (default case) a search in the plugin directory is performed for a vi that matches the 'state' before throwing the wrong typo error.

The one thing I would really like for an enum is inheritance (better multi-inheritance). That goes for state machines as well as for action machines. So I would have a basic state design like <Init, Blank, Idle, Error, Exit> and a child adding <Set, Get> anda Child (orsibling?) <Load, Save>.

I have no need to call it object as long as it allows my to moldularize my code, such as having a interface (checked during developement), e.g.

Error handling 1: <Set error queue, Clear Error, Shutdown>...

Thanks on sharing, again, it keeps my ideas flowing on that issue.

Felix

[Dave_Thomson]

Nice work, Jim.  You've brought together a lot of great ideas.  I'm sure this will serve a lot of people very well, and will inspire others to adopt some of your features in their own state machines.

In particular, I like your "enqueing" VI that allows you to put states in the front or at the back (or both).  And I like the "dequeing" VI that incorporates the error logic.  (My state machines typically have that error logic right on the diagram.  This is a nice way to encapsulate it.)  Althought I, too, am an enum fan, the strings certainly have some great advantages - like appending parameters, commenting them out, etc.  I've often used the cluster of enum and variant idea, allowing any parameter to be associated with the state, but it produces ungainly diagrams, where you're always bundling and unbundling the cluster to get states into the queues, etc.  By leveraging your enqueing and dequeing VI ideas, one could move that hassle off the block diagram as well, allowing the programmer to just drop the state enum and no variant, and have the enqueing VI bundle it with an empty variant when no parameter was supplied.

Cheers,

    Dave

[Wiebe@CARYA]

Jim,

Years ago, I've build my own state machine to flow chart tool. It's made in
7.1, when scripting was still easy... It basically takes a reference to any
VI with "one or more while loops with a case structure in it, and a shift
register wired to the case selector", AKA state machine. The result is a
picture control with states and staight lines or bezier curves between them.
It's a nice gatget, but since scripting is a delicate subject, I never made
it public. It doesn't work with buffered state machines, there are just too
much options...

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.

Regards,

Wiebe.