TCP IP Connection

[_natalie_]

Hi All,

I wrote here a few weeks back regarding how to use CRLF (here).

I am able to send a command and receive a response to another instrument via TCP-IP (I still can't say which instrument it is).  When I send a command, I get the string response "0\r\n\r\n". In my code, I have set the TCP Read mode to CRLF with 9 bytes to read (1 for the 0 which I always expect and 8 for the "\r\n\r\n".  If I specify more bytes to read, it will timeout.  Now when I send my second command, I can see that the listener is not receiving it (the screen is beside me) and the TCP Read for the second command  will timeout.  

If I close and re-connect, I can send the second command and get the response "1\r\n\r\n" (I was expecting the 1).  

However, if in the first read I specify 8 bytes instead of 9, the second read will return "n".  It's like it is receiving the rest of the first response.

[crossrulz]

If you are in \ Codes display and you want to send an CRLF character set, you should be using "\r\n".  You are actually sending the literal ASCII "\\r\\n".  So I don't think the instrument understands you or is timing out on the command.

[_natalie_]

I tried that, but it will timesout on the first read.

[Mark_Yedinak]

Try the attached VI. I modified the code so that you will actually send the CRLF. As noted above, you were sending "\\r\\n". Also, since you are using CRLF to terminate your reads, I increased the number of bytes to read. It will stop reading as soon as it encounters a CRLF so it doesn't matter if you specify to read more bytes than the response data. This is helpful if your responses are variable length. In addition, your sendo read was only reading a single character so unless the response to "cmd 2" was a line feed (\n) you would always timeout.

[rolfk]

I have a suspicion that the two sides are talking along each other here. There seem to be two possibilities:

1) Either the device sends really the literal string "0\r\n\r\n" (no backslash codes display in LabVIEW controll) which would indeed mount up to 9 bytes. That would mean there is no termination mode in the response!! And your setting the TCP Read into CRLF mode is just making things worse!! It also would mean there is a very good reason to not say what device it is as that would be a double brain damaged communication protocol! 😀

2) The device does send "0<cr><lf><cr><lf>" ("0\r\n\r\n" with display backlash code enabled in the LabVIEW string). In that case there are only 5 characters to be read and in order to get the whole string you need to issue two TCP Reads (at least the first in CRLF mode unless you always know exactly that there will be only one digit in front of the first <cr><lf>), one for the "0<cr><lf>" part and another for the trailing "<cr><lf>". Whenever you use TCP Read with CRLF mode you can and should use TCP Read with more bytes to read than you expect.

I guess there is another possibility where the device sends the actual string "0\r\n<cr><lf>". But if it did that the single TCP Read with CRLF mode and at least 7 bytes to read should have worked. Maybe one has to send this termination sequence in the command to the device??

[_natalie_]

---

@Mark_Yedinak wrote:

Try the attached VI. I modified the code so that you will actually send the CRLF. As noted above, you were sending "\\r\\n". Also, since you are using CRLF to terminate your reads, I increased the number of bytes to read. It will stop reading as soon as it encounters a CRLF so it doesn't matter if you specify to read more bytes than the response data. This is helpful if your responses are variable length. In addition, your sendo read was only reading a single character so unless the response to "cmd 2" was a line feed (\n) you would always timeout.

---

Thanks, Mark!  I should have said that I am using LabVIEW 2016.  I need to start mentioning this in my posts.  Would you please save it so that it's compatible with 2016?

[_natalie_]

---

@rolfk wrote:

I have a suspicion that the two sides are talking along each other here. There seem to be two possibilities:

1) Either the device sends really the literal string "0\r\n\r\n" (no backslash codes display in LabVIEW controll) which would indeed mount up to 9 bytes. That would mean there is no termination mode in the response!! And your setting the TCP Read into CRLF mode is just making things worse!! It also would mean there is a very good reason to not say what device it is as that would be a double brain damaged communication protocol! 😀

2) The device does send "0<cr><lf><cr><lf>" ("0\r\n\r\n" with display backlash code enabled in the LabVIEW string). In that case there are only 5 characters to be read and in order to get the whole string you need to issue two TCP Reads (at least the first in CRLF mode unless you always know exactly that there will be only one digit in front of the first <cr><lf>), one for the "0<cr><lf>" part and another for the trailing "<cr><lf>". Whenever you use TCP Read with CRLF mode you can and should use TCP Read with more bytes to read than you expect.

I guess there is another possibility where the device sends the actual string "0\r\n<cr><lf>". But if it did that the single TCP Read with CRLF mode and at least 7 bytes to read should have worked. Maybe one has to send this termination sequence in the command to the device??

---

Thanks for your response!  I am still waiting to see Mark's code that he sent me (post above your's) to see how to properly send the CRLF in the command.  However, I did run through your list of possibilities.

Assuming it's the literal string, I set my TCP Read to 9 Bytes and I put it in "Immediate" mode.  The response I received in "Normal Display" was "0\r\n\r\n".  In the "'\' Codes Display" the response is "0\\r\\n\\r\\n".

Since there are extra "\", can we assume that it is actually sending a string and not a CRLF?

[_natalie_]

---

@crossrulz wrote:

If you are in \ Codes display and you want to send an CRLF character set, you should be using "\r\n".  You are actually sending the literal ASCII "\\r\\n".  So I don't think the instrument understands you or is timing out on the command.

---

I was reading through the manufacturer's C# code, and they send the string "\\r\\n" as their termination character?  Is this why I've been needing to send "\\r\\n" to have a command received by the listener?

[Mark_Yedinak]

If they are indeed sending "\\r\\n\\r\\n", then I agree with Rolfk that this is a brain dead protocol.

[_natalie_]

---

@Mark_Yedinak wrote:

If they are indeed sending "\\r\\n\\r\\n", then I agree with Rolfk that this is a brain dead protocol.

---

Is there any other way I can go about this then besides closing and re-opening the connection?