Interested in your ideas for improving the JKI State Machine

[Jim Kring]

[cross-posted to NI forums]

 

Hi LAVA'ers,

 

Over at JKI, we've soft-launched a new idea exchange for the JKI State Machine:

 

http://ideas.jki.net/forum/31756-jki-state-machine/

 

I've seeded this with a couple ideas we've heard mentioned before.  If you're interested in providing your feedback on ways to make the JKI State Machine Better, we'd love to hear it!

In addition to feature ideas, we're also interested in knowing what types of design patterns and application examples you'd like to see.

 

Regards,

 

-Jim

[EricLarsen]

I've used the State Machine Template quite extensively, and even modified it to fit the apps I like to write.

 

I've added the following features to the template.  They are really unrelated to the State Machine processing, but more UI related.

 

1.  Create/Open an .ini file in the same directory as the Top Level vi or executable.  Could be the same as the .ini created by an executable, but not necessarily.

 

2. On exit, store the window position of the top level vi in the .ini file.  On startup, restore the window to that position.  This also includes monitor number for multi-monitor systems.

 

3. Use MGI Save Front Panel Data.vi and MGI Resore Front Panel Data.vi to remember control values between runs.  These values are also stored in the .ini file.

 

Basic stuff, but nice additions to most applications.

[Jim Kring]

That's great feedback, Eric.  These are definitely some useful features in Top Level applications.  I have a template with some similar features

 

If you have any more ideas or input, let us know! Thanks.

[Neil Pate]

It would be nice if the template could include a typedef for the main cluster on the shift register, I normally end up creating one.

[Jim Kring]

It would be nice if the template could include a typedef for the main cluster on the shift register, I normally end up creating one.

 

Hi Neil,

 

That's a good idea. One reason we didn't do that, initially, is that we wanted the JKI SM template (that you drop from the palettes) to be free of any dependencies . We're considering creating some templates that will integrate into the project templates wizard that will be a little more elaborate. Including a typedef (or maybe an LVClass?) for the main cluster might make great sense.

 

Anyone here try using an lvclass instead of a cluster?

[drjdpowell]

It would be nice if the template could include a typedef for the main cluster on the shift register, I normally end up creating one.

I actually never do that.  The main cluster is a set of data related by being “stuff this QSM needs”, rather than being a cohesive single thing.  Even when 90% of it is a cohesive thing (and then that part can be an object), there will be extra bits of data (update flags, say) that don’t belong in it.  So I never make the full cluster a typedef or object, even though it is mostly composed of typedef/objects.  

[Neil Pate]

I actually never do that.  The main cluster is a set of data related by being “stuff this QSM needs”, rather than being a cohesive single thing.  Even when 90% of it is a cohesive thing (and then that part can be an object), there will be extra bits of data (update flags, say) that don’t belong in it.  So I never make the full cluster a typedef or object, even though it is mostly composed of typedef/objects.  

So what do you do when you need to execute a reasonably complicated bit of code which requires various bits of "data" in this cluster (i.e. a portion of code that screams out to be made into a sub-VI, which in my opinion is virtually anything non-trivial)?

 

Do you unbundle the specific elements and pass them into a sub VI? I know it may be frowned upon, but by having the cluster typedef'd I then just pass the whole thing into/out of a sub-VI. Of course you could pass in a non-typedef cluster but we know how that is going to end...

[drjdpowell]

So what do you do when you need to execute a reasonably complicated bit of code which requires various bits of "data" in this cluster (i.e. a portion of code that screams out to be made into a sub-VI, which in my opinion is virtually anything non-trivial)?

 

Do you unbundle the specific elements and pass them into a sub VI? I know it may be frowned upon, but by having the cluster typedef'd I then just pass the whole thing into/out of a sub-VI. Of course you could pass in a non-typedef cluster but we know how that is going to end...

Below the top-level cluster I tend to have objects (or arrays of objects) whose methods do the “heavy lifting”.  The typical “state” will unbundle only a couple of things and call a couple of methods.  So I am doing something similar to what you do.  But the problem with the top-level cluster is that it is a grab-bag of everything; UI details mixed with INI file details mixed with analysis details.  It’s not cohesive.  

 

Because the objects/typedefs that make up the top-level cluster ARE chosen to be cohesive, it is rare to need more the a couple of them.  If you find you’re unbundling six things, that’s a good reason to stop and consider if some of them really should be a class/typedef.  But because they really naturally go together.

[hooovahh]

Yup I totally agree with drjdpowell.  I don't have a type def for my BFCluster and just bundle constants of the things I want in there.  It is faster to add an item this way then to have to open the type def and add it there anyway.  I also only take the things I need for the functions I want.  I don't think having a type defed cluster is wrong it's just not how I prefer to develop my code.  This is sorta like private data to this QMH anyway so having all the data available to some other function feels wrong.  I only need to give it the data it needs, which maybe a typed cluster within that cluster but most the time is isn't.

[Neil Pate]

Below the top-level cluster I tend to have objects (or arrays of objects) whose methods do the “heavy lifting”.  The typical “state” will unbundle only a couple of things and call a couple of methods.  So I am doing something similar to what you do.  But the problem with the top-level cluster is that it is a grab-bag of everything; UI details mixed with INI file details mixed with analysis details.  It’s not cohesive.  

 

Because the objects/typedefs that make up the top-level cluster ARE chosen to be cohesive, it is rare to need more the a couple of them.  If you find you’re unbundling six things, that’s a good reason to stop and consider if some of them really should be a class/typedef.  But because they really naturally go together.

OK point taken. I think my uses of the JKI template are much more localised (maybe the word I am looking for is specialised, but even this does not really convey what I mean, perhaps what I just mean is "simple") so my private data in the shift register is a bit more cohesive. I do not have a cluster-saurus with myriad elements.