SICL

1 Introduction

SICL (Standard Instrument Control Library) is a software library that provides a standardized application programming interface (API) for controlling and communicating with electronic test and measurement instruments. Developed originally by Hewlett‑Packard (later Agilent and Keysight Technologies), SICL abstracts the underlying hardware interfaces—such as GPIB, RS‑232, USB, and Ethernet—allowing developers to write portable instrument control code. It is widely used in automated test systems, laboratory automation, and industrial measurement applications.

1.1 Historical background

The origins of SICL trace back to the early 1990s when Hewlett‑Packard sought to unify the diverse, interface‑specific programming models for its growing range of test instruments. Before SICL, each instrument interface (GPIB, RS‑232, etc.) required separate code and driver libraries. HP introduced SICL to provide a single, consistent API that could work across all of its hardware platforms. After HP’s instrumentation division became Agilent Technologies (1999) and later Keysight Technologies (2014), SICL continued to be supported and extended, though it was gradually supplemented by the broader VISA standard. Despite this, SICL remains in use in legacy systems and certain specialized environments.

1.2 Purpose and scope

The primary purpose of SICL is to simplify instrument control by hiding the complexities of different physical transport layers. It defines a set of functions for opening sessions, sending commands, reading responses, and handling events. The library is designed for both low‑level bit‑banging and high‑level command‑oriented communication. SICL also provides a framework for driver development, enabling manufacturers to create instrument‑specific drivers that adhere to the same API. Its scope covers all common test‑and‑measurement interfaces and supports both synchronous and asynchronous I/O.

2 Architecture

SICL’s architecture is layered, separating the user‑facing API from the interface‑specific hardware drivers.

2.1 Driver model

SICL uses a two‑level driver model: interface drivers and instrument drivers. This separation allows the same instrument control code to work regardless of the underlying connection.

2.1.1 Interface drivers

Interface drivers handle the physical and link‑layer details of a particular communication bus (e.g., GPIB, RS‑232, USB, LAN). Each interface driver is implemented as a dynamically loaded module that registers itself with the SICL runtime. When a session is opened for a specific interface, the runtime loads the appropriate driver and delegates low‑level operations to it.

2.1.2 Instrument drivers

Instrument drivers sit above interface drivers and provide a higher‑level abstraction. They may encapsulate the command sets of specific instruments, offering functions like measureVoltage() or setFrequency(). However, SICL itself does not mandate a particular instrument driver architecture; rather, it supplies the foundation on which such drivers can be built.

2.2 Session management

A session in SICL represents a communication channel between the application and an instrument (or an interface). Sessions are identified by handles and are used for all subsequent I/O operations.

2.2.1 Creating and closing sessions

A session is created with the siclOpen() function, which takes a string describing the logical instrument address (e.g., gpib0,1 for GPIB address 1 on interface 0). The function returns a session handle. When the session is no longer needed, siclClose() releases all associated resources. Sessions can also be created for specific interfaces without an instrument address (e.g., for direct interface control).

2.2.2 Default session

SICL supports a default session that can be set using siclSetDefaultSession(). This session is automatically used by API functions that do not explicitly take a session handle, simplifying code for single‑instrument applications.

2.3 Data types and error handling

2.3.1 SICL data structures

SICL defines a set of data types for representing addresses, status, and I/O buffers. Key types include INST (instrument session handle), ADDR (interface address), and STATUS (32‑bit status value). Additionally, structures such as SICLattr allow the retrieval and modification of session attributes.

2.3.2 Error codes

All SICL functions return a status code. A successful operation returns SICL_SUCCESS (0). Errors are indicated by negative values, such as SICL_ERR_NO_DEVICE or SICL_ERR_TIMEOUT. Applications can call siclErrorDescription() to obtain a human‑readable error string. The error model is synchronous; asynchronous errors are delivered via events.

3 Supported interfaces

SICL supports a wide range of physical and logical instrument interfaces, making it suitable for diverse test setups.

3.1 GPIB (IEEE 488)

GPIB (General Purpose Interface Bus) is SICL’s original and most mature interface. SICL provides full IEEE 488.1/488.2 functionality, including controller‑in‑charge operations, serial/parallel polling, and bus management commands. Addressing follows the gpib<board>,<address> convention, with an optional secondary address.

3.2 RS‑232 / serial

For serial‑port instruments, SICL supports standard RS‑232 (as well as RS‑422/485). Configuration parameters (baud rate, parity, stop bits, flow control) are set via attributes. The interface driver handles framing and timeout management.

3.3 USB (USBTMC)

