Slow read of first character from VISA TCP/IP socket

[GeoffA]

A query (write, then read) for the status of an Ethernet connected controller results in an abnormally long delay receiving the first character of the status string from the controller.
The Ethernet controller is an upgrade of a GPIB version and has the same ASCII command set as the GPIB controller. Side by side, we compared the response of the two controller versions using NI-MAX and NI I/O Trace.

Controller:     GPIB interface               Ethernet interface
Resource:     GPIB::2::INSTR             TCPIP0::192.168.254.254::5001::SOCKET
Timeout:       3000                               2000
I/O Protocol:  Normal                          Normal
Termination: Send End on Writes       Send End on Writes
                                                            Enable termination character (\n)
Read duration: 6 ms                           1 ms

This looks reasonable. However, when using the VISA driver with the resource string for the TCP/IP resource, a delay of about 1 SECOND was noticed for the read response on this status query (normal completion, no errors). Delays using the same VISA driver with the GPIB resource string and its controller were about 10 ms. To find out where this delay was occurring, we took one character at a time from the Ethernet interface using the TCP Read in STANDARD mode and established that the delay was in receiving the first character in the 3 character status string - "0\r\n". The test VI for the TCP/IP read is attached. Our environment is Windows 10, LabVIEW 15 and NI MAX 17.0. What do you think causes this delay in the VISA TCPIP read and not in the NI-MAX Query?

[crossrulz]

Out of curiosity, why aren't you using the VISA driver for the Ethernet?  It can handle the instrument communications just fine.  Then you can literally use the same code you had for the GPIB version, except change the initialization to use the TCPIP0::192.168.254.254::5001::SOCKET resource instead of GPIB::2::INSTR.

[rolfk]

Nagle algorithme? NI VISA has actually a property called TCP NODELAY or something similar that you can use to disable the Nagle algorithme in the underlaying TCP/IP socket. 

[GeoffA]

Thanks for the feedback! Attached is a simplified version of the VISA calls where we originally discovered this problem. We then tried the simple TCP calls as well to see if the delay still occurred. It does.  Enabling the TCPNoDelay in this attached VI does not change things and still gives typical delays of 994 to 1010 ms. See the snapshot of the front panel.

I am now thinking that the socket setting TCP_QUICKACK may have something to do with this.

Geoff.

[rolfk]

Well TCP Nagle should be default only cause 200 ms delay so this can't really be it. But I have another guess! Do you append <carriage return> and/or <line feed> to your commands you send?

GPIB has a special hardware handshake line that is asserted with the last byte send over the bus. This way the device knows immediately when the entire command has been sent. On serial and/or TCP you do not have seperate handshake lines (obviously) so most devices use a termination character (sequence) to indicate that a command is finished. Some devices will do nothing if you don't terminate a write command, others will after some timeout without new characters arriving, attempt to parse and decode the command that has been received so far anyhow. Usually, devices that support serial and/or TCP/IP interfaces will also tolerate a termination character (sequence) appended to the commands send over GPIB. That way you still can use the same VIs to send commands, just add the termination character(s) always. A few weird devices do not like the termination character on the GPIB communication, in which case you would have to program a subVI that does the correct thing depending on the type of VISA resource.

[cstorey]

You're referring to the Newport motor controllers, ESP 301s and 302s?  301s have GPIB/USB/RS232 and 302 have Ethernet/RS232.  So are you comparing different models here?  https://www.newport.com/f/esp30x-3-axis-dc-and-stepper-motion-controller

These controllers aren't exactly fast, they are for high precision movement.  It might also depend on what sort of stage you have connected to your 302s.  DC, piezo, etc..  Some might respond faster than others. 

I think rolf is right it appears your termination characters are mismatched.  Your Ethernet interface table show end on write as "\n" and your code is using "\r".  In the GPIB VISA I think a "\n" would be appended automatically, but not in the ethernet case.  Though it looks like you have the timeout set to 5s...so, hmm.

[rolfk]

---

@cstorey wrote:

I think rolf is right it appears your termination characters are mismatched.  Your Ethernet interface table show end on write as "\n" and your code is using "\r".  In the GPIB VISA I think a "\n" would be appended automatically, but not in the ethernet case.  Though it looks like you have the timeout set to 5s...so, hmm.

---

