How should superstates be implemented?

[Jason_P]

OK - let me preface this by saying I don't have the statechart module, so I may be asking a really obvious question... But I'm curious about the how to properly implement super states in a LabVIEW state machine.  Imagine an application that dynamically loads several plugins (which are queued state machines) when started.  Depending on the user's actions, each plugin could be in the active or inactive super state at any given time.  Depending on which super state the plugin is in, a completely different set of sub states is required.

I'm not actually looking for a specific solution to a problem, but more of a general discussion of good state machine programming practice.  Is there a clever way to implement super states that I'm unaware of?  How do the hardcore LabVIEW experts (CLAs) do this?

Thanks,

Jason

[Ben]

Hi Jason,

Since I started with computers before they invented terms like "Super State" I may be off the mark, so forgive me or edify if so.

otherwise take a look at the documents I posted here showing State machines within State Machines.

Note:

I posted both word and a ppt with the full details, so don't just look at the linkied image.

Those documents show two applications. One used to test catalysts that will be used in hydrogen fule cell vehicles and the other is to test TPV (Thermo-Photo-Voltaic) diodes.

Just trying to help,

Ben

Message Edited by Ben on 07-23-2009 10:32 AM

[Jason_P]

Hi Ben,

Thanks for the docs - You are exactly the level of developer I was hoping would respond!  But I guess I wasn't clear in my question.  Let me rephrase:

One of the developers I work with was given a traditional state machine diagram for a process that looked like it was devised by an insane spider on crack.  Lines running everywhere and overlapping like crazy.  To make sense of it, he ended up redrawing it as a Harel-type state machine with superstates.  Same information, but with a remarkable improvement in readability.

It got me thinking that maybe there might be something analogous in how state machines are represented in the labview block diagram.  I have written applications that are very intuitive when thought of in terms of superstates, but I had to code them in a flat state machine representation.  In one such app, I ended up using queued state machine with a queue manager.  The queue manager would either pass or reject state requests depending on which superstate the program was in.  It worked fine, followed official LV style (as far as I can tell), but you had to dig into the queue manager to interpret behavior.  I can't help feeling that this will be a problem for the next guy, no matter how well documented.

What I'm hoping to learn is whether or not other developers may have already solved this problem (or if it even is a problem from their perspective).  If there is already a recommended block diagram template that can intuitively represent the super state concept, I'm dying to see it...

Thanks,

Jason

[Ben]

---

Jason P wrote:

Hi Ben,

Thanks for the docs - You are exactly the level of developer I was hoping would respond!  But I guess I wasn't clear in my question.  Let me rephrase:

One of the developers I work with was given a traditional state machine diagram for a process that looked like it was devised by an insane spider on crack.  Lines running everywhere and overlapping like crazy.  To make sense of it, he ended up redrawing it as a Harel-type state machine with superstates.  Same information, but with a remarkable improvement in readability.

It got me thinking that maybe there might be something analogous in how state machines are represented in the labview block diagram.  I have written applications that are very intuitive when thought of in terms of superstates, but I had to code them in a flat state machine representation.  In one such app, I ended up using queued state machine with a queue manager.  The queue manager would either pass or reject state requests depending on which superstate the program was in.  It worked fine, followed official LV style (as far as I can tell), but you had to dig into the queue manager to interpret behavior.  I can't help feeling that this will be a problem for the next guy, no matter how well documented.

What I'm hoping to learn is whether or not other developers may have already solved this problem (or if it even is a problem from their perspective).  If there is already a recommended block diagram template that can intuitively represent the super state concept, I'm dying to see it...

Thanks,

Jason

---

I think I can best serve you by pointing you at LAVA.

There are many "drinkers of the green Kool-aid" that swear by that type of architecture. One of my developers makes a living maintaining one of those that was developed by our customer. he could not keep track of what was happening where and finally settled on paying us to do that work for him. I feel for my co-worker when he has to trace back a state stack with 20 or more states. I tried starting a conversation on LAVA once asking "is the day of the QSM behind us?" only to find I was "using fighting words' by suggesting as much.

