Virtual Instrumentation And Automated Test System

Sushanta Kumar Mandal School of Information Technology Indian Institute of Technology Kharagpur 721302 E-mail: sushantakumar@yahoo.com

1. Introduction
1.1 What is Virtual Instrumentation?
Scientist, researcher and engineers mostly rely on data acquisition solutions for system monitoring, control and instrument characterization. A complete data solution typically consists of sensing, signal conditioning, data acquisition and processing, analyzing, visualization, report generation and actuating. To create complete and optimum data acquisition solution within a minimum time, dedicated hardware and software tools are required so that all data acquisition tasks are available concurrently on real-time. All these tasks cannot be done by using stand-alone traditional instruments. The rapid advancement and adoption of computers in the last two decades has given a great improvement in instrumentation test and measurement. Continuous reduction of personal computers and availability of low cost high performance software packages has boosted the systems for Automatic Test Equipment (ATE) based on programmable instrumentation. GPIB (General Purpose Interface Bus) based programmable instrumentation has gained tremendous spread in the last decade for designing ATE system with the concept of virtual instrumentation. Virtual instruments replace part of signal acquisition, processing and display, in traditional instruments, by using personal computer. By graphical programming, the computer monitor can be turned into the front panel of the traditional instruments and, in fact, with enhanced features. Plug-in data acquisition boards transform personal computers into digital device capable to collect signals from sensors and to send commands to actuators. Different manufacturer like NI [1], HP[2] has defined VI in different way. Therefore in general VI is defined as the combination of hardware and software with industry-standard computer technologies to create user-defined instrumentation solutions. In this type of test instrumentation that is basically software reliant and primarily dependent on a computer to control test hardware and equipment, analyze, and present test results. The power of VI application software lies in the fact that it empowers the user to include test equipments as objects in their programs. There are two basic types of virtual instruments. Simple virtual instruments are PC based instruments. These are basically cards or modules that can simply be plugged into a PC and the accompanying software allows the user to perform relevant measurement and data analysis. Alternatively, a variety of programmable test instruments, communication buses like GPIB (IEEE-488)[3], VXI[4], serial and

application test software such as LabVIEW[5], Agilent VEE[6] are available which can be used together to configure a VI.

1.2 Virtual Instruments versus Traditional Instruments

Traditional Instruments Vendor-defined Function-specific, stand-alone with limited connectivity Rely on hardware (integrated circuit) Expensive Fixed functionality Development and maintenance cost is high Virtual Instruments User-defined Application-oriented system with connectivity to networks, peripherals and applications Software reliant Low-cost Flexibility limited by the power of the software Software minimizes development and maintenance costs

1.3 Automatic Test Equipment System

Automatic Test Equipment system is basically a programmable instrumentation system based on GPIB (IEEE 488) buses. The GPIB bus connects all programmable instruments to a PC. Interface between PC and GPIB bus is made with GPIB interface card. The card is configured in a PC and connected to instruments through GPIB buses. Test automation software development tool is used for instrument control, data analysis and representation. Figure 1 shows the configuration of ATE system.

Figure 1 Automatic Test System

Table 1 summarizes the features of some Agilents programmable instruments that conform GPIB: multiple output DC power supply, digital multimeter, 4-channel digital oscilloscope, arbitrary waveform generator and interface card. There are a number of vendors such as NI, Textronix, Fluke etc. provides GPIB compatible instruments. Table 1 Features of instruments that conform Programmable Instrumentation Instruments Interface Agilent 6629A Multiple-output GPIB/RS232 DC Power supply Agilent 34401A DMM GPIB/RS232 Agilent 33250A Function GPIB/RS232 /Arbitrary Waveform Generator Agilent 54615B Digital Storage GPIB Oscilloscope HP 82341A Interface Card GPIB Features 4 Output, 50W, 16V@ 400mA, 50V@1A, 16V@2A 6.5digit, 1000Vdc/ 750Vac, dc/ac 3A, 80 MHz Sine, triangle, square, ramp, noise and more, 12-bit, 200MSa/s, 16,000-point deep arbitrary waveforms 2 Channel, 500 MHz, 1GSa/s, 4 MB SICL and VISA compatible, I/O Port

2. GPIB/IEEE 488 Interface Bus

