The VXIbus from an instrument designer's perspective - VMEbus Extensions for Instrumentation - includes related articles on message-based VXI instruments and a mainframe computer with a register-based interface - Technical

Hewlett-Packard Journal, April, 1992 by Steven J. Narciso, Gregory A. Hill

HP has defined a set of internal standards to compensate for some missing aspects of the VXIbus standard that are critical to instrument design.

The VXIbus specification defines a technically sound modular instrument standard that addresses electrical, mechanical, EMC/Power, and communication requirements for instrument modules. Although extensive, the VXIbus standard does not cover certain information that is critical to an instrument's design. For this reason, it becomes necessary for a VXIbus instrument manufacturer to define an internal standard to supplement the VXIbus specification.

The internal standards developed by HP enable instrument designers to provide customers with a consistent "look and feel" and functional interoperability. These standards also provide designers with common hardware interface and firmware design guidelines so that they can focus on specific instrument features and not on system design.

HP has concentrated its internal standardization efforts in four areas: a common instrument language, hardware interface, soft front-panel design, and industrial and mechanical design. This paper will cover these areas and other supplemental HP standards.

SCPI: A Common Instrument Language

Until recently a test engineer had to deal with a variety of instrument programming languages and formats. Data was transferred in almost every format imaginable, from ASCII to device dependent compacted binary. When a new instrument was introduced, the engineer could look forward to rewriting the majority of the instrument driver code, even if the new instrument was a direct replacement from the same manufacturer.

In 1987, IEEE standard 488.2 was approved. This standard provides a level of standardization in message and data formats, message exchange protocols, and common commands to be shared among a wide range of devices. This standard allows computer languages to speak in a consistent manner to instruments and enables higher-level instrument test executives to be written. IEEE 488.2 defines a few common commands that address the housekeeping functions of the instrument. The standard intentionally does not define commands that are necessary for measurement or signal configuration. This is the area that the industry's Standard Commands for Programmable Instruments (SCPI) addresses. SCPI is used by all of HP's VXIbus modules.

Originally HP's Test and Measurement System Language, SCPI builds upon existing standards wherever possible, including IEEE standard 488.2 and IEEE Standard 754. The result is a language that is orthogonal, powerful, extensible, and yet familiar and friendly to users. The language never refers to instrument types, only to instrument functions. Therefore, SCPI applies to a wide variety of instruments, from power supplies to network analyzers. We refer to this consistent coverage of all instruments as horizontal compatibility. The language also offers vertical compatibility, or consistent coverage of succeeding generations within an instrument family.

Mnemonics

SCPI uses a formal set of truncation rules to generate ninemonics. The rules are stated as follows:

* If a keyword is four characters or fewer, the keyword itself is the mnemonic (e.g., AUTO, ON, OFF).

* If the keyword is longer than four characters the mnemonic is the first four characters of the keyword (e.g., OUTPut).

* If the resulting mnemonic ends with a vowel, the mnemonic is truncated to three characters, dropping the trailing vowel (e.g., ATTenuator).

* If a phrase is used instead of a single word, the keyword uses the first character of the first words, followed by the entire last word (e.g., Kaiser BESsel).*

Hierarchical Structure

Keywords are joined to form a compound header element consistent with IEEE 488.2. This produces a hierarchical language. Thus, to set the input attenuator the command would be INPut:ATTenuator. There are several reasons for choosing a hierarchical structure. First, a four-character mnemonic becomes quickly overloaded, even within a single instrument. Collisions often occur that must be resolved by violating the nmemonic generation rules. By making the language hierarchical, keywords can have meaning within the context of their tree position, and collisions effectively disappear. For example, to set an output attenuator, the command would be OUTPut:ATTenuator. Both the input and output subsystems use the keyword ATTenuator without conflict because they appear in different places in the tree.

Default Node

Some functions are executed more often than others, and the most common functions need to have short and easy-to-use keywords. SCPI accommodates this by placing default nodes at critical points in the tree. Default nodes do not need to be sent as part of the command. For example, there are several commands associated with output conditioning such as attenuator, filtering, offsets, and output enabling. We determined that output enabling was the most commonly used function. Therefore, we added the command OUTPut[:STATe], which enables the instrument's output. The application can send either OUTPut:STATe ON or simply OUTPut ON to enable an output. Default nodes play an equally important role in allowing the language to be extensible. For example, if we had a command in the output section called FILTer, which enabled a low-pass filter, and we wished to add a command that enabled a high-pass filter, a conflict would exist. The new command creates a further qualification of the keyword FILTer. To add the new command, one would add a default node to the existing command under filter, describing the additional qualification. Thus, the existing command would become OUTPut:FILTer[:LPASs]. We could then add the new command as OUTPut:FILTer:HPASs. It is important to extend by adding default nodes because the default node allows applications written for the old instrument to continue to work with the new extended capability instrument. The application can still send OUTPut:FILTer and expect it to function the same as it did before the extensions were made.