Jump to content

Interested in your ideas for improving the JKI State Machine


Recommended Posts

[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

Link to comment

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.

  • Like 1
Link to comment
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?

Link to comment
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.  

  • Like 1
Link to comment
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...

  • Like 1
Link to comment
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.

  • Like 2
Link to comment

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.

  • Like 1
Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.