Concatenation of clusters

[Diaspora]

Dear Experts,

I am experimenting with different ways of passing data using clusters. From the attached vi, Cluster 1 and Cluster 3 are for inputs and whereas Cluster 2 and Cluster 4 are used for displaying outputs.

I have successfully concatenated two clusters and passing it to the data in of UDP Write. Kindly assist me how both the values of these respective clusters can be read and received from data out of UDP Read. Thank you in advance.

[cbutcher]

I suspect it may be quite difficult to do that in the way you'd like - you'd have to parse the string yourself and the parsing might change with LabVIEW changes (probably not, but still...)

A better method might be to bundle 1+3 together and create a typedef for the combined cluster of clusters, then flatten that. This way, you only send one object and can unflatten it into the joint typedef, then unbundle to get 2+4.

Here's an example without the typedef defined. I'd suggest using a typedef to simplify updating it in future.

[crossrulz]

Personally, I am a fan of using the Flatten Into String and the Unflatten From String functions.  They have some benefits over the Type Cast, the most important (to me anyways) being the ability to set the Endianness (ie byte order).  But for this case, the more important part is the the Unflatten From String has an extra output for "Remaining String".  So you can chain these functions together.

[altenbach]

---

@crossrulz wrote:

Personally, I am a fan of using the Flatten Into String and the Unflatten From String functions. 

---

Somehow I did not scroll enough to see your post, so I composed&tested basically an identical solution before noticing yours. 😮 Probably would need to handle unflatten errors, because there is no way to guarantee what's received. Probably needs also other tweaks.

[crossrulz]

---

@altenbach wrote:
Probably would need to handle unflatten errors, because there is no way to guarantee what's received. Probably needs also other tweaks.

---

If on a dedicated, low traffic network, not much of an issue.  If on a larger or high traffic network, I would add in some error checking like a CRC or Reed-Solomon.  We would then catch that issue before we even try to interpret the data.  But, yes, we should do some checking in case the wrong thing was actually sent.