2.1 What is GPIB?
The Hewlett-Packard Interface Bus (HP-IB) was developed by Hewlett Packard in 1965 to connect and control their programmable instruments to computers. The interface rapidly gained popularity due to its high data transfer rate. It was later accepted as IEEE Standard 488-1975, and has evolved to ANSI/IEEE Standard 488.1-1987. The IEEE committee renamed it GPIB (General Purpose Interface Bus) and more widely used than HPIB. IEEE 488.2-1987 strengthened the original standard by defining precisely how controllers and instruments communicate. In 1990, several instrument manufacturers organized the Standard Commands for Programmable Instruments (SCPI) Consortium and developed the SCPI specification. The specification is based on the SCPI instrument model and provides a much higher degree of commonality for instrument programming commands between different types of test equipment. Standard Commands for Programmable Instruments (SCPI) took the command structures defined in IEEE 488.2 and created a single, comprehensive programming command set that is used with any SCPI instrument. ANSI/IEEE 488.2 was later revised in 1992.

2.2 IEEE 488 Concept: Controller, Talker and Listener

The IEEE-488 concept of Controllers and Devices is shown in Figure 2. Controllers have the ability to send commands, to talk to data onto the bus and to listen to data from devices. Devices can have talk and listen capability. Control can be passed from the active controller to any device with controller capability. Devices are addressable as talkers and listeners and have to have a way to set their address. Each device has a primary address between 0 and 30. Address 31 is the Unlisten or Untalk address. Devices can also have secondary addresses that can be used to address device subfunctions or channels. Although there are 31 primary addresses, IEEE 488 drivers can only drive 14

physical devices. The IEEE-488 Standard defined an instrument with interface and device partitions as shown in Figure 3. Controller
Control, Talk, Listen

Device#1
Talk, Listen

Piggyback Cables

Device #n
Talk, Listen

Figure 2 IEEE-488 Bus Concept Some devices can be set to talk only or to listen only. This lets two devices communicate without the need for a controller in the system. An example is a DVM that outputs readings and a printer that prints the data.

Instrument
GPIB Interface Interface Functions Device Functions

Figure 3 IEEE-488 Instrument

2.3 Interface Bus Features

Maximum 15 numbers of instruments, called devices, can be connected to one computer. 1 MB per second Data Transfer Rate A maximum separation of 4 m between any two devices and an average separation of 2 m over the entire bus A maximum total cable length of 20 m between PC and one device Handshake: so called '3 wire handshake', reception of each data byte is acknowledged.

2.4 Physical and Electrical Characteristics

Devices are usually connected with a shielded 24-conductor cable with both a plug and receptacle connector at each end (piggyback connectors) as shown in Figure 4. Instruments can be connected in a linear (Figure 5), a star (Figure 6), or a combination of the two.

Figure 4 GPIB Connector and Signal assignment

Device#1

Device#2

Device#4

Device#1

Device#3

Device#3

Device#2

Figure 5 Linear Configuration

Figure 6 Star Configuration

2.5 GPIB Signals and Lines

The GPIB interface system consists of 16 signal lines and eight ground-return or shield-drain lines. The 16 signal lines are divided into three groups as follows: (i) 8 data lines, (ii) 3 handshake lines and (iii) 5 interface management lines. Data Lines: DI01 to DI08 are eight bi-directional data lines carry both data and command message. The state of the Attention (ATN) line determines whether the information is data or commands. Command messages are defined by the IEEE-488.2 standard. Most data formats are 7-bit ASCII with or without parity. DI01 is the Least Significant Bit and eighth bit DI08 may be unused or can be used as parity. Handshake Lines: There are three lines asynchronously control the transfer of message bytes between devices. The process is called a 3-wire interlocked handshake. It guarantees that message bytes on the data lines are sent and received without transmission error. NRFD (Not Ready for Data) This line is asserted by a Listener to indicate that it is not yet ready for the next data or control byte. NDAC (Not Data Accepted) This handshake line is asserted by a Listener to indicate it has not yet accepted the data or control byte on the data lines. DAV (Data Valid) - This is asserted by the Talker to indicate that a data or control byte has been placed on the data lines and is stable. The devices can now accept the byte safely. The handshaking process is performed as follows. When a Talker wants to transmit data on the bus, it sets the DAV line high (data not valid), and checks whether the NRFD and NDAC lines are both low, and then it puts the data on the data lines. When all the devices that can receive the data are ready, each releases its NRFD (not ready for data) line. When the last receiver releases NRFD, and it goes high, Talker sets DAV low to indicate that valid data is now on the bus. In response each receiver sets NRFD low again to indicate it is busy and releases NDAC (not data accepted) when it has received the data. When the last receiver has accepted the data, NDAC will go high and the Talker can set DAV high again to transmit the next byte of data. Note that if after setting the DAV line high, the Controller or Talker senses that both NRFD and NDAC are high, an error will occur. Also if any device fails to perform its part of the handshake and releases either NDAC or NRFD, data cannot be transmitted over the bus. Eventually a timeout error will be generated. The speed of the data transfer is controlled by the response of the slowest device on the bus, for this reason it is difficult to estimate data transfer rates on the IEEE-488 bus, as they are always device dependent. Interface Management Lines: Five lines (ATN, EOI, IFC, REN, SRQ) manage the flow of information across the interface ATN (attention) is set true by the controller while it is sending interface messages or device addresses on the bus. ATN is false when the bus is transmitting data. EOI (end or identify) can be asserted to mark the last character of a message or asserted with the ATN signal to conduct a parallel poll. IFC (interface clear) is sent by the system controller to unaddress all devices and places the interface function in a known quiescent state. REN (remote enable) is sent by the system controller and used with other interface messages or device addresses to select either local or remote control of each device. REN only enables a device

