New State Machine 'Run-time Data' structure or Property Node to help new users

[gt3000]

State Machine Sample Projects and LabVIEW courses teach that you can create a 'stack' or 'run-time' data cluster, which is passed to every state via default tunnels and a shift register on the While Loop.  Screenshot from the State Machine in LabVIEW 2017 SP1, below:

Newer LabVIEW programmers need to make a leap from the structure called 'cluster' and the feature called 'shift register' in order to apply them as a very powerful, and now standard, practice of using a cluster to store the data for that State Machine.

My suggestion is that a unique type is added, called 'State Machine data' or 'Run-time data' so that the new user experience is more intuitive for the use of structure that promotes maintainability and readability.

In LabVIEW 201x, this could be something similar to the Channel Wire dialog, to prompt a user to input all their data types up-front, according to their design.

In LabVIEW NXG, this could be a native part of the While Loop, and the user could use the Properties dialog from the right hand side.

Once the 'State Machine Data' is configured, any Case Structure that the data is wired to will populate with a Node appropriate to that environment, such as an Unbundle or a growable Node similar to an Event Structure, in LabVIEW 201x, or a Property in NXG.

I've seen other posts about a State Machine Case Structure hybrid, but that is not what I'm suggesting.  I still believe that primitive structures should be the choice, and I'm focused on getting people to write good code, with less barriers to understanding.

Looking forward to the feedback.

[Manzolli]

State machines are great, I have been using it a lot. A native state machine could make more people fan of this architecture. Liked the idea of having a "native" ubundle/bundle. I do think that the State Machine cluster could start with a single Enum item named "State". Additional items may be added by the programmer, as needed. Kudos!

[JÞB]

OK I use them.  "Them, They, The great and powerful Cluster Domini"  god of all data, god gone mad and user of no elements.

You know... That data gizmo on the Shift Register of your State machine.  

If you HAVE to have one (and you do not) at least use a DVR instead of the data itself.

[AristosQueue (NI)]

I wasn't commenting on the original idea to see how it struck the community. But this comment prompts me to reply...

> If you HAVE to have one (and you do not) at

> least use a DVR instead of the data itself.

Why would you recommend that? I believe you think there's a good reason, but I only know downsides on that road, so I'm curious. DVRs introduce useless performance overhead, remove LV's ability to do compiler optimizations, reduce VI testability, and introduce potential abuse for side effects and race conditions. What positives have you encountered that outweighs all those negatives?

[JÞB]

I wouldn't use the DVR myself either. 

in 95% of the cases where I see a State Machine's Shift Register the data is not consumed by the State Machine itself.  Most often it is passed into and operated on by sub-vis...... Wait, Then what is the data doing in the caller? Making a nuisance of itself and causing data copies in the cases where it isn't easy to make it "In Place"

So Why isn't it a Class? Beats me..... 

Why isn't it maintained on a resource module and hidden from the State Machine? Idunno....

Why doesn't the actor act responsibly and init its own data? Yagotmethere2

>And you do not

[gt3000]

Fundamentally, it is correct that passing the State Data cluster through the caller and into the SubVI functions can cause unnecessary copies and other behind the scenes effects that can be classed as inefficiencies.  That should be taken into account if this idea gets implemented.

The target audience is still users of LabVIEW that may struggle implementing a Cluster with a Shift Register, so I expect jumping to the concepts of Objects and DVRs won't make it easier to have a first time success with the State Machine.

[AristosQueue (NI)]

Jeff: I'm replying out of order to your comments.

> So Why isn't it a Class? Beats me..... 

Oh, that's easy. CEIP data shows only 30% of the LV user base ever creates classes. There's a chunk that uses them and knows what they are but doesn't create them. And then (this is from polling, not CEIP) there's around another ~30% that wouldn't know what one is if you asked them. And about half of those emphatically do not want to know and will be upset if you try to explain.

The AF took the route of encapsulating the state data into a class, and while many embraced that approach, it has met serious resistance in other quadrants (for many reasons, but specifically because it uses classes at all before we even start discussing the merit of how they are used).

> Most often it is passed into and operated on by sub-vis...... Wait,

> Then what is the data doing in the caller?

Well, once you no longer have coherent state of a class (see previous answer) then it makes sense because, well, where else would you store it? You wouldn't want it stored in the subVIs... yes, it should almost always be processed by subVIs. That doesn't mean it should be stored there. The state of the machine will be passed into lots of subVIs, ideally, a different subVI for each state.

> and causing data copies in the cases where

> it isn't easy to make it "In Place"

Improbable. It generally causes copies only where copies would be needed. That's a pretty well optimized pattern of LabVIEW, in my experience.

It's not ideal (in my opinion), but it is ideal in the opinion of a whole lot of other people. 🙂

[JÞB]

@AQ.  WHO would have thunk you and I would be debating these positions 4 years ago?  I agree that the standard SR Clustersaurus as embodied in the JKI SM is approachible.  It is wrong.  

I would not like too make it easier , I'd rather create a template (.vit)

[drjdpowell]

Re the original idea, I think that Clusters and Shift Registers are key concepts in LabVIEW that are much more widely applicably than "state machines", so allowing new programmers to work with state machines without needing to understand Clusters or Shift Registers is not actually in their interest.

> I agree that the standard SR Clustersaurus as embodied in the JKI SM is

> approachible.  It is wrong.  

That's my standard approach and what I recommend.  I would note a key difference between the "Clustersaurus" in the JKI template versus the NI template shown in the OP: it is NOT a typedef, and is never passed whole into a subVI.   It is built by bundling, and is very easy to add things to.   But it is a collection of "everything this loop is remembering", and as such is not a cohesive thing to cross a boundary into a subVI.  Parts of the big cluster may be small typedef clusters or objects, and these are passed into subVIs.  

[AristosQueue (NI)]

Personally, when I choose not to build it as a class (a choice I usually make for UI state machines, for various reasons), I frequently have multiple shift registers instead of a single bundled shift register. I don't have to dig out the data that each state needs, just route the wires through. My code looks like music notation -- straight lines across the top of the frame for all the values that are just passing through, and bends down to this frame's code for the ones that need to be involved in this frame.

I've seen other people who put a sequence structure down and route the unused ones behind the frame -- that's Jeff K's approach. I actually would like that style, personally, as the one exception to the "no wires behind nodes" rule, but my code ends up being used as an example for too many users who might take it as a license to do so more generally. 🙂

[JÞB]

>>I've seen other people who put a sequence structure down and route the unused ones behind the frame -- that's Jeff K's approach. I actually would like that style, personally, as the one exception to the "no wires behind nodes" rule, but my code ends up being used as an example for too many users who might take it as a license to do so more generally. 🙂

Hence: if you HAVE to.... At least use a DVR.  Reasoning: The DVR enforces an in-place data value usage and hides anything that isn't needed in the case's code while at worst, causing a copy of an I32.  

While the current template is approachable, it lacks the ability to enforce that the sub-vi's don't fork the data and leave stale data on the SM SR.  And the new developers just don't see why that is important when starting to use a State Machine.