Problems communicating with device over TCP/IP

[CryoGuy]

Greetings,

In designing a GUI for a device with both RS-232 and TCP/IP communications capability, I've run into quite a puzzling issue that has me stumped and my brain in pain.  You can query and send commands to this device using ASCII commands.  Developing the serial port communications aspect of the GUI was trivial.  My problem with TCP/IP is this:

I first establish the TCP connection using the "TCP open" vi.  I then send my ASCII command or query (that is CR terminated) using "TCP write," pause for 250 ms, and then read using, "TCP read" in the CRLF mode (the device does respond with CRLF line termination).  Success using this method in LV is intermittent, especially when I put the write/read vi in a loop and go between querying and sending commands-only.  As a matter of fact, if I am only querying the device, it will run indefinitely without any problems and my front panel indicators display values from the read buffer.  As soon as I send a command (to change a setting, for example), an error is propagated and the GUI no longer receives the data from the read buffer.  More recently, I've found out that the device is definitely receiving the commands even when the GUI fails to retrieve the read buffer, because I can send a query, switch over to hyperterminal, and hit return... it displays my response in HT without my even having to type in a command!  I'm totally stumped here, as I've played around with all kinds of delays in different places, different read modes, opening/closing connections, etc.  I even tried putting in a redunant "dummy" read by itself, and a dummy read following a write with just a CR as the command (I thought this might solve my problem based on the behavior I saw when switching over to hyperterminal).

I've been searching the discussions for similar problems, but to no avail.  I have read that TCP communications is handled by the OS, so perhaps this is where I am running into trouble?  Any help, advice or suggestions are greatly appreciated.

(A little bit more information on the device: The way I want the device to work is as a monitor, so it should be querying indefinitely unless the user sends a command to update a setting, at which point it would send the command and then resume monitor status).

[lis@jiang]

Hello CryoGuy,

Thanks for the question.

Your description seems to fit this KB about poor performance in TCP read.  If this document isn't helpful, please let us know the following:

1.  Which OS are you using?

2.  Which version of LabVIEW are you using?

3.  What's the specific error number and message you're getting?

4.  At which function in LabVIEW are you seeing this error?  (Turn on highlight execution to see where the error starts if the message doesn't say.)

Thanks,

Lisa