SICL supports USB Test & Measurement Class (USBTMC) devices, which follow the USBTMC standard for instrument control over USB. The USB interface driver automatically discovers compatible devices and assigns them logical names (e.g., usb0::1234::5678::INSTR).

3.4 LAN (VXI‑11, TCP/IP)

Ethernet‑based instruments are accessible via VXI‑11 (RPC over TCP/IP) or direct TCP socket connections. SICL provides a VXI‑11 driver that supports the defined instrument discovery and communication protocol. Raw TCP/IP sockets are also available, allowing direct command‑response communication.

3.5 VXI backplane

For VXIbus instruments, SICL supports communication via the VXI backplane, including register‑based and message‑based devices. Addresses follow the vxi<logicalAddress> convention.

4 Programming with SICL

SICL is designed to be used from C and C++ (and, through wrappers, other languages). The API consists of about 40 core functions.

4.1 Basic operations (read, write, trigger)

The primary I/O functions are siclWrite(), siclRead(), and siclTrigger(). siclWrite() sends a command string to the instrument; siclRead() reads a response into a buffer. The siclTrigger() function generates a hardware trigger on interfaces that support it (e.g., GPIB GET or VXI backplane trigger). Timeouts for I/O are set via the IOTimeout attribute.

4.2 Synchronous vs. asynchronous I/O

By default, SICL performs synchronous I/O: the calling thread blocks until the operation completes or a timeout occurs. Asynchronous I/O is available via siclAsyncWrite() and siclAsyncRead(), which return immediately. The application can later check for completion using siclAsyncCheck() or wait for an event. This is useful for managing multiple instruments concurrently.

4.3 Event handling and callbacks

SICL supports event‑driven programming. Events (e.g., SRQ on GPIB, service request, data arrival) can be registered using siclInstallCallback(). When an event occurs, the specified callback function is invoked. Alternatively, the application can poll for events using siclWaitOnEvent().

4.4 Integration with other languages (C, C++, Python wrappers)

While SICL’s native API is C‑based, it can be called from C++ with standard linkage. Several third‑party Python wrappers have been created (e.g., pysicl), which expose SICL functions as Python objects. These wrappers simplify scripting in automated test environments, though they are less common than VISA‑based Python libraries.

5 Comparison with VISA

5.1 VISA overview

VISA (Virtual Instrument Software Architecture) is a more modern, industry‑wide standard API for instrument control, initially developed by the VXIplug&play Systems Alliance and later maintained by the IVI Foundation. VISA provides similar abstractions—session management, interface drivers, and attribute control—but with a more extensive and standardized function set.

5.2 Similarities and differences

Both SICL and VISA aim to provide portable instrument control. SICL is historically tied to Hewlett‑Packard/Agilent/Keysight hardware, whereas VISA is vendor‑neutral.

5.2.1 API abstraction level

SICL’s API is somewhat lower‑level than VISA’s. For example, SICL uses a single handle type for both instruments and interfaces, while VISA separates them into ViSession for instruments and ViSession for resources (a naming overlap that can cause confusion). VISA also defines richer resource classes and strict event‑handling rules. SICL’s error codes are numeric; VISA uses a more detailed status model.

5.2.2 Platform support

VISA is available on Windows, Linux, and macOS from multiple vendors (National Instruments, Keysight, etc.). SICL is mainly available on Windows and Linux (through Keysight’s IO Libraries Suite) and is less broadly supported. For new projects, VISA is generally preferred due to cross‑vendor compatibility.

6 Applications

6.1 Automated test equipment (ATE)

SICL is commonly embedded in ATE systems that require reliable, deterministic control of multiple instruments. Its session management and asynchronous I/O enable parallel testing and high throughput.

6.2 Laboratory data acquisition

In research laboratories, SICL is used to script data collection from oscilloscopes, multimeters, and signal generators. Its simplicity makes it suitable for rapid prototyping, though modern labs increasingly use VISA or LXI.

6.3 Manufacturing test systems

Manufacturing lines rely on SICL for its robustness and low overhead. Many legacy production test sets (e.g., for circuit‑board functional testing) continue to use SICL because of its proven compatibility with older HP/Agilent equipment.

7 Further reading

7.1 Official documentation

• Keysight Technologies, *SICL User’s Guide* (available from Keysight’s IO Libraries Suite documentation).
• Hewlett‑Packard, *Standard Instrument Control Library Reference Manual* (1994).

7.2 Related standards (VXI‑11, IEEE 488.2)

• VXI‑11: TCP/IP Instrument Protocol Specification (VXIbus Consortium).
• IEEE Std 488.2: Standard Codes, Formats, Protocols, and Common Commands.
• USBTMC: USB Test and Measurement Class Specification (USB Implementers Forum).