In my case, I have to present a solution "on paper" that the customer belives will work before I drop node #1. I can do that with flat (well almost) state diagrams or UML.

I am still waiting for someone to illustrate how to document a QSM.

Waxing philosophical:

I used to program in machine language where I had to push and pop to/from a stack so I understand how old timers could gravitate toward a QSM since the idea are similar. But in my case I moved to LabVIEW to allow me to right bigger apps faster becasue I can "stay high-level". Judging by the QSMs that have crossed my desk, I still think the QSM is an idea that is history.

So try LAVA. I think Jim Kring recenlty released a framework to support that design patern.

Ben

[Jason_P]

Ben,

Thanks for the pointer.  I've poked around over there, but this forum has always been my labview home base.  So far I've only sipped the kool-aid!

I agree that its difficult to see how to maintain the QSM.  That was why I was asking if there was something better that people were using and I hadn't heard about.  I'm open to any approach that solves the problem - provided it doesn't create other problems.

Thanks,

Jason

[MichaelAivaliotis]

Personally, I think those that hang out on the NI Forums are the ultimate Kool-Aid drinkers.  But in any case...

Have you seen the JKI State Machine? It's free. Here's the link:  http://jkisoft.com/state-machine/

I've been developing in LabVIEW my entire career and swear by that approach. It's been battle tested in dozens upon dozens of projects that i've worked on.

Have Fun! 

Message Edited by Michael Aivaliotis on 07-23-2009 09:25 PM

[Ben]

---

Michael Aivaliotis wrote:

Personally, I think those that hang out on the NI Forums are the ultimate Kool-Aid drinkers.  But in any case...

Have you seen the JKI State Machine? It's free. Here's the link:  http://jkisoft.com/state-machine/

I've been developing in LabVIEW my entire career and swear by that approach. It's been battle tested in dozens upon dozens of projects that i've worked on.

Have Fun! 

Message Edited by Michael Aivaliotis on 07-23-2009 09:25 PM

---

Oh Look who has peaked over the wall!

Michael,

You are such a sweet talker. Now I am embarased. Please note I did allude to the JKI State Machine but not by name.

Ben

[Ben]

Back on topic...

This link does not work for everyone but maybe it will work for you. If it works you will find an html representation of an app I did back in about LV 6i or there abouts. It is very simple program that collects data from three different interfaces. Let me confess that code was from when I was still a "wee-G-babe" and I have llearned a lot since then as well as LV getting a lot of new features like polymorphic queues etc.

If I was doing that app now I would use queues instead of Action Engins to pass data and I would use enum state machines instead of string driven.

If I am getting closer to helping let me know. This is a learning experience for me so bear with me.

Ben

[Jason_P]

Ben - I started to look at your docs, then realized I need to take my time with it to understand everything.  You are definitely helping.  Just seeing how someone else is thinking will help my own style - and at the same time, I am learning all about how to rigorously document LV code! 

I had seen the JKI state machine, and I like it - I'll probably refactor one of my own apps with it as a test in the near future.  But the arguments about documentation in the old lava post seemed valid to me.  For my own QSM, I had to create a state-logger VI to trace the execution when I ran into a bug.  There was no easy way to see what was going on.  In the end, it was an unintended transition that was happening by default.  If I had better coding skills, it wouldn't have happened - but a better structure might have made it more obvious that I was doing something wrong before it blew up.  This is really what prompted me to look for a structure with the functionality and flexibility of the QSM and yet was easily traceable. 

Thanks,

Jason

[Ben]

---

Jason P wrote:

...For my own QSM, I had to create a state-logger VI to trace the execution when I ran into a bug.  There was no easy way to see what was going on. ...

Thanks,

Jason

---

 My point exactly! Trouble shooting one of those is like try to chase a crash dump back to the offending code.

I'll try to find some more examples that I can post in public that are more current. The one I am about to deliver would be good but the paying customer should really be the first person to see his code. After all, if I post it, why would he bother paying me?

Ben