Jump to content

Passing Cluster Datatype Through Tcp

Recommended Posts


This topic just came up at the SD Lava Usergroup meeting last week but I still have some questions regarding passing the "Type" of data through TCP and how to re-assemble the data on the "other side".

Currently, I'm "copying" over the datatype as a constant to the VI receiving the data. Then using this constant, I can rebuild the cluster either via XML or Variants. What I'd like to do is send the data type through so that constants don't need to be used, I can wire in the datatype so that the receiving VII doesn't need to know the exact type of Cluster that is being sent to it....

I'm also opened to suggestions as to better methods of packaging data so that it can be sent via TCP/IP



Link to comment

for some reason I get an error on the "variant to Data" VI. 

Possible reason(s):

LabVIEW:  The data type of the variant is not compatible with the data type wired to the type input.



You can see that the attached VI works just fine. So, either...

(1) your two clusters are not the same type or

(2) there is a problem with the code.

If the problem is #2, then my guess is that you might have used "Variant to Flattened String" or "Flattened String to Variant" instead of "Flatten to String" or "Unflatten from String" (respectively).


Download File:post-10-1078457192.zip

Link to comment

I think a more usefull implementation would be able to adapt to multiple datatypes passed along the tcp-ip link. Of course theis implementation can be used wherever communications is limited to string data.

The attached images show how you can add some smarts to your data so that it can be decoded properly on the receiving end. Of course you can improve upon this implementation by having the receiver call the appropriate data decoder dynamically when needed instead of feeding to a case structure.

Personally I use the variant method. The VI's shown are included in the OpenG LabVIEW Data Tools library that can be downloaded from the OpenG site. I don't use this for TCP\IP rather to pass data between VI modules using queues in LabVIEW.


Link to comment

Thanks Jim,

I'll have to check tomorrow but you're probably right about me using the Variant to flattened String Vi's.


in the VI that Jim put together (and the difference from mine that i posted) is that the you don't need to specify the incoming data's datatype.

This exercise did bring out the benefits of using Strict Type def controls....Anytime i changed the cluster, I didn't have to go around changing all the vi's where the cluster occurred.....


Link to comment

in the VI that Jim put together (and the difference from mine that i posted) is that the you don't need to specify the incoming data's datatype.

But on the contrary, you still do. Whether the datatype is an indicator or a constant makes no difference. How do you decide on what indicator to use?

I agree that variants are more powerfull in this regard. Did you read my last post? I think this implementation is much improved in handling multiple datatypes on the same comm link.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.