LabVIEW
Serial communication over ethernet using Lantronix XPort Pro Lx6
HI Massimo,
VISA Write and viWrite are the same, as well as are the other functions. viWrite is the actual name of the function in NI-VISA's C code-base, see e.g. viWrite - NI-VISA 15.0 Help.
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.
No this device does almost certainly not support the VXI-11 standard. The Lantronix people propably also only know VISA as a credit card company. 
It can still work through VISA if you use the VISA TCP/IP socket communication modus, so the VISA resource name will be:
TCPIP::xxx.xxx.xxx.xxx::port::SOCKET
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.
Or you can also use the LabVIEW native TCP nodes which basically work exactly the same way.
@massimo76no wrote:
I must point out few tips:
- the escape sequences (e.g. \r \n) that work in MAX are not effective with VISA blocks (there are posts on this issue)
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.
If you do not want to use that VI for whatever reason you have to wire a property node to the VISA session and select the correct properties yourself to write these values to it.
