virtualinstrumentation_article

8/14/2019 VirtualInstrumentation_Article

1/22

Virtual Instrumentation

And Automated Test System

Sushanta Kumar MandalSchool of Information Technology

Indian Institute of Technology

Kharagpur 721302

E-mail: [email protected]

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 ofsensing, 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 tasksare 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 forAutomatic Test Equipment (ATE) based on programmable instrumentation. GPIB (General Purpose

Interface Bus) based programmable instrumentation has gained tremendous spread in the lastdecade 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 beturned 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 signalsfrom 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 instrumentationthat 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 twobasic 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 ofprogrammable test instruments, communication buses like GPIB (IEEE-488)[3], VXI[4], serial and


2/22

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 Virtual InstrumentsVendor-defined User-defined

Function-specific, stand-alone with limited

connectivity

Application-oriented system with connectivity to

networks, peripherals and applications

Rely on hardware (integrated circuit) Software reliant

Expensive Low-cost

Fixed functionality Flexibility limited by the power of the software

Development and maintenance cost is high 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 andconnected to instruments through GPIB buses. Test automation software development tool is used

for instrument control, data analysis and representation. Figure 1shows the configuration of ATE

system.

Figure 1 Automatic Test System


3/22

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 Features

Agilent 6629A Multiple-output

DC Power supply

GPIB/RS232 4 Output, 50W, 16V@ 400mA, 50V@1A,

16V@2A

Agilent 34401A DMM GPIB/RS232 6.5digit,1000Vdc/ 750Vac, dc/ac 3A,

Agilent 33250A Function

/Arbitrary Waveform Generator

GPIB/RS232 80 MHz Sine, triangle, square, ramp, noise

and more, 12-bit, 200MSa/s, 16,000-pointdeep arbitrary waveforms

Agilent 54615B Digital Storage

Oscilloscope

GPIB 2 Channel, 500 MHz, 1GSa/s, 4 MB

HP 82341A Interface Card GPIB 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, andhas 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 theoriginal 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 programmingcommands 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. Devicescan 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 orUntalk address. Devices can also have secondary addresses that can be used to address device sub-

functions or channels. Although there are 31 primary addresses, IEEE 488 drivers can only drive 14


4/22

physical devices. The IEEE-488 Standard defined an instrument with interface and device partitions

as shown in Figure 3.

Control,

Talk, ListenTalk,

Listen

Talk,

Listen

Controller

Piggyback

Cables

Device#1

Device #n

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 printerthat prints the data.

Interface

Functions

Device

Functions

Instrument

GPIB

Interface

Figure 3 IEEE-488 Instrument

2.3 Interface Bus Features

Maximum 15 numbers of instruments, called devices, can be connected to onecomputer. 1MBper second Data Transfer Rate A maximum separation of 4 mbetween any two devices and an average separation

of 2 mover the entire bus A maximum total cable length of 20mbetween PC and one device

Handshake: so called '3 wire handshake', reception of each data byte is

acknowledged.


5/22

2.4 Physical and Electrical Characteristics

Devices are usually connected with a shielded 24-conductor cable with both a plug and receptacleconnector 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#3

Device#1

Device#2Device#3

Device#4

Figure 5 Linear Configuration Figure 6 Star Configuration


6/22

