Using the TCPIP Interface Type for LAN Access
This section contains information that applies to both Windows and Linux.
VISA provides the TCPIP interface type to communicate with LAN-connected devices. These can be devices connected directly to the LAN, or they can be connected to the LAN through a LAN gateway, such as the Keysight E5810 LAN/GPIB gateway, or through Remote IO Server software running on a remote computer with instruments connected to it.
The TCPIP interface type supports these protocols:
- VXI-11 (TCP/IP Instrument Protocol) is a networking protocol, developed by the VXIbus Consortium, which permits interoperability of LAN software from different vendors. This protocol supports SICL and VISA operations to a LAN-based VXI-11 instrument, SICL operations over the LAN to GPIB or VXI interfaces (message-based devices only), and VISA operations over the LAN to GPIB interfaces. The VXI-11 protocol does not support serial or USB interfaces.
- High-Speed LAN Instrument Protocol (HiSLIP) is a protocol for TCP-based instrument control that provides high-speed performance while maintaining the instrument-like capabilities of conventional test and measurement protocols.
- SICL-LAN is an older networking protocol developed by Keysight Technologies. The SICL-LAN protocol supports SICL operations over the LAN to GPIB, VXI (message-based devices only), USB, and RS-232 interfaces.
- Raw socket connection is a protocol for instruments that do not support a higher-level protocol. The SOCKET resource exposes the capability of a raw network socket connection over TCP/IP. This usually means Ethernet but the protocol is not restricted to that physical interface. Services are provided to send and receive blocks of data.
Like HiSLIP, sockets is a "fire and forget" sender protocol. This means that when a command is sent over sockets (or HiSLIP), the protocol writes it to the connection, but does not verify that the command has been received or processed by the instrument before returning from the send. This can sometimes cause command execution problems when making multiple connections to an instrument, see Multiple Connections for ways to ensure proper command execution.
The protocol(s) you will use depends upon the devices you are using and the protocol(s) that they support. Many instruments support multiple protocols.
Using the SICL-LAN or VXI-11 Protocol
For VXI-11 or SICL-LAN, the format of a TCPIP VISA resource string is:
TCPIP[board]::hostname[::LAN device name][::INSTR]
where:
-
board = board number (default is 0)
-
hostname = the hostname or IPv4 IP address of the LAN device or server.
IPv6 addressing cannot be used with the VXI-11 or SICL-LAN protocols. IPv6 is supported for HiSLIP and Raw Sockets.
-
LAN device name = the remote device name (case sensitive with default name of inst0)
The VXI-11 protocol constrains the LAN device name to be of the form inst0, inst1, … for VXI-11.3 devices and gpib0,n, gpib1,n, … for VXI-11.2 (GPIB Emulation) devices.
The SICL-LAN protocol allows any valid SICL name for the LAN device name. A valid SICL name must be a unique string of alphanumeric characters, starting with a letter.
The following table shows some examples of TCPIP resource strings.
String |
Description |
---|---|
TCPIP0::123.456.0.21::gpib0,2::INSTR |
A VXI-11.2 GPIB device at a machine whose IP address is 123.456.0.21. |
TCPIP0::myMachine::inst0::INSTR |
A VXI-11.3 LAN instrument at hostname myMachine. |
TCPIP::myMachine |
A VXI-11.3 LAN instrument at hostname myMachine. Note that default values for board = 0, LAN device name = inst0, and the ::INSTR resource class are used. |
TCPIP0::testMachine1::COM1,488::INSTR |
An RS-232 device connected to a LAN server or gateway at hostname testMachine1. This device must use SICL-LAN protocol since RS-232 devices are not supported by the VXI-11 protocol. |
TCPIP0::myMachine::gpib0,2::INSTR |
A GPIB device at hostname myMachine. This device must use SICL-LAN protocol since gpib0,2 is not a valid remote name with the VXI-11 protocol. |
TCPIP0::myMachine::UsbDevice1::INSTR |
A USB device with a SICL alias of UsbDevice1 connected to a LAN server at hostname myMachine. Note that the SICL alias is defined on the remote machine, not on the local machine.
Although the SICL and VISA alias names are normally the same, if they are not, you must be sure to use the SICL alias and not the VISA alias.
This device must use the SICL-LAN protocol since USB devices are not supported by the VXI-11 protocol. |
TCPIP0::myMachine::usb0[2391::1031::SN_00123::0]::INSTR |
A USB device with:
Manufacture ID = 2391 Model Code = 1031 Serial Number = 'SN_00123' USBTMC Intfc # = 0
connected to a LAN server at hostname myMachine.
This device must use SICL-LAN protocol since USB devices are not supported by the VXI-11 protocol. |
![]() |
A LAN session to a remote interface provides the same VISA function support as if the interface were local, except that VXI-specific functions are not supported over LAN. |
Addressing a Session Using the TCPIP Interface Type
This sample shows one way to open a device session with a GPIB device at primary address 23 on a remote PC that is running a LAN server. The hostname of the remote PC is myMachine. See Programming with VISA, for more information on addressing device sessions.
ViSession defaultRM, vi;.
.
viOpenDefaultRM(&defaultRM);
viOpen(defaultRM, "TCPIP0::myMachine::gpib0,23::INSTR", VI_NULL, VI_NULL, &vi);
.
.
viClose(vi);
viClose(defaultRM);
Using the HiSLIP Protocol
HiSLIP works at nearly the speed of raw sockets, allowing fast query/response transactions and fast bulk data transfers while still supporting the instrument-like capabilities of conventional test and measurement protocols. The HiSLIP protocol is similar to VXI-11; however, there are differences, see Comparing HiSLIP and VXI-11 Systems for details.
HiSLIP Features
- In addition to high-performance with instrument-like capabilities, HiSLIP has the following features.
- Reliable end of message (EOM) signaling, regardless of data sent.
- Asynchronous service request (SRQ) signaling (viInstallHandler, viEnableEvent support VI_EVENT_SERVICE_REQ).
- Status byte (viReadStb) readable regardless of the data/command state of the instrument, including when the instrument is hanging on a command).
- Device Clear (viClear) clears the connection of data and commands, including when the instrument is hanging on a command.
- Supports remote/local status and control (viGpibControlREN, VI_ATTR_GPIB_ADDR_STATE, and VI_ATTR_GPIB_REN_STATE).
- Enhanced locking:
- Shared and exclusive locks are maintained in the instrument, allowing locks to be honored by all hosts attempting HiSLIP connections to the instrument.
- Delayed lock error reporting allows more natural lock enforcement. See HiSLIP Locking Behavior for details.
- Stale responses are detected and suppressed via interrupted error handling.
- Supports both IPv4 (Internet Protocol version 4) and IPv6 (Internet Protocol version 6) connections. IPv4 uses a 32-bit address space; IPv6 uses a 128-bit address space.
- For more information on the HiSLIP protocol, see the HiSLIP specification and the latest VISA specification. Both specifications are available at www.ivifoundation.org.
Identifying HiSLIP Devices
An instrument that supports HiSLIP is identified in the system by its VISA address. The address syntax is
TCPIP[board]::host address[::HiSLIP device name[,HiSLIP port]][::INSTR]
![]() |
The HiSLIP device name must begin with hislip to establish a HiSLIP session. |
For example, a typical HiSLIP VISA address for a TCP/IP device located at IPv6 IP address fe80::1 is:
TCPIP0::[fe80::1]::hislip0::INSTR
HiSLIP VISA Attributes
The HiSLIP protocol introduces three VISA attributes for HiSLIP devices:
Attribute |
Attribute Value |
Description |
---|---|---|
VI_ATTR_TCPIP_HISLIP_OVERLAP_EN |
0x3FFF0300UL |
If VI_TRUE, enables overlap mode for HiSLIP. If VI_FALSE, the synchronous mode is used. Refer to Synchronous and Overlap Modes for a description of these modes. |
VI_ATTR_TCPIP_HISLIP_VERSION |
0x3FFF0301UL |
Returns the ViVersion in use by the current HiSLIP session. For example, HiSLIP version 1.0 returns a ViVersion value of 0x00100000. |
VI_ATTR_TCPIP_HISLIP_MAX_MESSAGE_KB |
0x3FFF0302UL |
Specifies the largest size HiSLIP message VISA will accept in units of kilobytes; defaults to 1024 (a 1 MB maximum message size). |
HiSLIP Locking Behavior
The HiSLIP protocol introduces these locking behaviors:
- Lock enforcement for HiSLIP devices is done by the HiSLIP device.
- viLock() pushes shared and exclusive locks requested on HiSLIP connections to the HiSLIP device, with the exception of nested locks.
- Lock-respecting VISA operations are sent to the device.
- If the HiSLIP device is locked and the current session does not have the lock, the operation is delayed until the lock is released.
- If VISA times out on an operation on a HiSLIP connection, VISA checks whether the HiSLIP device is locked. If a lock delayed the operation too long, it returns a (delayed) VI_ERROR_RSRC_LOCKED return value.
- Device Clear on a HiSLIP connection clears any queued operations delayed by a lock.
- viUnlock() sends an unlock request to the HiSLIP device as the last of any nested locks is unlocked.
- VI_RSRC_LOCK_STATE [VI_ATTR_RSRC_LOCK_STATE ] now returns the lock state across all open connections of the same interface and protocol. For HiSLIP, this requires querying the HiSLIP device for the lock state.
Comparing HiSLIP and VXI-11 Systems
HiSLIP and VXI-11 systems are similar in many ways. For example, both systems support sub-instrument addressing. HiSLIP can be used as a functional replacement for VXI-11, but there are some differences:
- Performance: HiSLIP is significantly faster than VXI-11. If your program has timing dependencies based on VXI-11 performance, you may need to change it to accommodate the faster HiSLIP.
- Multiple connections: HiSLIP permits many simultaneous active connections, whereas VXI-11 only allows one connection at a time. It is your responsibility to coordinate instrument operations on multiple connections, for example by using locks (see below). Locks guarantee that the operations done while the lock is active are complete before the lock is released. That ensures that all instrument changes made by a HiSLIP connection holding the lock are complete before any other HiSLIP connection can have its commands executed. Even if your application ensures HiSLIP connections do not overlap, you should make sure that all operations requested by a particular HiSLIP connection are complete before closing that connection (for example by using *OPC? at the end of the command sequence on the connection). Otherwise, the next HiSLIP connection might interfere with the completion of the last HiSLIP connection’s instrument operations.
- Fire and forget: Like sockets, HiSLIP is a "fire and forget" sender protocol. This means that when a command is sent over HiSLIP (or sockets), the protocol writes it to the connection, but does not verify that the command has been received or processed by the instrument before returning from the send. By contrast, VXI-11 handshakes each command, so that the send does not return until the command has been received at the VXI-11 driver layer in the instrument.
- Locking:
- Shared locks: HiSLIP holds both shared and exclusive locks in the instrument. VXI-11 holds exclusive locks in the instrument, but shared locks in the VISA layer. Because of this, HiSLIP can coordinate shared locks across multiple test controllers, whereas VXI-11 cannot.
- Lock errors: HiSLIP utilizes "lazy" lock errors: If an instrument is locked when a command is sent via HiSLIP, the sent command is buffered in the instrument and the protocol waits briefly, to allow the lock to be released. If the lock is released in a timely manner, there will be no error. If not, a subsequent viRead may time out and return a lock error. In VXI-11, lock errors are returned immediately.
- HiSLIP and VXI-11 locks are independent: A HiSLIP lock will not lock out operations on a VXI-11 connection, nor will a VXI-11 lock affect operations on a HiSLIP connection.
- IPv6 support: HiSLIP supports both IPv4 (Internet Protocol version 4) and IPv6 (Internet Protocol version 6) connections. IPv4 uses a 32-bit address space; IPv6 uses a 128-bit address space. VXI-11 does not support IPv6.
- Interrupted errors: HiSLIP detects and corrects interrupted errors by default, but can also be operated in an overlapped mode where interrupted errors are ignored but responses are sent as quickly as possible from the HiSLIP system.
- Modes: The HiSLIP synchronous mode is similar to VXI-11, GPIB, and USBTMC behavior. Overlap mode is unique to HiSLIP. Both synchronous and overlapped modes are discussed in the next section.
Synchronous and Overlap Modes
In synchronous mode, HiSLIP detects and corrects for interrupted errors. In overlap mode, HiSLIP ignores interrupted errors and sends responses as quickly as possible. The mode is controlled by the VI_ATTR_TCPIP_HISLIP_OVERLAP_EN attribute.
Synchronous Mode
In synchronous mode, VISA and the instrument work together to discard stale responses. For example, if your program sends two queries, but does just one read, the first response is discarded and the second response is read. In some cases, when an interrupted error is detected by the instrument, an error is sent to the instrument’s error log.
Overlap Mode
Overlap mode allows multiple operations to be initiated and conducted independently of the rate the device processes messages and sends responses. In overlap mode, stale responses (interrupted errors) are ignored and the instrument is free to send responses as soon as they occur. The responses are returned in the same order the messages were sent. Your test application is responsible for associating the responses with the queries that generated them (by reading the responses in the order that the queries were sent).
Creating a HiSLIP Program
Since HiSLIP programming is similar to VXI-ll programming, you can start with any sample program for an instrument that uses an IO interface and change the address string. For example, change the address string in the viOpen() call to:
err = viOpen(rmSession, "TCPIP0::myInstHostname::hislip0::INSTR", VI_NO_LOCK, 4000, &viSession);