TCP IP Connection

[Mark_Yedinak]

You shouldn't need to open/close the connection for each command. Simply open it once and do you work. Put in some error recovery that if your read/write do encounter an error you may want to close and reopen the connection. It depends on the protocol and the device. Given the crappy protocol your device uses, you could create a simple communication task that handles the reading and writing to the device. Based on what your longest response would be, use the read immediate mode using the max size. This task will not process the data but rather post it to a queue for a processing/parsing task. That task will get the data from the receiving task and then add it to its data buffer. It will then parse that data according to the protocol. If the device is consistent in using a literal "\\r\\n\\r\\n" you can use a regular expression or other string processing VIs to grab the first chunk of data upto and including the first "\\r\\n\\r\\n" in the data. Process it and then do the next chunk if there is data in the buffer. This can complicate things a little but it really depends on exactly how you are communicating with the device (is it command/response, streaming, asynchronous messages).

Another approach is to read a large amount of data, at least larger than your maximum size response. You use two reads. The first is a read of a single character with your long message timeout and the second is a read of the large data size with a very short timeout. This is useful when your responses are variable length. The assumption here is that after you see the first byte, you should receive the entire message after it. That is why you use the short timeout. This does not work if the device is streaming data. This works pretty well for command/response and asynchronous messages.

[_natalie_]

Ahh sorry, I didn't mean to hit solution yet and I don't know how to fix it...  Fixed

---

@Mark_Yedinak wrote:

You shouldn't need to open/close the connection for each command. Simply open it once and do you work. Put in some error recovery that if your read/write do encounter an error you may want to close and reopen the connection. It depends on the protocol and the device. Given the crappy protocol your device uses, you could create a simple communication task that handles the reading and writing to the device. Based on what your longest response would be, use the read immediate mode using the max size. This task will not process the data but rather post it to a queue for a processing/parsing task. That task will get the data from the receiving task and then add it to its data buffer. It will then parse that data according to the protocol. If the device is consistent in using a literal "\\r\\n\\r\\n" you can use a regular expression or other string processing VIs to grab the first chunk of data upto and including the first "\\r\\n\\r\\n" in the data. Process it and then do the next chunk if there is data in the buffer. This can complicate things a little but it really depends on exactly how you are communicating with the device (is it command/response, streaming, asynchronous messages).

Another approach is to read a large amount of data, at least larger than your maximum size response. You use two reads. The first is a read of a single character with your long message timeout and the second is a read of the large data size with a very short timeout. This is useful when your responses are variable length. The assumption here is that after you see the first byte, you should receive the entire message after it. That is why you use the short timeout. This does not work if the device is streaming data. This works pretty well for command/response and asynchronous messages.

---

It is done with asynchronous messaging.  I followed your second set of instructions.  The 2nd TCP Read results in a timeout error.  I attached my 2016 LabVIEW code.  Is this what you meant?

[Mark_Yedinak]

Yes, that is the basic idea. The changes you made to the reads after "cmd1". You would probably have to do the same thing for the read after "cmd2". I would make the read a separate subVI so you can re-use it. Also, depending on your specific case, the second timeout of 1 second maybe too long. I generally use short timeouts in the 50 to 100 ms range.

I attached a copy of a version we use.