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

[SManMTB]

---

@pincpanter wrote:

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.

---

I don't know for sure..... It could be the Lantronix but this equipment is already controlled by a Linux machine via python and it works just fine.

The reason to move to LabVIEW is to get away from basically a command line interface and entering a few different scripts.

Snce it works under Linux/Python with no problems and there are problems with Win10/LabVIEW the logical suspect is the new setup. But again... I don't know why this is happening.

Sending \n\n instead of \n solved the problem for now.

Communicating with it via Telnet works just fine. The \n (LF) is being transmitted as it should.

[SManMTB]

---

@RavensFan wrote:

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.

---

That looks very much like it.

I have not changed anything in its setting since it was working as expected under Linux/Python.

[SManMTB]

---

@rolfk wrote:

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.

---

No I have not tried an earlier version and I don't have access to one.

[nixiebunny]

Hi. I' m the engineer who built this system. The XPort is not causing the problem. We have been using this XPort (among many others) for ten years with many Linux systems, and we have never seen this odd behavior of the first newline being swallowed. Only with Labview does this occur.

So... is this a feature of Labview, or a bug? If it's a feature, what sort of feature is it? Is there a configuration to disable this behavior?

[SManMTB]

---

@nixiebunny wrote:

Hi. I' m the engineer who built this system. The XPort is not causing the problem. We have been using this XPort (among many others) for ten years with many Linux systems, and we have never seen this odd behavior of the first newline being swallowed. Only with Labview does this occur.

So... is this a feature of Labview, or a bug? If it's a feature, what sort of feature is it? Is there a configuration to disable this behavior?

---

 Hi Dave 🙂

It's very odd...

[rolfk]

And did you check with Wireshark what is sent over the wire? Both in case of LabVIEW and with your Python solution? While I haven't checked on LabVIEW 2016 I can assure you that any earlier version of LabVIEW did NOT translate <cr><lf> to a single <cr> when using the TCP Write node.

Or are using VISA for the communication?

[SManMTB]

@interfacerolfk wrote:

And did you check with Wireshark what is sent over the wire? Both in case of LabVIEW and with your Python solution? While I haven't checked on LabVIEW 2016 I can assure you that any earlier version of LabVIEW did NOT translate <cr><lf> to a single <cr> when using the TCP Write node.

Or are using VISA for the communication?

---

I did try to run Wireshark under Win10 but the program didn't even see an interface to capture from so that venture died from the start.

I'm sure it is a great tool but easy to use it is not... and I'll pass on trying to get it going under Linux. It's a critical machine and.. well, not going to touch it.

VISA is not used for the communication. Plain low level functions from the TCP/IP menu.

- 'TCP Open' connection to host

- 'TCP Write' data

- 'TCP Read' data from device

- 'TCP Close' connection

As far as I'm concerned the communication is working now but of course I am curious as to what is the root cause of this. I do however not have time to dive very much deeper into this at this point.
Thx for the feedback.

/CH