to go into remote mode when addressed to listen. When in remote mode, a device should ignore its local front panel controls. SRQ (service request) is like an interrupt and may be sent by any device on the bus that wants service.

2.6 IEEE-488.2
IEEE-488.2 defines a set of standard format for programming GPIB. IEEE 488.2 instruments are easier to program because they respond to common commands and queries in a well defined manner using standard message exchange protocols and data formats. The IEEE 488.2 message exchange protocol is the foundation for the SCPI standard that makes test system programming even easier. All devices must be able to send and receive data, request service, and respond to a device clear message. IEEE 488.2 defines precisely the format of commands sent to instruments and the format and coding of responses sent by instruments. All instruments must perform certain operations to communicate on the bus and report status. Thus the IEEE-488.2 Standard establishes standard instrument message formats, a set of common commands, a standard Status Reporting Structure and controller protocols that would unify the control of instruments made by hundreds of manufacturers. The standard instrument message format terminates a message with a linefeed and or by asserting EOI on the last character. Multiple commands in the same message are separated by semicolons. The common command set defined a subset of ten commands that each IEEE-488.2 compatible instrument must respond to plus additional optional commands for instruments with expanded capabilities. IEEE 488.2 Common Commands and their functions are listed in Table 2 Table 2 IEEE 488.2 Common Commands Functions Identification Query (Company, model and serial number) Reset Self-test query Clear status Operation complete Operation complete query Service request enable Service request enable query (0-255) Event status register query Event status enable Event status enable query Read status byte query (0-255) Wait to complete

Mnemonic *IDN? *RST *TST? *CLS *OPC *OPC? *SRE *SRE? *ESR? *ESE *ESE? *STB? *WAI?

Probably the most familiar Common Command is the *IDN? query. This is a good first command to use with an instrument as its response shows the details identification of the instrument model, serial number and company name and it ensures that you have communication with the instrument.

2.7 Standard Commands for Programmable Instruments (SCPI)

The Standard Commands for Programmable Instrumentation (SCPI) defines a standard set of commands to control programmable test and measurement devices in instrumentation systems. It decreases development time and increases the readability of test programs and the ability to interchange instruments. SCPI specifies standard rules for abbreviating command keywords and uses the IEEE 488.2 message exchange protocol rules to format commands and parameters. One may use command keywords in their long form (MEASure) or their short form shown in capital letters (MEAS). SCPI Command Structures and Examples SCPI organizes commands into various sets that match "subsystems" of the target instrument. The commands for each subsystem are defined in a hierarchical structure similar to the hierarchical file system found on most computers. In SCPI, this command structure is called a "command tree". A simplified example, for the SENSe command as implemented on a DMM, is shown below:

SENSe

CURRent

VOLTage

RANGe

RESolution

RANGe

RESolution

AUTO

UPPer

AUTO

UPPer

AUTO

AUTO

Figure 7 SCPI Command Structure The command tree is described with nomenclature similar to that used for file systems. The command at the top of the tree is the "root" command, and subsystem commands are linked into "paths" through the tree. For example, one path through the tree is defined by the command sequence: :SENSe:VOLTage:RANGe:AUTO -- which sets the Digital Multimeter (DMM) to read voltages using autoranging. Note how colons (":") are used as path separators. Another path is: :SENSe:CURRent:RANGe:UPPer -- which sets the DMM to read currents and uses the upper current range of the DMM. Note that the full path of a command does not need to be sent to the DMM each time. The parser navigates through the tree as directed by subsystem command strings according to the following rules: After power-on or the *RST common command is sent, the current path is set to the root.



