Lantronix Serial To Ethernet Manual

0 views

Skip to first unread message

Poochie Tenharmsel

unread,

Aug 3, 2024, 4:57:25 PM8/3/24

to neuvedonla

I am trying to convert the interface of a motor driver pcb from RS485 to ethernet. To do this I am using a Lantronix XPort Lx6 device which I am confident has been wired correctly to the old motor control pcb but I am not sure if I have set it up correctly in labview.

I then used a simple VISA write/read vi (selecting the new interface as the VISA control) and queried the device with "*IDN?" which would normally return something along the lines of "motor drive 1.0". However, the return string is actually some html code (594 characters long) which bears no resemblance of what I would normally expect.

Unfortunately, I have never seen a Lantronix XPort myself. From its data sheets I understand it does not support VXI-11 (so it is not an LXI instrument), so VISA seems the wrong way to go. I could still work with the XPort though, as maybe they have implemented it, and just don't want to guarantee it.

Have you found out how the protocol it expects looks like? The original posting in the thread stated the SCPI command "*IDN?". Does the XPort accept this directly on the Ethernet port? Or is it using more like a telnet or another TCP protocol to set up a connection and THEN does the SCPI communication transparently inside this connection? The last post in the thread VI for Lantronix Embedded Servers ( ethernet to serial converter ) seems to acknowledge the first option.

But in this way you are communicating directly on the TCP/IP socket level so you will need to read the Lantronix manual to see what commands you need to send it in order for it to transmit data to the serial port and read data from the serial port.

- the device you are controlling replies with messages that contain CR or LF characters, VISA will stop reading (in my case the instrument starts its reply with LF, therefore I must cascade two VISAread to get the right information).

They have nothing to do with the VISA blocks. That is a feature of the user interface in the Interactive Control Panel in MAX and can be also made to work in LabVIEW by right clicking on the string constant (or frontpanel control) and selecting "Enable \ codes". Basically this backslash escaping is something that I think was invented in C and taken over by many other environments including LabVIEW. Without that option enbled, typing in "\n" in a LabVIEW string wil simply add two 8 bit characters into the string, one for the "\" and one for the "n". With that option enabled, the LabVIEW string considers the "\" character as an escape character that tells it how to interprete the following character, translating the "\n" sequence into a single 8 bit character with the numeric value or ASCII value 10 or 0xA.

- the device you are controlling replies with messages that contain CR and? LF characters, VISA will stop reading (in my case the instrument starts its reply with LF, therefore I must cascade two VISAread to get the right information).

That's a dirty workaround. The real fix is to change the termination character for the VISA session on which VISA Read will stop when you request data. If you use the VISA Configure Serial Port (Instr).vi function, you have two inputs that determine the termination character behaviour of a VISA sessions. One is a boolean that enables or disables the read on termination character functionality, the other is an integer to which you can wire a numeric constant for the termination character to end reads. For your case you want to wire up a 10 (or in hex notation 0xA) value to that input. By not so strange coincidence the default values for VISA Configure Serial Port (Instr).vi already contain these values.