How to convert a general cluster to a typedef'd cluster?

[cober]

I have a typedef cluster with 12 identical elements, which I need to apply some operations on (the same on every element). So I use a cluster-to-array, feed it into an autoindexing for loop and then convert it back with array-to-cluster (with number of elements set to 12). But now the output cluster no longer has any of the labels and is of course no longer connected to any type def.

I think using typecast or flatten/unflatten could work, but it will only at runtime cry if the datatypes don't match up (for example I change the number of elements in the cluster, but don't think about the "array-to-cluster" function).

Is there a way to achieve "type A cluster -> array -> type B cluster", so Labview will show me a broken arrow, if something does not match up?

[GerdW]

Hi cober,

to answer your question: You unbundle your generic cluster and use a BundleByName function with your typedefd cluster as input.

To raise a question: why do you use a cluster at all when it contains just 12 elements of the same datatype? Why don't you separate data presentation for internal storage and UI display?

[cober]

---

to answer your question: You unbundle your generic cluster and use a BundleByName function with your typedefd cluster as input.

To raise a question: why do you use a cluster at all when it contains just 12 elements of the same datatype? Why don't you separate data presentation for internal storage and UI display?

---

Ok, this does not work with BundleByName though, since it does not autogrow when a cluster is changed (and I would like to see a broken VI, should I change the number of elements in the cluster). Anyway an idea, it would be nice if the array-to-cluster function had an additional terminal where you could hook an typedef to to define the output cluster.

Why I use a cluster? First the number of elements is constant (except for the unlikely case hardware gets extended and new channels will be added; but in that case I want Labview to break my code so I can't forget to adapt my code). But even more importantly it's for the labels. The values may be of the same type, but the treatment after that first check is very different. Since Labview unfortunately lacks very useful datatype of associative arrays, a cluster with appropriately named elements is the only chance in my opinion to keep code after that readable (juggling around with single array indexes and remembering where in an array a certain value is, is no fun).

[GerdW]

Hi cober,

there is a function that allows for conversion to other (typedefed) datatypes. You may try CoerceToType…

I would rather make my internal data storage independent from a certain hardware limit, thus using arrays for storing data. To keep track of data channel names and their associated hardware terminal I often use key-value-pairs implemented as attribute of a variant…

[cober]

---

@GerdW wrote:

Hi cober,

there is a function that allows for conversion to other (typedefed) datatypes. You may try CoerceToType…

---

Comments here say it's unstable (June 2014). (I can't find the anywhere anyway in Labview 2013)

http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/92/page/2

Which is weird. Because all I'm seraching for is a "manual" coercion dot. Never heard the automatic coersion is unstable. In the end I may just make a subvi with the typedefed cluster as input and output with no other content than a connection between these two terminals and force of the use of the builtin coercion dot. It's okay for the single typedef I need it for I guess. But a little bit annoying if you had more of them.

[GerdW]

Hi Cober,

you can't find that function in any LabVIEW version on the palettes as it is a "LV-internal" function hidden from us so far. That's why it is presented in the snippet in that LV idea…

---

But a little bit annoying if you had more of them.

---

That's why I usually separate internal data storage from display presentation: you get best of both worlds! You can make your internal data storage as efficient as possible and you can make your display presentation as beautiful as it needs to…

[crossrulz]

Let's take a step back.  What operation are you doing to each element of your cluter/array?  You may not even need to convert to the array in the first place.

[cober]

I have values that are formated to fixed point notation including an overflow status. (the reason for fixed point being that they are together with some other stuff coming flattened to string over UDP in as small packages as possible). On the receiving side I unflatten them, convert them to a double, which I set to NaN, if the overflow flag was set. So the standard polymorphic functions can't be used (but I use them later for other stuff of course, after I have the cluster of doubles).

[nathand]

Instead of using flatten/unflatten or typecast to convert a generic cluster to a typedef'd one, consider using Variant to Data. I would guess it will be more efficient. This doesn't answer your question about checking if the clusters are compatible at edit-time, though. To do that, you could do any sort of comparison between cluster A and cluster B -  for example wire both to an Equals. You don't need to do anything with the output, and the compiler is probably smart enough to eliminate it during compilation. However it will cause a broken arrow if A and B aren't compatible.