A message terminator, usually a <newline> (line-feed) character, also sets the current path to the root. A colon (":") is, as shown above, a path separator. Each time the parser finds a colon in the subsystem command string it moves down through the command tree one level. If the colon is the first character in the string, however, it specifies the root. A semicolon (";") separates two commands in the same subsystem command string without changing the current path. Whitespace characters, such as <tab> and <space>, are generally ignored. However, whitespace inside a subsytem command keyword is forbidden. For example, MEAS ure is not a legal keyword. Whitespace is also required to separate a parameter from a command. For example, :SOURce:VOLTage6.2 is incorrect, you must use :SOURce:VOLTage 6.2. Commas (",") are used to separate multiple parameters for a single subsystem command. Common commands, such as *RST, are not subsystem commands and are not interpreted as part of a path.

For example: :SENSe:VOLTage:RANGe:AUTO; RESolution:AUTO is the same as executing :SENSe:VOLTage:RANGe:AUTO :SENSe:VOLTage:RESolution:AUTO It should be noted that the spaces around the ";" are strictly window-dressing. The parser ignores them, they're just there to make the string easier to read. Similarly: :SENSe:VOLTage:RANGe:AUTO :SENSe:CURRent:RANGe:UPPer -- is the same as executing both commands separately, since the ":" immediately following the separating ";" resets the current path to root. A feature of compound commands is that the following command starts at the last node of the previous command. This often makes the command line shorter than it would be otherwise. But what if you want a to use a command on a different branch? If this is the case, you must put a colon (:) before the command that follows the semi-colon (;). This returns the command tree to the root. For example this is a valid command line: MEASURE:VOLTAGE:DC?;:MEASURE:CURRENT:DC?

2.8 Device Addresses:

GPIB devices can be assigned any primary address between 0 and 30. Each GPIB device must be given different address to avoid confliction. Addresses 0 and 21 should not be used for device address as these may be used by the GPIB controllers. GPIB controllers have their own GPIB address. National Instruments controllers typically use GPIB address 0. HP/Agilent controllers typically use GPIB address 21. GPIB Devices typically use a dip switch with five rockers to set the GPIB address. The rocker bit weights are 16, 8, 4, 2, and 1. In some GPIB devices address can be set from front panel.

3. Automated Test System using Virtual Instrumentation

3.1 Introduction
By creating a virtual instrumentation-based system we can develop a compact, cost-effective and easy-to-use test system for test and evaluation of any system. By using VI-based system we can control all the programmable instruments from the desktop of a PC. For the controlling of instruments and test evaluation we can use any industry standard automation software like LabVIEW, Agilent VEE etc.

3.2 System Configuration

3.2.1 Hardware Implementation Most GPIB test configurations have one computer with a single GPIB Interface Card. There may be more than one GPIB interface card on each GPIB bus but only one at a time can communicate to the GPIB instruments. A PC may also control more than one GPIB bus using more than one interface controller card. Programmable GPIB instruments may be connected in linear, star or both configurations. The system is generally configured using a PC with OS, GPIB Interface Board by (NI, Agilent etc), GPIB Bus and programmable instruments. The block schematic of the test system is shown in Figure 8 GPIB Bus PC with Operating System

GPIB Instruments

GPIB Instruments Automation Software GPIB Interface Card

GPIB Instruments

System Under Test / Circuit Under Test

PRINTER

Figure 8 Block Schematic of a Test System

Software Implementation: The software program is developed using graphical programming environment such as LabVIEW, VEE etc. Programs are generally made in modular structures and are expandable.

3.3 Selecting GPIB Instruments