2.5 GPIB Signals and LinesThe 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 Bitand eighth bit DI08 may be unused or canbe 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 hasbeen 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 areboth 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 (notdata 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 andNDAC 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 deviceaddresses 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 theATN signal to conduct a parallel poll.

IFC (interface clear) is sent by the system controller to unaddress all devices and places theinterface 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


7/22


8/22

2.7 Standard Commands for Programmable Instruments (SCPI)

The Standard Commands for Programmable Instrumentation (SCPI) defines a standard set ofcommands 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. Onemay 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

UPPer AUTO AUTO

RESolutionRANGe

UPPer

RANGe RESolution

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 commandsequence:

: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 notneed 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.


9/22

A message terminator, usually a (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 withoutchanging the current path.

Whitespace characters, such as and , are generally ignored. However,

whitespace inside a subsytem command keyword is forbidden. For example, MEAS ure isnot 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 deviceaddress 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 theGPIB address. The rocker bit weights are 16, 8, 4, 2, and 1. In some GPIB devices address can beset from front panel.


10/22

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 cancontrol 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 maybe 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 bothconfigurations. 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

PC withOperating System

Automation Software

GPIB Interface Card

GPIBInstruments

GPIBInstruments

GPIB

Instruments

System Under Test /

Circuit Under Test

GPIB Bus

PRINTER

Figure 8 Block Schematic of a Test System


11/22

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 testrequirements. 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 teststo 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 datatransfer. 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 finiteamount 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 structureallows 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 commandsor 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 anexternal 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 tooperate 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.


12/22

3.4 Choosing a GPIB Controller Card

Once the GPIB test instruments have been selected, the designer can focus on choosing theproper 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 9shows 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'sphysical 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 arecompatible 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 issueGPIB 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.2device drivers. These drivers are supported for a wide variety of computer platforms, hardware

interfaces, and OSes.

GPIB Test Software GPIB Instrument

Operating System

Hardware Platform

Instrument

drivers

GPIB Interface

Controller Card

S/W to controller

device driver

OS - controller

device driver

H/W - controller

compatibility

S/W

H/WC

ompatibility

S/W - OScompatibility GPIB cable length/

device spacing

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


13/22

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 usedremotely 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 theGPIB 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 interfaceavailable.

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 dataacquisition. 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) tosupport 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 aresupportable over a broad range of Operating Systems and hardware platforms.

Both software packages can run simultaneously on a multiboard system. By this each packagecan 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 off-the-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 tooperate 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 beaccomplished 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 toperform the desired test(s), and recording, analyzing, and displaying test data. There are various


14/22

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 areconnected 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 andwhere data will flow through the program.

Sequence Input Pin

Data Output Pin

Data Input 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 viadata 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 anetwork 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 Inpins willexecute. Thus the objects with no data input pins execute first in the workspace. Their Data Outpins 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


15/22

sequence pins. An object with its Sequence Inpin wired to something else may not execute untildata (of any type) is passed to that pin. Then the object may execute, and it is not until thisexecution is complete that the Sequence Outpin 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 ObjectMenu, 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 726Agilent 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 DirectI/O are discussed.

Panel Driver:Panel drivergives 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 AgilentTechnologies 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 ofthe 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.


16/22

SelectFunctionGenerator(@706)in the dialog box that appears, and click thePanel Driverbutton.

Click anywhere on the working area of the screen to place the instrument. The object canbemovedby 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 thedefault. Make the following changes in the settings, while observing the digital display on the bench

instrument:

Select theFunctionwindow and set the function to one of the choices that appear;

Select theFrequencywindow and set an arbitrary value; you may use units such as m, k, and Mfor milli, kilo, and mega respectively;

Select theAmplitudewindow 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


17/22

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 ifonly few functions of an instrument are used. The Direct I/O object works by transmittingcommands 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 aheader, or a header separated by a space from one or more parameters (see Figure 14). The header

consists of one or more key words.


18/22

sp

,

< parameter >< header >

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 messageterminator; 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 tocommands:

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. Thelong 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).


19/22

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


20/22

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 randomanalog 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 andcapacitances. The circuit schematic is shown in Figure 18. Catastrophic faults were introduced inthe 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 faultycircuit 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 bea 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 datapattern 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 circuitAn 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 insignificantin 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. Automationhelps 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.


21/22

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 inthe X-Y trace is given in Figure 21.

Figure 19 Setup & Circuit Schematic

Figure 20 The VEE Program


22/22

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-timeprogram 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, thirdedition 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: 33250AArbitrary Function Generator

[13] Agilent Technologies: 54615b Oscilloscope
http://www.hp.com/http://www.ni.com/http://www.ni.com/http://www.hp.com/

virtualinstrumentation_article

Documents