Passing Cluster Datatype Through Tcp

[regisphilbin]

Hi,

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

Regis

[Jim Kring]

You can do it this way... (see attached image)

Also, you can use the OpenG Version of Flatten and Unflatten From XML, which outputs variant data.

EXAMPLE - OpenG Flatten to XML

-Jim

[regisphilbin]

Jim,

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.

Regis

[Jim Kring]

Jim,

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.

Regis

Regis,

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).

-Jim

Download File:post-10-1078457192.zip

[Michael Aivaliotis]

Why use variants. What advantage do you get?

Why not use this method?:

Even with the implementation Jim mentioned, you still need to know the datatype of the final output. The question is, how do you pass the datatype across.

[Michael Aivaliotis]

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.

[regisphilbin]

Thanks Jim,

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

Michael,

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.....

Regis

[Michael Aivaliotis]

Michael, 

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.