Bug / Unexpected behaviour of 'TCP Write' (LabVIEW 2016).

[SManMTB]

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

[rolfk]

I never have seen this happening! Protocols like HTTP do use <CR><LF> as part separator and I have written several VIs implementing a (crude) form of HTTP in the past. Is this something that only happens in 2016? Did you try on an earlier version of LabVIEW? I still haven't gotten around to install 2016 on my working machine.

[pincpanter]

How do you know the last character is dropped by TCP write rather than the XPort?

Put up your own TCP server on another computer and check what's received.

[rolfk]

Or use Wireshark to see what is really transmitted. It may be not trivial as the message is likely embedded in some binary data block for the Ethernet to RS-232 server, but might be a good way to check.

[pincpanter]

Rolf, there is no special driver for XPort. Just open the TCP connection directly with the device and send data (UDP is also available). Fairly transparent unless some very special configuration are set (e.g. requiring a connection password).

[rolfk]

Then Wireshark is definitely the most simple solution to verify that. And I'm almost 120% certain that it is some protocol conversion setting in the Xport that is eating the <lf>, something like convert <cr><lf> to a single <cr>. Those devices tend to have a whole bunch of configuration settings that can be used to mix and match the network side with the serial port side.

[RavensFan]

Is this your device?  http://www.lantronix.com/wp-content/uploads/pdf/XPort_UG.pdf

Check out page 29.  It has a setting about sending trailing bytes that defaults to none.  I wonder if the CR is considered the termination characters and it is set to send nothing after that (in this case the LF).  Maybe Match 2 byte sequence would help and could be CR and LF.

[pincpanter]

The available documentation is not very good. Those settings actually affect the outbound stream (serial to network), moreover they only concern output timing, not output content. In principle there is no filtering in neither direction whatever setting you apply. In principle.

[rolfk]

In principle you are right. In practice I really suspect those RS-232 server devices to do something, that is not quite explicitly documented, than that LabVIEW suddenly magically starts to eat characters that it never did in earlier LabVIEW versions.

[SManMTB]

<Deleted>