"I’d just like to add that in 30 years of my LabVIEW engineering, your software Steve is exactly as I believe LabVIEW is intended to be implemented and a pleasure to start and grow projects upon. I’m getting all my Architects to base their design on your well crafted template so we can easily understand each other’s code today and ten years from today.
LabVIEW essentially has a front panel for the user and under the lid an area to craft good or bad code. Bad code used to just be messy, now I think bad code is also made up of over abstracted objects .. which can result in code equivalent to a ‘potted’ car engine under the hood rather than one where you can see the vital moving parts and wires."
I love this analogy and it's something I've been alluding to more and more of late, I think you should see some moving parts and wires to help understand the design.
"Really like the way the state machine isolates the activities going on in each state. It pays back at the back end of the project when you need to make late changes. As the logic is isolated we were able to make clean changes with little risk of unpredictable issues. Also I had to move a graph completely into another vi running on a separate screen. Having the screen updates decoupled made this straight forward."
I honestly think that of all the things I've designed/stolen over the years, using a QMH to decouple screen updates is the most useful.
To explain briefly...
You have a QMH that receives UI update messages like this as part of your main screen.
And this allows you to set the screen from any subvi in the hierarchy like this..
The point of this is to allow changes late on in a project and without affecting the integrity of the project.
I'm thinking of a doing a webex type session where I run through our template and how to use it, is this something of interest? I'm thinking of a Bob Ross style painting session, informal and with lots of interruptions. Email me on firstname.lastname@example.org and we can work out a date if there's enough interest.