Deprecated Property Nodes

Recommended Posts

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.

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

> 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.

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:

And, then possibly creating a subVI for the data initialization code (setting the default values etc.)?

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:

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!

Share this post

Link to post

Share on other sites

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.

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.