replace bundle with bundle by name

[Jman2150]

Ok so I have this code and here is what I want to do. I used the bundle function to organize sections of the code and flow information into a sub VI (I removed the sub VI for the purpose of this post). now I want to replace that bundle block with a bundle by name block to make it easier to udate the code later if I need to. So I want to replace this bundle

and this bundle

with the bundle by name function. Nothing I've tried so far has worked. I think the problem has to do with the fact that I want to put arrays of different type, refrences, and another cluster into the bundle by name function. Oh and I did make sure that they all have owned names before I tired this, so I'm pretty sure thats not the problem. Code is attached, but be warned, its kind of a mess. Its my first big code and I need to clean it up, which is part of the reason I'm trying to do this.

All help is appreciated.

John

[crossrulz · Accepted solution]

The thing with bundle by name is that it needs a cluster to be passed into it as a type def.  So what I did was right-click on the cluster wire, create constant.  Name all of the elements.  It's big, so view as icon.  Wire the new cluster into the input cluster of the bundle.  Right-click on the bundle and replace with Bundle by Name.  And all was good.

[Jman2150]

Thanks crossrulz I was trying for forever to figure that out. Really obvious now that I think about it haha. Appreciate your time.

John

[johnsold]

John,

You really do not have names for the Bundle by Name.  When you put the wiring tool over the array the context help shows: 1D array of Select Option 2... The array itself does not have a name even though it consists of named typedefed elements.

I suggest that you have bigger problems than naming your cluster elements. The use of Value property nodes and control references to move data around is about the worst way you can do it in LabVIEW.  Wires are always the best way when they can be used. In your code it looks as though everything could be wired directly.  That would drastically simplify your diagram by itself.  Also using Build Array inside a loop results in frequent memory reallocations and can slow down your program or even make it crash. Pre-allocating an array and using Replace Array Subset is the preferred method of putting data into an array.

I suspect that if you used wires wherever possible, the size of your BD would be 1/4 what it is now.

I never thought of dividing a typedef by a zero-valued typedef of the same type to get the NaN in a typedef.  Very interesting! I do not usually use typedefs for numeric value controls, so I have never had any need for a typedefed NaN.

Lynn

[Mark_Yedinak]

---

@crossrulz wrote:

The thing with bundle by name is that it needs a cluster to be passed into it as a type def.  So what I did was right-click on the cluster wire, create constant.  Name all of the elements.  It's big, so view as icon.  Wire the new cluster into the input cluster of the bundle.  Right-click on the bundle and replace with Bundle by Name.  And all was good.

---

You forgot to mention that the cluster should be a typedef. Simply creating random constants will not make your life easier. A typedefed cluster is the way to go.

[Jman2150]

Lynn,

The primary reason I used the property nodes and control refrences is becasue I plan to put the inner loop into a sub VI and then the outer loop as another sub VI and then the entire thing will be part of a larger code. It was my understanding, and I could be wrong, that I needed my controls outside of the sub VI for them to work on the front panel of the main VI, hence the refrence/property node stuff.

I had been looking for a way to replace the build array comand, so I may look into using Replace Array Subset.

Thanks,

John

[Mark_Yedinak]

Generally it is better to separate your processing code from your user interface. Have your processing code pass data to the user interface controller via queues, notifiers or user events. You generally don't want to have references to controls littered throughout your code. The exception to this is if the code is specifically used for the user interface. This type of design make it very easy to switch the look of your user interface and keeps your processing code basically untouched. Your messaging API between the processing code and the user interface should be well defined. This makes for a system that is easier to maintain, it will be more flexible and you can get greater reuse of your code.