TCP read bytes to read

[espeno]

Hi! I have a little question about the TCP read palett in labview, im trying to send 1 bit from a server to a client. This works when i put numeric 4 into the bytes to read input on TCP read on client side. But when i change this value to 1, as should be efficiant, this dosent work. Any ideas?

[crossrulz]

What do you mean by "it doesn't work"?  Data is not interpretted right?  You get an error?

Do you have any code to show your situation?  Server and Client code would be useful.

[espeno]

Hi.

Thanks for your promt reply. What a mean is that when i have numerice constant 4 into "TCP bytes to read" I am able to flip boolean vertical toggler on bot client and server side, and make a led go on.

But when I change this numerice value to 1, the led will not go on when i flip the toggler. I have just made som modification on the TCP simple example in LabVIEW. And I think this is mabye is caused by the string/numeric conversion and only 1 byte is not enough. But I have also tried to change the numeric "bytes to read" value to 10, and nothing happens when a flip the toggler.

I think what I am realy asking is; Can you pls explain to me in very simple terms how the TCP read input works?

I have attached all 4 VI`s below, if my explination was unclear.

Thanks for any reply.

With kind regards

Espen

[JakeA]

Hi Espen,

Thanks for uploading your code. For future reference you can only attach up to three files to each post so the fourth piece of code wasn't uploaded, but what you posted was more than adequate for me to see what is occurring in your code. The TCP VIs in LabVIEW send data as strings, and string data in LabVIEW has a minimun size of 4 bits. When the single bit boolean data type is type cast into a string the data is padded with zeroes to make it 4 bit. Essentially, LabVIEW takes the '1' and changes it to '1000' which is then changed into a string to be sent via TCP. This is why you need to read 4 bits in your VIs; anything less and all it reads are zeroes. Does this answer your question?

Regards,

[espeno]

Hi! Thanks!

I tought the problem was with the boolean string conversion, and this made it somewhat clearer.

But then; If Labview change 1 boolean bit into into 4 bit, then should the TCP Read be able to read this with a numeric input of 1 byte into "bytes to read" input. (as 1 byte = 8 bit) .

And also, why does the problem still occure when i put numeric 10 into "bytes to read" as this should be more then efficient to read 4 bits?

Thanks again!

Regards

Espen

[drjdpowell · Accepted solution]

Your number of bytes value is an I32 number (32 bits or 4 bytes), so you are sending 4 bytes followed by 1 byte for the boolean itself.   You could convert the number of bytes to a I8 to make it one byte (but I wouldn't bother as the IP header info is many bytes, meaning 1 versus 4 bytes means little).

[JakeA]

drjdpowell is correct, I now see that the issue is that you're passing the string length data over TCP which requires 4 bytes.

To answer your other question, the TCP VI, be default, TCP Read Function waits until all bytes you specify in bytes to read arrive or until timeout ms runs out. If fewer bytes than the number of bytes you requested arrive, it returns the partial number of bytes and reports a timeout error.

Regards,

[espeno]

Great!

Thank you both for your help, this finaly made things clear 🙂

With kind regards

Espen

[Kumar@321]

i have made one code for TCP communication using ethernet interface. But when i am connecting byte at port os value 1024. its showing Error 56.

I am attaching my code. Please suggest me the solution to get rid of this TCP bytes at port error.

Thanks

Prashant Kumar

[rolfk]

What is your device sending back? If it is sending back a <carriage return><line feed> terminated string, change the mode input of the TCP Read to CRLF. If it is sending back something else you need to know how much data bytes it is sending back.

Currently you use Standard mode and that means, the function will only return when the requested amount of data bytes have been received OR the timeout occurred OR another error has occurred. With CRLF mode the function will return when the requested amount of data bytes have been received OR the <carriage return><line feed> as been encountered in the data stream OR the timeout occurred OR another error has occurred