LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How much bytes are my data - TCP-String

Hi,

 

I have a 40960 elements long 1D array of SGL data type. I flatten it and I send it through TCP. The receiver gets it but certainly slower than it is sent. It makes me think that I read in much more bytes than needed. For the TCP read I use the CRLF option.

 

After flattening the 40960 long SGL 1D array should become a 40960 long string that would be 40960 bytes. Now, the TCP includes its data as well but I don't know how much, i.e. I don't know how much data [in bytes] I really send and so don't know how much to receive.

 

Thanks for the advices.

0 Kudos
Message 1 of 9
(3,753 Views)

Set up a header packet of a constant size, as shown below, which includes the length of the array you are sending. You get this length by typecasting the data to a string, then using the string length function to determine the array size in bytes. Using this method makes your code expandable, rather than using a constant for the number of bytes read on the host side.

 

Send 

 

Receive

 

 

Download All
Message 2 of 9
(3,748 Views)

Thanks!

 

After I posted I realised that the TCP Write contains a "byte written" output. That actually solved my problem.

0 Kudos
Message 3 of 9
(3,740 Views)

if you are using that to get the number of bytes then hardcoding this value, I would not recommend doing that. It will cause expandability issues for your code, and make it much more difficult if you change the data type you are typecasting to a string.

0 Kudos
Message 4 of 9
(3,732 Views)
I don't undrstand how the "bytes written" can solve your problem. The receiving end needs to know that, and that's elsewhere.
0 Kudos
Message 5 of 9
(3,726 Views)

@altenbach wrote:
I don't undrstand how the "bytes written" can solve your problem. The receiving end needs to know that, and that's elsewhere.

I believe what was done is the OP used an indicator to see the number of bytes written, then hardcoded this value as a constant on the host side. Bad, bad, bad, bad....,bad...........bad...............bad............

0 Kudos
Message 6 of 9
(3,710 Views)

A Single is 32 bits long. 

 

If you convert the array of single to a string using Type Cast, you should get 4 characters per single, or 163,840 characters.

If you write the contents of the array to a binary file, the file will also be 163,840 bytes in size.

 

Why do you think that the TCP string transmitted would be 40960 bytes long?

 

 

 

 

 

 

 

 

 

Message 7 of 9
(3,705 Views)

@Phillip Brooks wrote:

  

Why do you think that the TCP string transmitted would be 40960 bytes long?

 


Single = single byte? Smiley Very Happy

0 Kudos
Message 8 of 9
(3,698 Views)

Hi,

 

yes, the hardcoding kills the expandability, true. And that it is bad bad bad is true as well, I'll change my code using the solution you suggested [very clever by the way!] a bit later however for the application at the moment all I needed was a quick fix.

 

So I got the "byte written" value of the sent TCP packet and hardcoded the value into the receiver side. 

 

Actually I knew that SGL is 4 bytes large but I somehow forgot that 4 bytes are 4 bytes in a flattened way as well. Hmm...

0 Kudos
Message 9 of 9
(3,695 Views)