Jump to content


Photo

Deprecated Property Nodes


  • Please log in to reply
6 replies to this topic

#1 hooovahh

hooovahh
  • Members
  • 65 posts

Posted 18 March 2015 - 05:57 PM

It is a known issue that the current JKI state machine uses deprecated functions for the Front Panel Open?  Is this an issue that needs fixing?  

 

The latest version of the state machine was released in 2008 according to the copyright on the package information.  So is there plans to update this state machine to use non-deprecated functions for modern versions?  This would also be a good time to add any features and updates in a new release.


  • 1
"40 dollars!? This better be the best damn beer ever.. [drinks beer] You got lucky. "
"Whoah, someone smells stinky! Oh, its me. "

#2 Jim Kring

Jim Kring
  • JKI Team
  • 1,267 posts

Posted 18 March 2015 - 07:00 PM

Hey Brian!

 

Thanks for taking the time to comment on this. The JKI State Machine was just open sourced and we *are* currently looking at possible new features and updates.

 

Are there some things you're especially wanting? :)

 

-Jim


  • 0

#3 hooovahh

hooovahh
  • Members
  • 65 posts

Posted 18 March 2015 - 08:38 PM

Are there some things you're especially wanting? :)

Why yes, yes there is.

 

So at my previous company we made our own QMH+.  I thought about using the JKI but at the time I thought arrays were superior to a string that has return characters in it.  My reasoning for this was figuring a delete from array would have less over head than the Parse State Queue which has lots of string manipulation.  I'm not sure I care so much and a single string is probably just fine.  But for the record I'd prefer an array of string.

 

Another difference I had was all state machine loops pushed data to a central DVR in a functional global.  This of course could have a taste of OO but at the time it didn't.  What this allowed me to do is have a way to access all loops in an application that were running.  So when my VI was running I could go to Tools >> Debug QMH and a window would come up showing me all state machines being ran, what states were being enqueued and dequeued, along with the delta time between each step.  This way I could see how much time each state machine was in each state.  This helped improve speed by finding where the states taking the most time were.

 

This DVR Global also had the ability to log this state changing data from state machines.  Then even if my application crashed I'd have a log of what states each loop went to leading up to the crash.

 

The ability to log, or probe a state machine could be turned on and off using that same DVR global.  By default both log and probe were off for efficiency.  But this could be turned on from the built EXE by going to Help >> Debug Application >> Debug QMH which called a VI that I made to enable or disable these debugging features.

 

The JKI state machine is simple by design.  So I'm sure it is difficult to say how many features you want to pack into it.  And some of the ones I mentioned might not seem like a good fit.  But I just figured over the last 7 years the state machine could use some kind of tweaks or improvements.


  • 1
"40 dollars!? This better be the best damn beer ever.. [drinks beer] You got lucky. "
"Whoah, someone smells stinky! Oh, its me. "

#4 Jim Kring

Jim Kring
  • JKI Team
  • 1,267 posts

Posted 19 March 2015 - 05:00 PM

These are all great ideas, Brian. I was sitting next to another JKI engineer on the plane-ride home from the America's CLA Summit and we were discussing similar things.

 

In particular, we discussed the importance of being able to log states and turn this on/off dynamically. I've got some ideas for how this might be accomplished.

 

Also, I think that the JKI State Machine Objects design pattern can possibly address some of the other needs for sharing data and communicating across multiple processes.

 

I've got some more work to do to get the examples/templates out and get some videos posted. Stay tuned and thanks for being part of this conversation and development.


  • 0

#5 hooovahh

hooovahh
  • Members
  • 65 posts

Posted 20 March 2015 - 12:16 PM

I should probably make a new thread for this too, but the state machine could used some Linked Input Tunnels for the cluster of data, string states, and error data, through the case structure and event structure

 

Also I'm a fan of having cluster initialization happening outside the while loop.  This is the stuff normally found in the Data: Initialize.  I tend to have lots of data and it doesn't always fit in that case.  Adding it on the outside also makes it easier to add new data.  This also cuts down on the number of uninitialized shift registers which can lead to problems if you aren't careful.

 

Which brings me to another possible improvement.  The error shift register could have an Error In on the input instead of being uninitialized.  Oh and if you do add an error in, it would be nice to have an Error Out, and to wrap the while loop in a case structure that does nothing if there is an error coming in.


