Reading Binary Data using TCP/IP

[manny09]

Hi Everyone,

I was wondering if someone could help me out. 

I am working on a project where I have to collect continuous binary data through ethernet using TCP/IP. I am not sure where to start. Can someone point me towards a right direction or some examples related to it. 

The way my project should work is I send a binary number to the host using TCP/IP and receive the data in response based on the binary number I send initially. 

Thanks

[Alexander_Sobolev]

Help -> Find examples -> Search -> TCP/IP. 

[manny09]

I looked at it initially, but it doesn't have anything with binary data. 

[RavensFan]

All data is binary. 

Please tell us more where you are stuck.

Do you mean that the inputs and outputs of the TCP/IP Write and Read are showing as string datatypes?  Strings are binary data also.  You just need to typecast whatever your datatype is to a string.  And then typecast it back again on the other side.  Just like the TCP/IP examples you looked at show.

[Bob_Schor]

I have a LabVIEW RT Project where I collected multi-channel (16-24) analog data at 1KHz.  I use Network Streams to "stream" these data (in packets of 50 samples at a time) from the Remote (PXI) Target to the Host PC (where they are promptly displayed and streamed to disk).  I have no difficulty "keeping up" -- I haven't tried "pushing it" to see how fast I can go, but I know I'm not "missing" any data points.

There's a good White Paper here.  There are also several Network Stream topics under LabVIEW Help.

Bob Schor

[manny09]

I am about to start looking at it. I will give it a shot. I just wanted a starting point as I have never dealt with TCP/IP with labview. 

[manny09]

thanks for the link.  I will have a look at it. 

[Bob_Schor]

It's actually not too bad, particularly if you let LabVIEW do some of the hard work for you in managing the data (which is why I like Network Streams).

Something to think about is how you connect your PC and your Remote.  When I was first introduced to LabVIEW RT, it was with an older LabVIEW 7.0 routine where little thought was given to the "niceties" of IP addressing.  Now that I'm writing the code, I've made a few changes and some "new rules", which I'll pass along.

• Where possible, dedicate a second NIC in your PC to handling the connection to the Remote (don't try to do this over the same "wire" you use to browse the Web and authenticate to your network).
• I recommend using a non-routable IP address.  I'm using 10-dot addresses, with PCs being 10.0.0.x, and Remote Targets being 10.0.1.x.
• For a NIC-to-NIC connection, you need to "cross-over" the TCP/IP send/receive wires.  Rather than purchase a (cranky) CrossOver cable, buy an inexpensive 4-port switch and simply plug a "standard" Ethernet cable from both your PC and Target into it -- it will figure out the proper wiring itself.
• You need to know at least one IP (either Host or Remote) to establish the TCP/IP connection.  I recommend you specify the Remote IP, as there is code you can run in your PC to "discover" reachable RT Systems.  This way, you can (in principle) have more than one PC connect to your Remote System (one at a time, of course) without changing any code, since the IP of the Host is never specified.

Bob Schor

[crossrulz]

I would also recommend you have a good look at the STM library put out by the AEs at NI.  You can download and install it via VI Package Manager.

[Alexander_Sobolev]

>> I looked at it initially, but it doesn't have anything with binary data

Ttcp-ip vis are sending and receiving bytes, who cares - it is data. You have type cast, you have flatten to string.