LabVIEW
Questions about where to Unbudle and Bundle
I have been wondering lately, as I clean up some code, how much it matters where clusters are unbudled and bundled. Please refer to these two pictures, and, if you could, provide your opinion. Thanks!
Diagram 1
Diagram 2
@Darin.K wrote:
{...}
The lower diagram seems to be asking for an In Place Element Structure.
Yes, it's perfect for that. Ok then, inside or outside the VI? It just seems to me that putting a big control and indicator in the VI is such a waste of.... buttons and whatnot. 
But all this unbundling from a state machine data cluster gets large (in graphical size). Ideally, I'd like to know where the cut-off point is between esthetics and performance, and I'd like to know how some other programmers feel. I remember one time, one of the heavy hitters said that he had stopped being overly concerned with tiny minutiae performance aspects and was building his diagrams to be elegant and maintainable over and above saving an immeasurable amount of speed and memory. Do my two examples fall into the tiny minutiae category?
@broken Arrow wrote:
@Darin.K wrote:
{...}
The lower diagram seems to be asking for an In Place Element Structure.
Yes, it's perfect for that. Ok then, inside or outside the VI? It just seems to me that putting a big control and indicator in the VI is such a waste of.... buttons and whatnot.
With LV10 and onward, you can have your cake and eat it too. Put the IPE inside the SubVI, and set the SubVI to inline automatically and you get the beauty of the subVI and the performance of dumping it all on the BD.
I agree about the minutae, you are usually better off in the long run keeping your code intuitive. As long as your intuition is reasonable, you are fine, and you can wait for an actual performance issue before diving into crazy tweaks that may make a slight difference. Most of these tweaks are becoming outdated anyway. It seems to me that the tide is turning: for a long time we had to do things to improve the compiler's performance, now the compiler is beginning to do things to improve our codes' performance...
I want to thank those who replied, it’s been helpful and enjoyable. I like the InLine option as Darin suggested. If you want to unbundle inside a VI due to real estate or esthetics, that seems like the way to go.
Speaking of “God clusters” (nice one Jeff), most of my programs have a large amount of configuration data that end up in one of those big honkin’ clusters. I’m speaking of the parameters the user sets upon entering the program but are never modified (i.e. static data). These items will be used throughout the program in a dozen or more states of a state machine and in dozens of VI’s, and in parallel loops. What's your preferred method of dealing with this data? Big Cluster, AE, Global, a batch of smaller clusters, dozens of flat S/R's… ??? I have often thought of putting all the “config data” in a large string, and just carry that one string around and parse from it. What I don’t like about that idea is all the data conversion and typecasting that will have to occur. Any thoughts about the string idea?
@Mark Yedinak wrote:
I have been thinking more about an LVOOP option.
I used OOP in my last large project for the configuration data. Not as fancy as what you propose. Just assessors. The advantages were that it was (and still is) the tidiest configuration code I've ever written (you are obviously forced to unbundle only in member VI's) and I liked the fact that each VI just had that neat box as an input rather than a large cluster. (I'm unsure of the memory impact of passing that class into a VI vs.. passing a normal cluster of equal elements, but I like to think that it's less - it's certainly easier on the eyes). Ultimately, I have written subsequent code without OOP because, at times, I want to see what is being passed to a VI by looking at the top level diagram - i.e., as in Diagram 2