Designing a GPIB automatic test setup is the same as designing a manually operated test setup. The selected GPIB test instruments must have the performance capabilities to meet the test requirements. Since GPIB compatible instruments vary widely in instrument type, this may include a broad range of technical performance criteria and will vary depending on the specific test or tests to be conducted. Test equipment performance, in this sense, also includes the GPIB performance of the test equipment. It is true that the GPIB bus will, in some configurations, support up to 1-Mbps data transfer. The new high-speed GPIB (HS488) will support even faster data rates up to several Mbps. However, the actual data rate over the bus is usually limited by the instruments and the measurements made by them. A fast GPIB bus is no guarantee that the instrument can make a measurement and put the data onto the bus at that speed. GPIB test instruments require some finite amount of processing time to turn digital information into an electrical stimulus and turn an electrical measurement back into digital data. This processing time is a function of the speed and capabilities of the instrument. In some cases, a reduction in instrument processing times and in the amount of data transferred from the instrument can be accomplished by having the test software command the GPIB test instrument (if the instrument has the capability) to transfer only the raw acquired data over the bus. The GPIB controller's computer processor (usually a much higher-performance processor) can then perform calculations on the data and thereby reduce the load on the bus. Commercially available test software, compatible with GPIB instruments, usually includes a variety of mathematical capabilities or additional software suites that allow the designer to customize the data processing once the computer has acquired data, using their own algorithms or external executables. The discussion of the instrument's data acquisition time, processing time, and data transfer rate raises another concern on the GPIB test configuration. Although the GPIB command structure allows for sequencing bus activity through device service requests and wait commands, the nature of the GPIB bus restricts tasks over the bus to be performed one at a time. Therefore, the longer the GPIB bus is busy from instrument or device lag, the less time is available to issue new commands or acquire additional data. This can impose some unnecessary restrictions in design, particularly when performance criteria requires precision timing or transferring large amounts of data from instruments. Where precision timing is required, it is best to use a GPIB-compatible device as an external trigger and, thus, externally trigger all test equipment in the configuration that requires a precise timing signal. Where large data transfer or instrument lag is a problem, more than one GPIB controller card can be used to control another GPIB bus. A multiboard system allows the designer to operate another GPIB instrument or an entire test configuration on a separate bus, simultaneously, and thereby increase throughput. The ideal GPIB test configuration would be physically connected so that all GPIB devices are powered on, all GPIB cable lengths are as short as possible, and all GPIB devices are spaced equally on the order of one device every meter of cable length.

3.4 Choosing a GPIB Controller Card

Once the GPIB test instruments have been selected, the designer can focus on choosing the proper GPIB controller card and GPIB test software that will support testing. The controller card must be compatible with the computer's hardware platform and OS. Figure 9 shows a block diagram of compatibility issues between the GPIB controller card, computer hardware platform, computer OS, and GPIB test software. The GPIB controller card must be compatible with the computer's physical hardware and its OS. GPIB controller cards are available that will connect to a variety of computer hardware interfaces, such as PCI [7], PCMCIA, EISA, serial and parallel ports, Ethernet, VXI, and several other types of hardware interfaces. The majority of GPIB controller cards are compatible with Windows OSes. Many cards are also compatible with several flavors of Unix, like HP-UX and Solaris, as well as a few other OSes. Each of these GPIB controller cards requires a set of device drivers from the card manufacturer that allow software running on the computer to issue GPIB commands, acquire data from the GPIB test setup, and control instruments. These device drivers must also be compatible with the computer OS and hardware platform. Finally, the device drivers for a specific GPIB controller card must also be compatible with the GPIB test software selected. The compatibility between device drivers and test software is an important consideration. NI offers a large selection of GPIB controller cards, based on its (industry standard) NI-488.2 device drivers. These drivers are supported for a wide variety of computer platforms, hardware interfaces, and OSes.

Instrument drivers

GPIB Test Software

S/W to controller device driver

GPIB Instrument

S/W - OS compatibility S/W H/W Compatibility

GPIB cable length/ device spacing

OS - controller device driver

Operating System

GPIB Interface Controller Card Hardware Platform

H/W - controller compatibility

Figure 9 H/W, S/W and GPIB compatibility

The selection of the controller card should allow us to not only configure our current GPIB test configuration, but anticipate future requirements or applications. Will the GPIB setup be used remotely or in a multiboard system? Designing a remotely-operated GPIB test setup has special considerations from a GPIB setup in which all of the components are local. Mulitboard systems may also have unique considerations. Multiboard systems, for example, are effective at controlling more than one GPIB test configuration, provided the computer and the hardware interface to the GPIB controller card can support high-speed transfer. Because of their high bus speeds, GPIB controller cards that interface to the computer through PCI or PCMCIA will do a good job of supporting the load of a multiboard system. Other GPIB interfaces, such as a serial or parallel port, operate at a much slower throughput and can bottleneck a test configuration. A good rule of thumb is to select a controller card that meets all the compatibility issues in Figure 9, including compatibility with the GPIB test software, and uses the fastest computer hardware interface available.

3.5 Choosing GPIB test software

