LabVIEW Idea Exchange

[#1]

Who has ever made a cluster typedef, then added some elements, then added more, then a little more? Have you noticed the "typedef explosion" of your block diagram as a result, with constants overlapping other code? Make a right-click option to "link" a bundle by name to a typedef. Note that the two pieces of code below would be identical, but the bundle on left would not suffer from typedef explosion. In addition, have a selectable menu

Another idea is to link the bundle to the destination:

[#2]

Edit: For the picture on top, the bundle on the RIGHT (not left) would not suffer from typedef explosion.

[#3]

Personally I don't like the idea of 'linking' to a type def since it would be hard to no which type def you are linked to.

However, I do hate the 'explosions' as well, especially if you have painfully auto arranged all the clusters in the typedef to be horizontal and when you make a change to the type def (don't even have to add an item) it defaults back to vertical arrangement.

You can get around that and the amount of space that they take up by selecting the constant and creating a SubVI for it. That way you can give it a nice icon,and if you set the VI properties to re-entrant/pre-allocate you can use it multiple times and set you constant values in the subVI.

This is a little time consuming so I only do it for really large clusters but if that functionality could be automated it would be perfect.

[#4]

hfettig, Creating a slim subVI that only has one output as the typedef... that's what I do now for HMI work. If that subVI had an "inline" execution priority (i.e., no hit for subVI overhead for mem allocations into and out of the call), then it would be a perfect solution! However, this solution suffers from performance loss in high-speed RT apps. Here's an idea! Make the functional equivalent of the marriage of your idea and mine. Make a second menu item right under "Link to Typedef" and call it "Open Initialized Typedef". That way you could open up a separate BD with values you can initialize, but it is compiled inline with the parent VI so you don't see performance loss. What do you think? Regards, Jack

[#5]

I'd be happy if there was just an option to show typedef's on the block diagram as their icon instead of the actual control. There is already an icon for the typedef, let us use it.

[#6]

The main issue with using the icon is the values. If you change the values in the constant, this will be hidden. Maybe NI needs to mandate that an icon constant always has the cluster's default values. Another alternative is the one already suggested, where double clicking the icon opens an editor window for changing its values.

[#7]

I think Lavezza has the most elegant solution yet - better than my original proposal. The icon would feed the "input cluster" terminal of the unbundle, and the icon would compile down as efficiently as a BD constant.

Double clicking on the icon would bring up the editor window that allows editing of the constants. This way, each icon could have its own initialization, not just the default values for the cluster.

tst - true, the initial values would be hidden. Let's say hovering over the icon would bring up the initial values in Context Help. I would rather live with this than Typedef Explosion.

[#8]

We just need a way to take CTL file default values OR provide custom values values (maybe a right click option with check mark) when this is implemented.  In any case, we're talking about gaining since a developer can still revert to the old method when applicable.

This could be implemented well along with Add block diagram design for typedefs.

[#9]

I would love to see the icon rather than the data elements.  I also recommend against ever changing the cluster constant's contents if it is a typedef, because if you ever change the typedef, you won't know that instance has changed, until the bug comes to light.  The icon could also have a special border if it contained non-default data.  There is already something subtle like that for lvclasses.

[#10]

I also use the subvi idea, it's okay for huge clusters but takes time to create.

I dont think it's possible to adapt to a polymorphic destination.

[#11]

I have been wishing for a feature like this for a long time.  Regardless of whether you make a typedef for the cluster, it would be nice to be able to "embed" the cluster constant into a Bundle By Name function just by dragging it into the Bundle By Name.  I cant count the number of times I have a big cluster condtant wired into the Bundle By Name and have to "shrink" it on the block diagram to avoid taking up lots of space.  Then of course if I add to the cluster it "explodes" again.  Its just annoying, the amount of BD space a simple Bundle function needs to take up becuase of this.  I like the idea of making the constant a subvi but it is an extra step that takes time- the drag and drop Bundle definition would be simple and fast.