Full Stack Overview

Overview of the different standards.

Programming Interfaces

SCPI

Standard Commands for Programmable Instruments - also often called “skippy”, is a set of commands based on ASCII characters. It was first introduced in 1992 by the SCPI Consortium, which was later integrated into the IVI Foundation. It expanded the IEEE 488.2 command set from 1987 which already defined some common commands like:

*IDN? - Query the ID string of the instrument.
*RST - Restore the instrument to the default state.

The goal was to ease the task of implementing test & measurement (t&m) applications by unifying common commands. This has been successfully achieved since almost all of the modern instruments support the standard. It is also very persistent with the last changes having been made in 1999. The commands introduced with SCPI have the following syntax:

  • Commands are structured into keywords.
  • Commands usually start with, and keywords are separated by ‘:’.
  • Query commands are indicated by a ‘?’ at the end.
  • All commands are case insensitive.
  • Keywords can be abbreviated e.g. ‘CHANnnel’ becomes ‘CHAN’

An example of a query of the current offset voltage of channel 1 on a generic oscilloscope:

:CHAN1:OFFS?

SCPI does not specify the physical communication layer, data can be transmitted over different bus systems like GPIB, RS232, USB, VXI or LXI.

Pros

  • A minimal amount of requirements
  • No need for an IVI driver (except when connecting via ethernet, LXI)
  • Good level of abstraction / high code readability

Cons

  • Errors are first caught by the instrument.
  • ASCII string manipulations are compute-intensive, although modern computers can handle them very quickly, which makes SCPI unsuited for high-speed applications.
  • Low interchangeability

VXI Plug&Play Drivers

In 1993, the VXI plug&play Systems Alliance first created the specifications. By using a VXI plug&play driver, you can access the instrument by calling a subroutine in your programming language instead of having to format and send an ASCII string as you do with SCPI. Unlike IVI drivers, programming interfaces differ between manufacturers, so you can not exchange instruments without refactoring the code.

IVI Drivers

IVI (Interchangeable Virtual Instruments) drivers are divided into 13 classes, which correspond to the type of instrument they interface e.g. dmm, scope, fgen. For any IVI driver developed for a DMM, the measurement command is IviDmmMeasurement.Read, regardless of the vendor. However, there still exist, instrument-specific drivers, since some models may offer additional capabilities which go beyond the common functionality of the class driver. Note that there are also three different IVI driver types: IVI.NET, IVI-COM and IVI-C. And two generations 2003 and 2014. To search for a driver look up the driver registry on ivifoundation.org, there you can also which features are supported by the driver.

Shared Components: You must install the IVI Shared Components before an IVI driver can be installed.

Pros

  • Interchangeability – Exchange of instruments with minimal code changes.
  • Simulation – Code development and testing without hardware.
  • Range checking – Ensures parameters are in spec.
  • State caching – I/O is only performed when necessary.
  • Good level of abstraction / high code readability

Cons

  • Complicated - High upfront time investment to learn.
  • Support - The user depends on the manufacturer to provide the driver.

IO/Software Protocols

VISA

Virtual Instrument Software Architecture was also first introduced by the VXIplug&play Systems Alliance and is now maintained by the IVI Foundation. Multiple vendors provide VISA I/O libraries – Anritsu, Bustec, Keysight, Kikusui, National Instruments, Rohde & Schwarz, and Tektronix.

Some links:

Sources