Technologies used in the Test & Measurement Industry - A quick perspective
Introduction
There are controllers and there are instruments. The Test & Measurement industry has created a good number of PC-based and embedded products (over 1000 to be sure) that have been based on a few industry standards. This document is an attempt to provide an introduction to some of the technologies used in this area - particularly GPIB and VXI.
Instruments can measure analog and digital inputs, and also generate analog or digital output, driving relays or creating waveforms. The concept is not limited to test & measurement, but also extends to data acquisition and control. The common configurations make use of PCI add-on cards to a PC, with software running on Windows (sometimes Solaris/HP-UX). The add-on card can connect to multiple instruments (housed in a chassis for example), or even other cards each connecting instruments/sensors etc.
To enable instruments from various vendors inter-operate or replace one another, physical bus standards were introduced. One is GPIB (General Purpose Instrument Bus - also known as IEEE 488.2) and the other is VXI (VMEbus extensions for Instrumentation). Standard command sets were defined to be sent over the bus, so instruments could be replaced with similar ones from another vendor, and one instrument could talk to another.
The instruments are connected to a GPIB bus controller, or a VXI bus controller, which is typically the add-on card to the PC. It is the controller that enables software to interact with the various instruments, acquire data, control it etc. Between the software and the controller, the PC's PCI bus is used. From the controller to the instruments, GPIB or VXI prevail.
Note that none of these "instruments" have a physical display, knobs etc. as in an oscilloscope or multi-meter. Instead, these are rendered visually on computer screens, or dispensed with and these "instruments" are used internally from software programs. The instruments themselves could be housed in a chassis, called the "mainframe", and controlled by a controller card on the PC. The controller card was also sometimes embedded into the mainframe(chassis), with ports for connecting a keyboard/display. Thus you have embedded VXI systems. The chassis could also be cascaded.
On the software side, three approaches were available to the user. One is interactive, graphically driven, specialized software that is meant for test & measurement applications. Such an application allows a user to lay out graphically the instruments, connect them together, set properties, outputs, inputs, voltages, and various attributes, and then execute a configuration or "program". National Instruments LabView and HP VEE are the prominent ones. Of this, LabView provides its own graphical layout and programming language called "G" for this purpose.
The other approach is to write C/C++/VC/VB programs directly with an instrument's driver, which is usually a DLL supplied along with the instrument. The documentation for the DLL will tell the programmer how to work with the instrument.
A synthesis of these two approaches, that combines a graphical framework from which C code is generated, is provided by the LabWindows product, from National Instruments.
In all these approaches, the Instrument Drivers provided by instrument manufacturers all had their own proprietary functions in a software library (e.g. a Windows DLL), and worked with (apparently) a specific set of controllers. This meant that, even though the instruments talked GPIB commands, the software DLLs themselves made inter-operability with instruments difficult. Also these Instrument Drivers were specific to the controller cards, meaning only a set of popular controllers would be supported.
The New(?) Approach
Recognizing this problem, a Plug-n-Play initiative was started by VXI, called the VXI PlugnPlay Consortium, with the aim to make any instrument be easily plugged and manipulated via software, regardless of the controller card's make or vendor. The framework would support not only VXI, but also GPIB, Ethernet, serial etc. buses. See www.vxipnp.org.
This called for two steps. One, to virtualize the communication between instrument drivers and the controllers, using a standard set of APIs. This was called the Virtual Instrument System Architecture, or VISA, which allowed the same set of APIs to be used to talk to a GPIB controller, or a VXI controller. (Talking to a controller is the equivalent of talking to the instruments on the controller's bus). An important note here. Even though the same set of APIs were to be used for different bus types, the parameters to those APIs would vary from one bus type to another. This could not be helped, because each bus has its own peculiarities. However, these APIs tended to collect instrument-related operations into standard functions, and if the bus-type was known, the parameters to be sent are also thus known. The VISA spec was then implemented by the vendors who make the controller cards (not the ones who make the instruments). All vendors who have a controller card for a particular bus type could now create such a DLL (VISA.DLL) and instrument drivers could use them regardless of the make/vendor. It is important to note here that VISA does not really virtualize an instrument, but the controller, and the I/O that occurs with it. This indirectly virtualizes the instruments to some extent by making access to these happen through the use of standardized APIs.
The second step was to standardize the Instrument Driver concept. Instruments are usually made by vendors, who are usually not the same ones who make the controller cards. These Instrument Drivers can all now use VISA (visa.dll) to converse with any compliant controller. It remained to make the interfaces exposed by these drivers to be standardized, so that software can use them easily, regardless of instrument type/make/vendor. This was accomplished by creating an Instrument Driver standard, which segregated lots of common functionality into standard API sets, so that 90% of most instrument capabilities would be mapped to those. The segregation was into sections like "Initialize, Configure, Action, Status, Data, Utility, Close" etc. To support any extra special features of an instrument, the whole source code for the standard Instrument Driver framework was provided by the VXI PlugPlay consoritum, and driver developers could extent by adding new functions. The resulting new driver is supplied in source code as well as DLL, along with documentation. This driver code utilized VISA to communicate with the instrument via the controllers. For other software to use these instrument drivers, in most cases, the standard APIs could be used as such, regardless of the instrument maker. The additional APIs could be programmed against.
In the GWIN framework (see figure) using LabView, however, such C source code modification is not possible. Instead LabView provides Instrument Driver templates written in G source code, which can be copied and slightly modified. The G code in turns calls VISA internally from LabView. So Instrument Drivers could be created wholly from within LabView without knowing C/C++ programming, and visually used in layout and test execution. However, LabView can automatically import an instrument driver DLL created in the WIN framework and visually present each of the functions in it as a "virtual instrument", so that a user can layout a setup using these icons. This makes the WIN framework more universal, applicable from LabView, LabWindows as well as VC++/VB and any programming language that can load a DLL.
An instrument manufacturer packages the following PlugnPlay software with the instrument. An Instrument Driver DLL, its source code, a Knowledge Base that defines the instrument features, specifications etc., Help documentation for programmers as well as for LabView users, and a Soft Front Panel application that demonstrates the usage of the Instrument Driver, and at the same time can be used to test the basic features of the instrument.
Notables
The VISA and PlugnPlay Alliance as formed in 1993, and the VISA standard, PlugnPlay specifications and other documentation were introduced around 1995. The latest modification has been in 2000. But hardly any major activity in the standard could be detected in the past 5 years or so.
LabView is a complex software in the hands of a vanilla software professional. It expects good understanding of electrical and electronic measurements practice, and the ability to design a measurement solution from constituent instruments, knowing about resistance, power requirements, circuit diagrams and so on.
Instruments also appear on other buses, like the Ethernet, serial, parallel etc. There are converters, like GPIB/serial, GPIB/firewire that enable such instruments to be plugged into a GPIB controlled chassis/interface and be used by popular test and measurement software.
PXI (PCIbus eXtensions for Instrumentation) is a popular emerging bus standard, derived from the PCI bus standard and VXI (the auxiliary signal set of VXI is adapted). This enables PXI-based systems to interoperate with Compact PCI cards, and also appear on the PCI bus of a computer transparently (The host PC to chassis link functions as a PCI bridge). PXI technology enables products to be generally smaller in footprint, cheaper and easier to integrate with a host system than their VXI counterparts. This is an emerging market.