TCP Timeout Issues

[Eccomi]

Hello,

The application: I'm using LabVIEW 8.2 to communicate with an RFID reader.

I connect to the reader via TCP and write (TCP Write block) a number of commands (login, set system parameters, query reader for tag list), and my VI functions smoothly, with one exception: since I do not know beforehand how many tags will be in the vicinity of the reader's read capability, I have no method of gauging the length of the return data (the TCP Read block for bytes to read).

To break the problem down, I can either read a very small number of bytes and avoid a 56 Timeout error, losing some return data in the process, or I can allow the system to timeout, reading a large number of bytes and allowing each step of execution to take the  amount of time designated in the Timeout as opposed to the amount of time it actually takes for the reader to respond. 

My question, simplified: is there some way I can use TCP to read only the data which is actually sent (I'd rather not specify the number of bytes to be read, allowing the VI to realize when no more data is available)?

Thank you in advance.

[tst · Accepted solution]

As far as I know, there is no way to check how much data there is in advance. Some protocols have a predefined amount of bytes, or start the message by sending the message length, so that you read that first and know how many bytes you need.

If you can't do that, what you want to do is call the TCP Read primitive in a while loop until you get a timeout error and wire the string into an auto-indexing output tunnel. You can then wire the resulting 1D string array into the Concatenate Strings primitive to convert it to a string. That way, you can use a short timeout and read a small number of bytes with each read without losing information.

[pavanb]

Sorry I replied to the wrong thread. Meant to reply to,

http://forums.ni.com/t5/LabVIEW/always-get-tcp-read-timeout-56-but-getting-data-too/td-p/1271218

[Mark_Yedinak]

Unless you know the exact number of bytes to read you will always get a read timeout or you will read a partial amount of data. The remaining data will be there but will be read in your next read.

The way that I handle this type of situation is to use two reads. The first read will look for a single byte. This read will use a longer timeout. The second read will then read blocks of data (block size will depend on the typical block size of your data) and this read uses a short timeout. This second read is in a while loop which will read until a timeout (or other error occurs). I concatenate all of the data read. If the first read times out I return the timeout error. If the timeout occurs in the read within the while loop I filter this error out and return the data. If another error occurs I return that error along with the data that was read up to that point. Depending on the type of data you are receiving and how quickly the othe rend responds the second timeout can be very short. A good value to use is 100ms. This may need to be a little longer or shorter depending on your particular application.

This is not a fool proof method but it generally works quite well for reading unknown amounts of data when you don't have a terminator or known amount of data.