As manager, you should know and understand all phases of a project under your direction. But don’t kid yourself. With the many projects you supervise, this goal is tough–sometimes impossible–to achieve.
To help you with those critical test software decisions, here is an overview of the software architecture of instrument controllers. This article breaks this subject into component parts so you can become acquainted with the architectural elements and the software needed to make an instrument controller work effectively.
Software Architecture Components
Users of test software talk about an application running on a computer (PC or workstation) and controlling an instrument external to the computer. On the other side of the instrument is the device under test (DUT).
The major software and hardware components of a controller are represented in Figure 1. The interface hardware and controller, both hardware components, are included for a more complete representation.
The functions of these components are:
(o) Controller–The computer for the instrument controller task. Typically, this is a PC or a workstation.
(o) Interface Hardware–Hardware that is part of the controller, such as plug-in GPIB cards, GPIB ports built into the computer, or RS-232 ports.
(o) I/O Drivers–Provides data exchange between I/O devices and the controller. For example, when the application sends the command “Measure DC Volts” to the voltmeter, the I/O driver ensures the correct GPIB address is used, the proper control and data and interrupt signals are sent and received, and reliable data is obtained.
(o) I/O Libraries–Special functions that are not part of general-purpose languages, such as C. C provides I/O calls to files and printers, but these are of no use for instrument control.
The I/O libraries are supplied by vendors of test and measurement software and hardware (Hewlett-Packard, National Instruments, Data Translation). As an absolute minimum, the I/O library for instrument control must include commands for clear, trigger, read, write, and get status byte.
(o) Application–Directs the test for a given DUT. This is the program the test engineer writes. It may be a simple program to control voltmeters and signal generators, or a complex task involving cell controllers and large factory floor tasks.
(o) Language–Used by engineers when writing an application, such as C and Microsoft’s Visual BASIC. Graphical languages increasing in acceptance are HP-VEE from Hewlett-Packard, DT-VEE from Data Translation, and LabView from National Instruments.
(o) Operating System–The computer software, usually supplied with the computer by the manufacturer, that coordinates all functions of the computer. It determines when applications will run, sometimes with instructions from the programmer. It will control the system resources, including disks, memory and displays. Examples are MS-DOS, MS Windows, Windows NT and HP-UX.
Instrument Drivers
An important software module used with graphical languages is an instrument driver. Instrument drivers are written to efficiently communicate with a particular instrument or a class of instruments; for example, scopes. The driver for an instrument is supplied by the instrument’s manufacturer, by the manufacturer of the graphical language, or both.
Just as GPIB interface drivers know how to control the GPIB interface, an instrument driver controls the instrument. The instrument driver translates commands we understand by writing into the application “Measure DC Volts” to a binary representation of that command, and passes it along to the instrument.
The instrument driver relieves the test application programmer from having to write very complicated code. This boosts productivity.
Run Time vs Development Systems
In Figure 1, there is a break between the application and the block that includes the language and I/O library. This break indicates that the language and I/O libraries do not have to be on the controller to run an application.
The distinction here is between a run time system and a development system. Development systems may be used to run an application in a manufacturing environment, but a system that is strictly run time cannot be used to develop applications.
To develop an application, the system must have a language compiler, such as C, and it must have the instrument I/O libraries that contain the instrument control function calls. Once the application is compiled and the I/O calls have been linked to it, the application can run on a system that does not have language compilers and I/O libraries.
Standards
There is a move to standardize all computer environments, including instrument controllers. As the computer environment achieves a greater degree of standardization, applications become more portable.
Before the advent of IEEE 488, if engineers connected instruments together, they did it in a variety of mechanical and electrical ways. There was variety because there was no standard.
IEEE 488, which first standardized the electrical and mechanical interface, was a significant revolution in the test and measurement world. Subsequent revisions of IEEE 488 standardized protocols and common commands; this continued the revolution.
Today, in the world of VXI, mechanical and electrical standards are formulated by the VXI Consortium. Critical parts of the software architecture that need standardization are the I/O library layer and instrument drivers. Fortunately for application programmers and instrument suppliers, this topic is receiving the attention it deserves and will provide yet another revolution for test and measurement.
Portability between computers depends on all elements of Figure 1. With portability, you can reuse the code, providing a significant increase in productivity.
If all elements are the same between instrument controllers, including the operating system and the interface, and they adhere to a standard, the task of porting software will be simple. If there are differences, porting may require a simple recompile (for example, when the operating system is different) or it may require rewriting some of the application (for example, when I/O libraries are different).
Standard Commands for Programmable Instruments
Standard Commands for Programmable Instruments (SCPI), as the name implies, provides standard commands to be used by programmers. Today, most programmable instruments are SCPI compatible.
Standard commands help the engineer who writes the application software–the basic commands for one vendor’s instrument will be the same on a second vendor’s instrument. Outside these basic commands, there is also the capability to write commands that take advantage of special features of a particular instrument.
SCPI commands are usually sent to an instrument as an ASCII string. An example is MEAS:VOLT:DC?, which tells a voltmeter to measure DC volts.
Register-based VXI instruments, which have been designed for speed, require a binary input. These register-based instruments will not understand or parse an ASCII string. SCPI is still useful for these instruments, and programming has been facilitated by SCPI compilers. These compilers preprocess the SCPI command, turning it into binary code understandable by the inst…