Array to Cluster to Typ-Def Cluster

[herrlin]

Yik In your Read MTM example I would use a bundle by name and wire each value of the array to the appropriate cluster element.  This way you will insure your cluster is correct and you should avoid corrosion dots if all values and element representation match correctly. Dan

[herrlin]

Example of what I am talking about. 

[RavensFan]

Are corrosion dots rust colored?

[dan_u]

---

Ravens Fan wrote:
Are corrosion dots rust colored?

---

Yes, and if you don't do something about them they might break your wire 

[jyang72211]

Oh, no.  All my wires are rusted away. 

[gstanczak]

A quick related question (I don't think it warrants a new thread):  Why does the coercion dot need to save a copy of the original data?  The Convert functions do not, correct?  And this where the performance suffers?

Why can't/doesn't the coercion dot function exactly like a Convert function (that may or may not convert the data the way you want)?

Thanks!

Greg

[smithd]

Hey gstanczak,

As far as good programming practice, explicit conversion is always better. LabVIEW can sometimes coerce things strangely, which gives bad results for your code. On the other hand, sometimes coersion dots can be faster. See this for more info:

http://forums.ni.com/t5/LabVIEW/Dealing-with-Coercion-Dots/m-p/926925/highlight/true#M416411

In that example, explicitly converting to a double is slower than using coersion.

Take a look at ben's post on the last page:

http://forums.ni.com/t5/LabVIEW/Array-to-Cluster-to-Typ-Def-Cluster/m-p/1085005#M480154

"Coercion dots of the greatest concern when dealling with arrays since they upcasting to a larger type of number (u8 to U32) can't be done in place and requires copying the buffer."

A new buffer is not always needed, but it will always interpret the data in a way that you have not explicitly chosen, which can be bad. There are no hard and fast answers about this, I'm afraid.

Thanks,

D Smith