No, GPIB VISA does no appending of anything to the sent data byte. What it does instead is to assert a special line ËOI on the GPIB bus with the last data byte transfer. This is controlled by te "Message Based Settings:Send End Enable" property which for GPIB is by default enabled (except for some very very old hardware it can't really hurt to assert this line even if a device would not evaluate it at all).

ASRL (serial port) is more complicated. Here the "Message Based Send: Send End Enable" does control if the special "Serial Port:End Mode for Write" is honored or not, in which you can configure if the termination character should be appended or not. In a somewhat inconsistent manner, the "Serial Port: End Mode for Read" does overwrite the meaning of the "Message Based Settings: Termination Character Enable" if it is set to "(2) Termination Character".

On GPIB, VXI, TCP Instr and USB Instr resources, "Message Based Settings: Send End Enable" causes the IEEE 488.2 defined End of message terminator according to the documentation which is a little ambigous. It basically means that the GPIB and VXI interfaces use a special handshake line, TCP/IP and USB Instrument Resources use a <cr> <lf>. Note that this does not appy to TCP Socket and USB Raw resources as they have no IEEE 488.2 operation mode at all.

Personally I never use the Send End Enable property at all (but the Termination Character and Termination Character Enable a lot). If a device requires a specific termination character to be appended to its commands I include them either explicitedly in all the commands I send or write a small utility VI that sends out the data strings and does the appending. This is especially useful for devices that require specifically different termination modes for different interface options, eg. most GPIB devices do not require an trmination (character) but are also not choking on commands that are terminated by such a termination character (sequence) as they typically discard these characters when parsing commands. So it is usually ok to just send this characters out anyways, but if there are differences between interfaces the commong Write Message subVI can be programmed to determine the resource type of a VISA session and act accordigly.

[GeoffA]

Hi Rolf and gang,

To answer your questions:
Yes, we intend to replace the legacy ESP300s and ESP301s with ESP302 Ethernet communication interfaces. Here is the rule for communication, taken from the ESP302 manual:
"A controller command (or a sequence of commands) has to be terminated with a
carriage return character. However, responses from the controller are always
terminated by a carriage return/line feed combination. This setting may not be
changed."
Since motors on this system are plug and play with the same drive and the example provided is a status request (MOTOR ON?), the motor type does not materially affect the response speed, since the status is from the controller and drive.
We include the \r in each command and specify that the \n terminates the response to avoid timeouts. The CRLF is stripped in the application when parsing the response. So, here are the typical calls on each interface using the NI MAX VISA test panel for each instrument:

Instrument ESP300 ESP302
Resource string              GPIB::2::INSTR              TCPIP0::192.168.254.254::5001::SOCKET
Send END on Writes      DISABLED                      DISABLED
Enable term char            DISABLED                      ENABLED (\n)
Suppress END on read          ---                             DISABLED
Command sent               1MO?\r                            1MO?\r
Return count                   5 bytes                            5 bytes
Read op retn count         3 bytes 0\r\n                    3 bytes 0\r\n
Call duration                    00:00:00.0070                 00:00:00.0000 (from NI IO Trace)

The delays of 1 second on LabVIEW VISA reads on ESP302 as shown in previous post attachments occur on all tested queries, such as 1MO? (motor on?), VE? (revision), 1MD? (motion done) and VA? (actual velocity). Playing with [Suppress End En], [Send End En], [IO Prot] and [TCP NoDelay] doesn't seem to help. What is the difference between the VISA test panel reads and the LabVIEW VISA Read? I logged the TCP/IP packets on Wireshark (See attached file) and the results are:
1) The NI-MAX VISA test panel query has 3 packets (No. 11-13 attached PNG): the [PSH, ACK] write packet (5 bytes data), the [PSH, ACK] read packet (3 bytes data) and an [ACK] 0 data - 4 ms total.
2) The LabVIEW VISA query has 9 packets (No. 1-9 attached PNG): packets 1 to 5 setting SACK_PERM=1 and sending the query. Packets 6 to 9 sending the reply after 1 second with [FIN, ACK] handshake and [ACK] from the PC to the ESP302 - 1 second.

Any comments?

[GeoffA]

In conclusion:

• A test of the same VI results in identical delays on another LabVIEW system.
• We also used an alternative interface (RS232) to the ESP302 controller and verified that the VI runs with 7-11 ms delays in response times, compared to the 1 s delay with the Ethernet interface.
• For the Ethernet interface, a change in the VI to request status continuously in a While loop has clarified the situation. After the Open VI and then property change VIs, the delay is often there on the first status request call, but does not persist. Delays of 2 ms are then typical. We suspect that the 1 s delay has something to do with the opening of the session and property setups.
• The application was adjusted to avoid issues with this delay.

[JohnHWhite]

I am trying to control the ESP302 via RS232 but through a RS232 to USB adaptor as well as the adaptor supplied by Newport (Previously we used the ESP301 via USB). Ethernet is fine but via RS232/USB all I get is timeouts 

I am guessing you connected directly to a RS232 port on a PC?

The settings are as per Newport's example code for the ESP301