[HELP] Send multiple clusters via TCP/IP

[mcm95]

I am new to Labview and I am trying to figure out how to send multiple clusters using TCP/IP from client to server. Only boolean data is used in the cluster. I managed to get two clusters sent, where in one cluster all the data is correctly sent, and the LEDs lights up on the server end. However, when I send the second cluster, only one switch and LED works. The rest of them don't seem to be transmitted. I have included a screenshot below. I am not looking for anyone to do this for me, rather just guide me and show me where I have made mistakes. Thank You.

[GerdW]

Hi mcm,

instead of putting "pure" cluster into the TCP message I would convert the clusters into "readable" text including a header describing the message content.

Example: cluster of booleans is converted to text "kitchen,1,0,1,1".

(You could even convert the boolean into an array, then into a number and send "kitchen,13"…)

Hint: when working with clusters you should typedef them!

[crossrulz]

Personally, I am a fan of the Flatten To String and the Unflatten From String primitives.  The main reason I prefer these over the Type Cast is that you can specify the Endianness (which has been a problem when trying to communicate with PLCs or microprocessors).  The other cool thing with the Unflatten From String is that it has an output for "Remaining String", meaning you can get a cluster value out of it and that part of the flattened string is removed and you can pass that on to the next Unflatten From String to get the next set of data.

So first I flatten all of the data into strings and concatinate them into a single string.  Then I get the string length and flatten that into a string.  You can use two TCP Writes or just add the flattened length to the front of the actual data and use one write (as I show below).  So what does this buy us?  The first thing you are sending is how much data you are actually writing.  So the server does not have to guess at how much data is coming.  So the server first reads the length (I32, so 4 bytes), unflattens that data into an I32 and use that value to tell the next read how many bytes to read.  So now we have all of the data that was sent.  Now the decoding.  Use a chain Unflatten From Strings with each one unflattening the cluster you expect at that location.

And, yes, you really need your clusters to be Type Defined so that it becomes a lot easier to update everything when you have to add items to the clusters.

[Bob_Schor]

I find that LabVIEW's Network Streams are pretty robust "wrappers" around TCP/IP.  I've used this to create a "Message" system between Client and Server where the Message payload is a Cluster consisting of an Enum and a Variant.  The Enum tells the receiver what kind of data is packed in the Variant so that it can be properly reconstructed on the other side (you need, of course, to know the TypeDef of the item that went into the Variant).

Of course, if it can send a Cluster of Enum + Variant, then it certainly can send a fixed TypeDef'ed Cluster all by itself ...   I let LabVIEW handle the "messiness" of TCP/IP communication ...

Bob Schor

[Blokk]

Another vote for Network Streams. They also handle very nicely scenarios like network outage, etc... (connection auto recovery)

[crossrulz]

Personally, I am a huge fan of the STM library, which has Ethernet and serial implementations.  I do wish they (NI SE) would make a Network Stream version.

[Hooovahh]

+1 for Network Streams, and +1 for teaching me a few things about unflattening strings on TCP.

We have an actor based design for applications where user events tell code modules to do some work.  I then made a Network Streams actor that listens for remote connections from remote devices and if if finds any performs a connection where it will listen for requests and convert them into user events for a module to do some work.  The result is a code module that can get a user event internally (an actor asking itself to do some work usually from a debug UI interaction) the same user event from another code module (one actor telling another to do some work) or the same user event from the Network Stream (an actor on another network device asking this actor on this device to do some work).  It allows us to write sequence code that runs on the target asking local actors to do work, or the same sequence to run on one target, and ask another target to run the test step by step.  Great for debugging and testing sequences without having to deploy new code.