The GPIB test software must be compatible with the GPIB instruments, the GPIB interface (controller) card, the Operating System, and the hardware platform. The GPIB test automation software should have instrument drivers for each of the instruments that will be used for configuration of automated test system. Sophisticated automatic test equipment (ATE) can have many instrument-specific commands for configuration, operation mode, status, control, and data acquisition. For advanced communication test setups, this can literally add up to a few hundred instrument-specific commands. The test software packages comes with large instrument libraries and have capabilities for advanced analysis, signal processing, and data acquisition (non-GPIB) to support various types of communication testing. Two most noteworthy GPIB test software packages are Agilent's visual engineering environment (Agilent VEE, earlier HPVEE) and National Instrument's LabVIEW. Both software packages contain large instrument libraries, are usable with several interface controller cards, and are supportable over a broad range of Operating Systems and hardware platforms. Both software packages can run simultaneously on a multiboard system. By this each package can control a separate instrument in the same test configuration via a separate GPIB controller card and GPIB bus. For some designs, this offers significant advantages in rapid design and implementation of GPIB test configurations, as well as higher performance. By combining the instrument libraries from both software packages, this will effectively increase the number of offthe-shelf instrument drivers. The additional bus or buses provide a significant performance advantage, since data transfer from the instruments to the computer can be split up over more than one bus. This type of multiboard system imposes a load on the computer OS and hardware to operate the controller cards and multitask between applications. This is where we want the load not bottlenecked at the GPIB controller card or waiting to get data or commands on the GPIB bus. In these types of configurations, communication between software packages (processes) can be accomplished through dynamic data exchange (DDE) in a Windows environment with HPVEE as the DDE client and LabVIEW as the DDE server. For Unix systems, a similar form of interprocess communication may be used to perform this task. Once the software package is selected, the task is now concentrated on writing software to perform the desired test(s), and recording, analyzing, and displaying test data. There are various

means available to communicate with other applications on a system (Discussed in Case Study using VEE)

4. Case Study: Virtual Instrumentation Based Automated Test System Using Agilents VEE
4.1 Introduction to Agilent VEE
Agilent Visual Engineering Environment (Agilent VEE) [8][9] is a graphical programming language specially designed for controlling programmable instruments such as power supplies, function generators, digital multimeters, oscilloscopes and others. When the instruments are connected to a circuit, the user can send commands and data to the instruments to activate the circuit from a desktop computer, receive the data measured by the instruments, perform mathematical analyses of the data, and display the results graphically or store them in files. In a conventional textual language, rules of syntax and operators control program execution. In Agilent VEE, the program is designed by connecting objects in the workspace together with "wires", lines that connect these objects in a meaningful fashion. These wires dictate when and where data will flow through the program.

Sequence Input Pin

Data Input Pin Data Output Pin

Sequence Output Pin

Figure 10 VEE Object with different pins Each object acts like a function call, which manipulates certain arguments. It receives data via data input pins on the left side. The object performs some function to this data and then returns any results through data output pins on the right hand side. Each pin is for a specific input/output to the function, though that data may be an array or record of information. Data propagation through a network of objects, analogous to the way a variable passes through functions in C, is determined by the status of each object's pins. Only an object with data supplied to all its Data In pins will execute. Thus the objects with no data input pins execute first in the workspace. Their Data Out pins provide inputs to other objects, then those objects may execute, etc. Multiple objects may have the ability to execute at the same time. The determination of which executes first is indeterminate. However, the programmer may control this propagation by using

sequence pins. An object with its Sequence In pin wired to something else may not execute until data (of any type) is passed to that pin. Then the object may execute, and it is not until this execution is complete that the Sequence Out pin sends its data out, if it is wired up. Consequently, the Sequence pins are acting just like Data In/Out pins, except the data isn't being used for anything. Agilent VEE has a menu bar like all other Windows based application. Just below the menubar is a tool bar with the Agilent logo on it. Buttons located on the toolbar, used to execute your programs (e.g. Run, Stop), will be designated in a similar manner. The left mouse button is used to make choices and perform actions. The right mouse button will open a pop up menu for anything on the screen. The menu displayed when you click the right button over an object, its associated Object Menu, is one you will be seeing frequently.

4.2 How to Control Instruments

