I found a bug or at least an unexpected behavior of the TCP Write command in LabVIEW 2016 and would like to know if anyone else have seen it and if it actually is a bug or somewhat of a 'feature'.
The Setup:
ThinkPad running Win10 x64 + LabVIEW 2016 x64.
Lantronix XPort (server that LabVIEW will connect to).
The Lantronix XPort is a small server that connects to the local wired Ethernet. It is basically a Ethernet to RS232 'adapter' that will accept a TCP/IP connection from any programming language or even Telnet and SSH if needed.
Connected to the RS232 port of this server is a piece of custom electronics used to control a Cryogenically cooled low noise Radio Astronomy Receiver (not a really important detail in itself).
The commands are very simple and straight forward. In this example I'll use this command:
5\sRDIN\s\r\n <-- note the LabVIEW '\' codes display.
The command ends with a 'CR' and 'LF'.
The 'LF' tells the hardware to start processing the command and for some reason this did not work at all. It seemed like it was still waiting for the 'LF' (or \n) character.
Sure enough.... hooking up an Oscilloscope to the RS232 lines showed that the 'LF' (\n) was not being sent. It was stripped off before the command was sent over the TCP/IP connection.
When adding in a second 'LF' the communication works as expected. The working command looks like this:
5\sRDIN\s\r\n\n
Is this the way TCP Write is expected to behave or is this indeed a bug?
Why is the first 'LF' stripped away? Is there a setting somewhere in LabVIEW or is this a Windows thing?
I did notice some odd behavior when connecting via Telnet to this device. Connecting from windows command prompt with: "C
>telnet hostname port" works as expected but starting from the telnet prompt: "Microsoft Telnet>open host port" results in some kind of incomplete connection.
Have anyone else seen this strange behavior of TCP Write?
Thank you,
Christian Holmstedt