Repetitive Unbundling and Bundling

[trlee02]

Hi all,

I'm fairly new to LabVIEW, I'm creating this program for work. I am using the JKI State Machine to create a DMM Controller. I want the user to have the ability to add multiple channels, with the option of making each one a different type of measurement. I'm passing the channel lists as a cluster, then when I need to update a list I unbundle by name in a case structure for whichever mode the user has selected. The challenge I'm having is each of these cases are the exact same code with different unbundle names. Is there a way I can do this in a less brute force manner? 

I've attached some images for reference.

Thanks for the help!

Tristan Lee

[BertMcMahan]

Couple thoughts here:

1- Yes, but it's not very intuitive: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YHdmCAG&l=en-US

2- Perhaps a different datatype is a better option for you. I'd suggest looking into a Map. It is basically a list of key-value pairs, and both the key and the value can be any data type you'd like. For what you're doing, you could use the enum as the index and a string as the value. First check to see if the selected enum is an element of that map. If so, add your new channel to it. If it isn't, add that as a new element to the set.

Give it a shot, if you're totally confused I can mock something up tomorrow.

[Gregory]

Hi Tristan, 

I agree with Bert that you should use a different datatype. A Map would work well, which is a newer datatype. If you have an older version of LabVIEW you can use Variants with Get/Set Attribute, or even a 2D array of strings.

Also, in the future you can use an "in place element structure" when you want to unbundle and bundle a cluster. Its main advantage is readability, I think the way you did it can be optimized by the compiler to behave the exact as an in place element structure.

[altenbach]

You already got some good answers but in general it would really help to see the actual VI. We can't really tell the data structure details from a picture. Please attach your VI!

With some exceptions, images are unsuitable for troubleshooting.

You seem to have a string wired to the case selector. Since you have fully defined number of possibilities, an enum might be more appropriate but we cannot really tell without seeing the rest of the code. Once you have cases for each enum item, the "default" is no longer needed. (In your case you should make the "default" a special case that tells you that an entirely unexpected string has occurred.)

[trlee02]

Thanks everyone! I was super glad to see all the solutions when I got back to work today. I'll give a Map a try. I've attached the VI to this message, I am still in the process of wiring everything up so it may be somewhat messy, feel free to leave any tips. 

[GerdW]

 Hi trlee,

---

@trlee02 wrote:

feel free to leave any tips. 

---

What's this???

• You can create/show wire labels by right-clicking the wire and selecting visible items->label.
• You don't need that arrow decoration: any free label/comment in the block diagram shows an arrow in the lower right corner that can be used to link to a certain block diagram item…
• Why do you need a system text decoration? You can set block diagram items to "no border" by default, with a white or transparent background…

[trlee02]

Hi Gerd,

That is a a default message from the JKI State Machine that I forgot to delete.

Regards,

Tristan Lee

[pauldavey]

You have the "Functions" control as an enum - you should definitely make this a TypeDef and then use this same type as the key for the "Channel List" map. That way everything will stay synched if you add an entry to the enum. I would never make an enum without making it a typedef,