There are several ways to communicate with instruments using Agilent VEE [10]. These are obtained by choosing I/O Instrument Manager from the menu bar and the appropriate options. A dialog box with a list of the connected instruments and their bus addresses will appear. As for example the instruments connected to the PC are: Agilent 6629A Four-output dc power supply [11]: address 705 Agilent 34401A multimeter [12]: address 726 Agilent 33250A function generator [13]: address 706 Agilent 54615B oscilloscope [14]: address 707 These instruments can be controlled by several ways. Here two easy ways, Panel Driver and Direct I/O are discussed. Panel Driver: Panel driver gives a very simple user interface (or soft front panel) to control an instrument from computer screen. When parameters in the VEE panel driver are changed, the corresponding state of the instrument is changed. Panel drivers are provided by Agilent Technologies with VEE and cover over 450 instruments from different vendors. Figure 9 shows the soft front panel of a DMM.

Figure 11 Soft Front panel of DMM The soft front-panel of an instrument driver makes possible to control online the instrument with the mouse and to read the state and the measured value on the screen. The instrument manager shows all available drivers (if necessary further drivers can be loaded). Using the edit function of the instrument manager, many special parameters of the driver (e.g. name, address, status) can be changed. It is possible to add terminals to the soft front-panel for input or output of data, parameters, instrument functions and control signals.

Select Function Generator (@706) in the dialog box that appears, and click the Panel Driver button. Click anywhere on the working area of the screen to place the instrument. The object can be moved by clicking anywhere on it and dragging the mouse. The actual function generator is immediately in communication with instrument driver through the bus cable. Although several "panels" are available, you will probably need only the Main Panel, which is the default. Make the following changes in the settings, while observing the digital display on the bench instrument: Select the Function window and set the function to one of the choices that appear; Select the Frequency window and set an arbitrary value; you may use units such as m, k, and M for milli, kilo, and mega respectively; Select the Amplitude window and set an arbitrary value.

Try to familiarize with the panel drivers for the digital multimeter and the oscilloscope as well. Figure 10 shows the opened drivers for all three instruments. Figure 11 shows remote control of instruments using panel driver.

Figure12 Instrument Panels

Remote Control of Instruments using Soft Front-panels (Panel Driver)

Figure 13 Instrument remote control using soft front-panels Direct I/O: Direct I/O object allows us to communicate with any instrument from any vendor over standard interfaces. The application of direct I/O is useful if no instrument driver is available or if only few functions of an instrument are used. The Direct I/O object works by transmitting commands to the instrument and receiving data back from the instrument. Use of Direct I/O generally gives faster execution speeds. Figure 14 shows an example using Direct I/O to control a function generator.

Figure 14 Direct I/O with SCPI Commands Remote Control of Instruments Using Direct I/O and SCPI Commands A command or query is called a program message unit. Such a program message unit consists of a header, or a header separated by a space from one or more parameters (see Figure 14). The header consists of one or more key words.

, < header > sp < parameter >

Figure 15 Syntax of a program message unit One or more program message units (commands) may be sent within a single program message, separated by a semicolon (;). A program message must be finished by a program message terminator; Agilent VEE sends this terminator automatically. SCPI commands have a tree structure. The syntax of a command begins from the root level downwards to the leaf-nodes at the bottom of the command tree. All key words begin with a double point (:). Leaf-nodes are the last key words in the command header. The following notes apply to commands: Key words written into angular brackets can be left out. Basically all commands also have a query form. The response to the query is often the parameter of the command. Commands that do not cause a setting or state to be changed (so-called event commands), do not have a query form. There are also queries that do not have a command form. A command may or may not have parameters. Following data can be used as a parameter: Numeric values, Several key words as a special form of numeric data, i.e. MINimum, MAXimum, DEFault, Other data types, e.g. string, character, Boolean. Long and short form Key words (mnemonics) in SCPI program messages may be sent either in long or short form. The long and short forms essentially obey the following rules: The long form is the full word of the mnemonic but has a maximum of 12 characters (example: INITiate). The short form consists of the first four characters of the long form (example: INIT). Exception: When the fourth character is a vowel and the four characters do not form the long form, then the short form consists of the first three characters only (e.g. long form: SWEEP, short form: SWE). Sometimes a mnemonic is created from a concatenated word or phrase, i.e. PTPeak for peak to peak or AC for alternating current. Either the long form or the short form may be used in a command message. In a response message only the short form will be used. Measurement instructions SCPI offers different possibilities to obtain measurement results. These groups of measurement instruction sets have different levels of complexity and flexibility. :MEASure? The :MEASure? query configures the instrument, starts the data acquisition, and returns the result. Parameters may be added to give further details about the signal to be measured (Figure 16).

