Get name of cluster element as a string

[CatDoe]

Is there a way to get the name of a cluster element into a string format?

I do not want to manually write headers for all my elements as the names and orders may change when the physical program is edited in the future by other people who will not know the program or update these details. I do not need to output the entire cluster.

For example:

The element in the cluster is named "User.Test"

The string is "User.Test"

[JÞB]

There shout be a vi on the Types pallet. 

[CatDoe]

@JÞB How can I get to that pallet? I do not see it, nor could I find anything under the search.

[Gregory]

You can use NI_Data Type.lvlib:Get Type Information.vi. If you have a cluster of clusters, you will have to use it recursively. MGI's Read Write Anything library will show you how to do this.

I believe you have to install Hidden Gems on VIPM to see the Data Type VIs.

[altenbach · Accepted solution]

---

@CatDoe wrote:

Is there a way to get the name of a cluster element into a string format?

---

You mean like that?

[JÞB]

---

@altenbach wrote:

---

@CatDoe wrote:

Is there a way to get the name of a cluster element into a string format?

---

You mean like that?

---

Yes, but there is a vi for that.

[CatDoe]

Yes! Thank you! I will try that on my end and see if I can get it to cooperate.

[rolfk]

---

@JÞB wrote:

---

@altenbach wrote:

---

@CatDoe wrote:

Is there a way to get the name of a cluster element into a string format?

---

You mean like that?

---

Yes, but there is a vi for that.

---

But the Types VIs do this by parsing the type descriptor, So basically you propose to turn the cluster into a variant, retrieve its typedescriptor and then parse that to eventually get that name.

While it works it’s for sure a lot of effort and memory operations and the property node is very likely a lot faster and clearer to understand.

[drjdpowell]

---

@rolfk wrote:

But the Types VIs do this by parsing the type descriptor, So basically you propose to turn the cluster into a variant, retrieve its typedescriptor and then parse that to eventually get that name.

While it works it’s for sure a lot of effort and memory operations and the property node is very likely a lot faster and clearer to understand.

---

From my experience, I would expect Variant work to be faster than Property Nodes.  

Your description of parsing descriptors sounds like the older techniques based on flattening, such as used in OpenG.  I'd still give them an edge over property nodes.  Property Nodes are very slow.

[rolfk]

---

@drjdpowell wrote:

---

@rolfk wrote:

But the Types VIs do this by parsing the type descriptor, So basically you propose to turn the cluster into a variant, retrieve its typedescriptor and then parse that to eventually get that name.

While it works it’s for sure a lot of effort and memory operations and the property node is very likely a lot faster and clearer to understand.

---

From my experience, I would expect Variant work to be faster than Property Nodes.  

Your description of parsing descriptors sounds like the older techniques based on flattening, such as used in OpenG.  I'd still give them an edge over property nodes.  Property Nodes are very slow.

---

The LabVIEW type library also parses the type descriptor. Both the older depreciated version and the new one.

And yes Property Nodes tend to be slow because of the thread context switch to the UI thread. Usually it's ok but I recently had a case where for some reasons a function in a library was sometimes (1 out of 100 times maybe) extremely slow. It was on two different cRIOs and this same library was working on many other cRIOs without any such hitch.

Finally we could pinpoint the problem to a low level function deep down in the library that tried to convert a numeric value into a sparse enum (ring control) by accessing the ring controls property and mapping the number accordingly. For some reason that properly node would sometimes stall for up to a second or more for no obvious reason. Our suspicion is that it has to do with either the NI OPC driver or another similar driver that we can not look into. These are the major difference on these two stations compared to all the other cRIO chassis that were operating just fine even with that property node present. Of course that property node has been replaced by a diagram constant now. Takes away the automatic adaption of the conversion when the ring control typedef is changed but that's a price we were willing to pay.

Still, if such operations are part of UI processing in an application, there is no reason to not use the property nodes for this and they definitely look more obvious to me as to what is going on in the code.