LabVIEW
CRLF Questions
Solved!
Hello,
I am communicating with a device (I cannot say which at the moment) with TCP/IP communication. The commands require CRLF (\r\n) at the end. I have two problems:
1) If I concatenate the command string with the EOL string constant, the Listener will not receive the command. However, it I concatenate "\r\n" to the command string, the Listener will receive the command.
2) After sending the first command successfully (but with "'\r\n" instead of the EOL string constant), it will not receive the second command.
What is it that I am missing? I've included a picture of the code as well as its VI.
@RavensFan wrote:
Your \r\n constant is in normal display. That means you are sending literally backslash r backslash n.
Change it to \code display. Make the display style visible so it is obvious on inspection you are not using normal display. Edit the string to be \r\n (because it will currently show \\r\\n )
If find it hard to believe that the EOL constant which sends a carriage return followed by a linefeed is not working for you.
Why can't you tell us what device you are communicating with? You need to know the device and read its manual to clearly know what you are supposed to send.
Thanks for getting back to me.
Yes, I find it hard to believe, too, but that appears to be the case. I can't tell you which company we are working with, so I can't tell you the instrument. However, looking from their C# code, I see that their terminator is written as "\\r\\n" and is concatenated to the end of the command.
I changed both string constants to the '\' Codes Display, and checked the "Display Style Visible". I tried a few combinations and these were my results...
"cmd1\r\n" and "cmd2\r\n": neither were received by the listener
"cmd1\\r\\n" and "cmd2\r\n": "cmd1\r\n" was received by the listener
"cmd1\\r\\n" and "cmd2\\r\\n": "cmd1\r\n" was received by the listener
"cmd1\r\n" and "cmd2\\r\\n": "cmd1cmd2\r\n" was received by the listener
The VI is also attached.
It would appear that your listener is more like a passthrough to the actual parser than contain the parser itself, A strange implementation that only the manufacturer itself can help you with.
It’s not a LabVIEW problem for sure!
Note that unless this is a custom device implementation for your application, it is special enough to likely find out what device you might be using. 😀
Note that your TCP Read Function specifies 1000 Bytes to read, and its Mode (wired in from the top) is left at the default "Standard". If you want to use CR/LF as a String Terminator (similar to the "proper" way to use VISA), you need to wire Mode "CRLF" to this input.
Bob Schor
@Bob_Schor wrote:
Note that your TCP Read Function specifies 1000 Bytes to read, and its Mode (wired in from the top) is left at the default "Standard". If you want to use CR/LF as a String Terminator (similar to the "proper" way to use VISA), you need to wire Mode "CRLF" to this input.
Bob Schor
Thanks for pointing that out!