Edited by hooovahh, 20 March 2015 - 12:20 PM.

  • 0
"40 dollars!? This better be the best damn beer ever.. [drinks beer] You got lucky. "
"Whoah, someone smells stinky! Oh, its me. "

#6 Jim Kring

Jim Kring
  • JKI Team
  • 1,267 posts

Posted 20 March 2015 - 05:03 PM

> the state machine could used some Linked Input Tunnels for the cluster of data, string states, and error data, through the case structure and event structure

 

We considered that and it might still is probably a good idea to add this. The reason we never added this (besides it not existing in earlier versions of LabVIEW) is because we generally use the Duplicated frame feature instead of Adding a new frame; so that the nodes, comments, and coloration are automatically copied.

 

For example, when a new category is created, you can copy the "New Category" frame and get the comment, coloration, and Add States node for free.

 

2015-03-20_09-31-52.png

 

That said, there's no reason that these are mutually exclusive (the tunnels can be linked and we can promote the best practice of copying frames rather than adding them).  I've also been thinking that it'd be good to have a JKISM helper tool for adding new frames, so this issue would become moot.

 
> Also I'm a fan of having cluster initialization happening outside the while loop.  This is the stuff normally found in the Data: Initialize.  I tend to have lots of data and it doesn't always fit in that case.  Adding it on the outside also makes it easier to add new data.  This also cuts down on the number of uninitialized shift registers which can lead to problems if you aren't careful.
 
I'm assuming you're referring to having a typedef'ed cluster like this:
 
2015-03-20_09-51-35.png
 
And, then possibly creating a subVI for the data initialization code (setting the default values etc.)?
 
2015-03-20_09-53-50.png
 
This is another good idea. The reason we didn't do that in the template, is because we wanted the template to be merge-able (and not have any subVIs that required modification), so that it could be dropped onto the block diagram. We do have templates that have the data initialization outside the loop in a subVI. It's relatively trivial to create a constant, convert it to typedef, and wrap in a subVI.
 
> Which brings me to another possible improvement.  The error shift register could have an Error In on the input instead of being uninitialized.  Oh and if you do add an error in, it would be nice to have an Error Out, and to wrap the while loop in a case structure that does nothing if there is an error coming in.
 
Another great idea! We didn't do this in the template that gets dropped from the palette, but we have other templates that do have this, such as the Process.vi template in the JKI State Machine Objects:
 
2015-03-20_09-55-23.png
 
We didn't add it to the template in the palettes, since it's so easy to add. But, I'd be curious to see in practice how often people would want to add this error handling "harness" vs. people who would want it removed.
 
Great discussion! 

  • 0

#7 hooovahh

hooovahh
  • Members
  • 65 posts

Posted 23 March 2015 - 11:58 AM

All very good stuff, and thanks for explaining some of the reasoning used.  I generally don't use the Duplicate Case, because I like where in the case my new case should be.  Like I may want "UI: Update UI" to appear after "UI: Defer Panel" because generally Update UI happens after a Defer, so I will use the Add Case After to ensure my order is what I want.  If I use a template case and duplicate it I then need to perform another step to rearrange the cases.  But I could change habits if it means things like the Add States VI comes along.

 

The only other thing I'd like to say is on the cluster initialization.  I agree to keep dependencies like a subVI and type def'ed cluster to a minimum for templates like this.  What was I suggesting was more like moving the bundle and the init data outside the while loop like this.

 

Init Cluster JKI.png

 

This could be a user preference thing.  Because this way it is easier to quickly see the init values without having to change states, and it is easier to add new data.  But this does make the template wider.  For me it doesn't mean I need to make my window larger.  This could mean a horizontal scroll is used to see the init data.  This doesn't seem ideal for a template because a first time user of it might be confused not being able to see everything.

 

Honestly I could see making my own modified JKI state machine that moves the bundle and makes a few other modifications that might be user specific preferences.  Like I don't like the return key toggleing the OK button causing an exit.  If anything I use Escape to exit.


Edited by hooovahh, 23 March 2015 - 11:59 AM.

  • 0
"40 dollars!? This better be the best damn beer ever.. [drinks beer] You got lucky. "
"Whoah, someone smells stinky! Oh, its me. "