Figure 16 Application of the :MEASure? instruction with parameter (1) In this case a numeric value is used as a parameter: the parameter 10 is the expected signal range. It is possible to use a data input of the direct I/O object to transfer the parameter as a variable into the direct I/O transaction (Figure 17, the parameter is the variable A).

Figure 17 Application of the :MEASure? instruction with parameter (2)

Program Examples

Figure18 Instrument remote control using Direct I/O

4.3 Automated Test System of Analog Circuit

4.3.1 Implementation of Analog Design for Testability on VEE Environment A work has been done to implement Analog Design for Testability (ADFT) by pseudo random analog signal to circuit under test analogous to the Signature Analysis in Digital Domain. The circuit chosen for testing is a simple second order filter realized using an opamp, resistances and capacitances. The circuit schematic is shown in Figure 18. Catastrophic faults were introduced in the circuit by sorting a high resistance with a small resistance for short circuit faults and putting a high resistance in series for open circuit faults. Fault simulation is done in SPICE by changing the circuit script file, to incorporate the catastrophic faults described above. A random signal applied to the input of both the normal and the faulty circuit. From simulation it has is found out that the faulty circuit response to the random sequence is different from that of the fault free circuit. Thus this method will serve as a tool for distinguishing fault free circuits from faulty circuits. The challenge is to verify the simulation results experimentally. The input random signal is to be a very precise signal with accuracy of 10-4 volts. Similarly the response of the circuit has to be recorded up to four places of decimal. The difference between the output response of the fault free circuit and the faulty circuit is very small to be easily marred by spurious noise. 4.3.2 Inputting a pseudo random sequence of high accuracy The input sequence is a periodic repetition of 1000 random samples placed at a distance of 10 microseconds. This signal has to be generated continuously from the arbitrary waveform generator. An Agilent 33250A 80 MHz Function/Arbitrary waveform generators is first loaded with the data pattern from a file by GPIB interface. The pattern generator is automatically programmed to output the data at a desired frequency. The frequency is periodically repeated. Since pattern generator has very high-resolution data storage the quantization error is much smaller than 10-4 V. 4.3.4 Recording the response of the circuit An Agilent 54615B oscilloscope (with GPIB programmability) records the response of the circuit. As the oscilloscope samples at the rate 500 Mega Samples/s, it is ensured that all signal points get recorded. Also high resolution of the oscilloscope ensured quantization error insignificant in comparison to accuracy required. The VEE environment records the oscilloscope screen data and stores them in a file in Microsoft XL format. VEE program for automatic testing is shown in Figure 18. Without Automated Test Setup it is very difficult to carry out this test manually. Automation helps to send thousands of samples generated by a SPICE Pseudo Random Pattern Generator to Waveform generators memory. Similarly the data from Oscilloscope is directly measured and stored in an excel format. So storing a huge amount of data no longer remains a bottleneck. Figure 19 represents the experimental results analyzed in VEE.

4.3.5 The Test Setup Figure 19 shows the setup and circuit schematic for automatic testing of an analog circuit. Figure 20 shows the corresponding VEE programs for automated test structures. Result that is analyzed in the X-Y trace is given in Figure 21.

Figure 19 Setup & Circuit Schematic

Figure 20 The VEE Program

Figure 21 Experimental Result

Conclusions
This article introduces a programmable instrumentation system development connecting programmable instruments to a PC using GPIB interface bus. It also discusses how to design, configure and develop distributed ATE system by implementing communication network. The detailed discussion on GPIB interface bus and VEE test automation software is presented. Real-time program examples are given to demonstrate how the instruments are controlled.

References
[1] National Instruments: Instrumentation Catalogue: Measurement and Automation [2] Hewlett-Packard Company, www.hp.com [3] Caristy, J.: IEEE 488 General Purpose Instrumentation Bus Manual. Academic Press, 1989. [4] Hewlett Packard: Test System and VXI Products Catalog. Hewlett-Packard Company, 1997. [5] National Instruments: LabVIEW Manual. www.ni.com [6] Agilents VEE Pro 6 manual [7] National Instruments: PXI Specification Rev.1.0, National Instruments, 1997. [8] Agilent Technologies: Getting Started with VEE [9] Helsel R.: Visual programming with HP VEE. Hewlett-Packard Professional Books, third edition 1998. [10] Agilent Technologies: Controlling Instruments with HP VEE. [11] Agilent Technologies: 6629A Four-output dc power supply [12] Agilent Technologies: 33401A Digital Mutimeter [12] Agilent Technologies: 33250A Arbitrary Function Generator [13] Agilent Technologies: 54615b Oscilloscope