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