TCP Data stream

[lepina]

The manufacturer sent me a sample C# code, because he apparently did not work with labview for the last 20 years -_-

I dont work with C# but maybe some of you can better understand how the data is sent, so I can set this up in labview...

C# sample code
byte[] buffer = new byte[10000];
List<Queue<double>> Channel = new List<Queue<double>>();
int j = 0;
int i = 0;
int NbChannel = 1;
while (1)
{
while (TcpStream_gsr.DataAvailable == false)
{
System.Threading.Thread.Sleep(1);
}
bytesRead = TcpStream.Read(buffer, 0, buffer.Length);
for (i = 0; i < bytesRead;
{
i = i + 8; //Timestamp
for (j = 0; j < NbChannel; j++)
{
Channel[j].Enqueue(BitConverter.ToDouble(buffer, i));
i = i + 8;
}
}
}

[GerdW]

Hi lepina,

this code defines a buffer of 10000 bytes.

When data is available ("TcpStream_gsr.DataAvailable == false") this data is copied into the buffer ("bytesRead = TcpStream.Read(buffer, 0, buffer.Length)").

Then 8 bytes are skipped ("i = i + 8; //Timestamp"), then for each channel in the data 8 bytes are converted to DBL and put in a queue ("Channel[j].Enqueue(BitConverter.ToDouble(buffer, i))").

This is repeated for all bytes in the buffer.

(I'm no expert in C#…)

Your code snippet is missing that BitConverter.ToDouble method…

[lepina]

Im wondering if there is an option to work around it, just to make it plain and simple open tcp->stream data->convert->graph the data

I think the problem is that I dont know how to graph the received data right, since the data comes in this format (as doubles)

Its probably a simple code, but Im new to labview ..

[GerdW]

Hi lepina,

I dont know how to graph the received data right, since the data comes in this format (as doubles)

Probably those doubles follow the IEEE754 standard (like any modern CPU and software like LabVIEW), so you could just typecast those 8 bytes…

It would help when you could post a typical received string in a VI. It would be even better when you could also provide the expected values in that string.

[crossrulz]

---

GerdW wrote: so you could just typecast those 8 bytes…

---

I recommend using the Unflatten From String.  The reason being that the Type Cast assumes Big Endian format.  With the Unflatten, you can specify just in case the data is sent in a Little Endian format.

[lepina]

when I make the tcp send data as text, it sends me numbers. if I click on send as binary its just random symbols like "$)(&"!

and the string length is 8

and crossrulz sorry but I dont understand what u mean with that. an example would probably help me understand it

[GerdW]

Hi lepina,

when I make the tcp send data as text, it sends me numbers.

You probably are talking about text containing ASCII chars in the range "0" … "9" (with some additional chars like +-.Ee)!?

Why don't you use that text and convert it to numeric values?

if I click on send as binary its just random symbols like "$)(&"!

That's the point of using "binary encoding": more compact data…

and the string length is 8

There should be 16 bytes atleast - unless there is no "channel" configured in your measurement and you only receive the timestamp.

I repeat: Attach a VI containing typical string data and their expected numeric values!

[lepina]

can u please explain me how to make that VI with the actual string data and numeric values?

[GerdW]

Hi lepina,

after receiving those string data you show the data in a string indicator. Then use Edit->Set current values as default from the menu and save the VI. Create a comment on the frontpanel and type in the values you expect in those string data. Save the VI again. Attach the VI…

[crossrulz]

---

lepina wrote:

and crossrulz sorry but I dont understand what u mean with that. an example would probably help me understand it

---