Get off the shelf

Test always takes too long and costs too much. But you can do something about both problems—if you can redeploy test equipment and reuse code.

Seven companies are taking these and other concepts on the road as part of the 2004 Automated Test Summit, which is visiting a dozen North American cities this spring. (See "Summit details," below.) In this first of three articles, I'll summarize what Summit attendees are likely to learn about how to reuse equipment and code and protect future investments from changing technologies. I'll also summarize the options you have for instrumentation platforms. The next two installments will appear in the May and June issues.

Fifteen years ago, you had two options for connecting instruments to computers: RS-232 and IEEE 488. Today, you have numerous options for instrument platforms and communications buses for use in engineering labs, production floors, and field sites. Buses such as MXI, Ethernet, USB, and IEEE 1394 let you connect computers to discrete instruments or to modular instruments such as VXI and PXI.

You can combine these instrument and bus technologies into hybrid systems that can maximize flexibility and performance. Because discrete and modular instruments can work together, you can often reconfigure a test system from instruments you already own when new test challenges arise.

PXI modular systems combine an embedded PC module with assorted instrument cards. Courtesy of National Instruments.

You can take advantage of today's technologies when you redeploy test equipment for new products or add functions to a test system. For example, you can add boundary scan to an existing functional tester, thus adding to its usefulness (see "Into the structure ").

Five to 10 years ago, a typical test stand consisted of one to several IEEE 488 instruments and perhaps a VXI chassis loaded with switch modules. In most cases, those systems used a stand-alone PC that communicated to each instrument and to the VXI chassis over IEEE 488. Some systems used VXI slot-0 controllers with embedded PCs. Today, many systems use an MXI copper or fiber link between a host PC and a VXI chassis. Some use Ethernet, while fewer use IEEE 1394 in place of MXI.

With the advent of PXI in 1997, systems now use combinations of discrete instruments, VXI instruments, and PXI instruments. You can use a VXI or PXI embedded controller to control instruments in a chassis and to communicate with discrete instruments. Alternatively, you can use a desktop or rack-mounted PC for instrument control. For controlling a VXI chassis with a PC, you can use MXI-2, MXI-3, IEEE 1394, IEEE 488, or Ethernet. For the PXI chassis, you can choose from MXI-3 and Ethernet only.

By combining discrete instruments, VXI modules, and PXI modules, you can take advantage of each technology to get the performance, flexibility, and cost you need. For example, a test system may use IEEE 488 instruments such as an RF spectrum analyzer, a high-speed VXI digitizer, and a switching system for capturing continuous RF, transient, and audio signals, and it may also use a PXI DMM for monitoring a power supply. Table 1 highlights the differences among platforms (including standard PCs).

When you redeploy test instruments, you must decide if the PC, VXI chassis, or PXI chassis will become the system controller. Suppose you need to add several analog-input channels for monitoring voltage or current and you need some digital I/O for controls or alarms to a VXI system. You can extend the system with additional VXI instruments, or you can add a PXI chassis and instrument cards. If the VXI chassis uses an embedded controller, you can use its Ethernet port to communicate with a PXI chassis.

Test racks can employ PXI, VXI, and discrete instruments. Courtesy of National Instruments.

Some discrete instruments—most notably oscilloscopes such as those from Tektronix—have PCs built in. Thus, you can install your favorite programming language and write code that runs inside the instrument. The scope can use software drivers to control other instruments through Ethernet and USB ports, so you can redeploy instruments into systems controlled from your scope.

"Tektronix scopes have LabView 7 instrument drivers," notes Chris Loberg, business development manager at Tektronix. "The drivers, with LabView 7 programming interfaces, simplify connectivity and produce reliable performance. When LabView runs on a Windows-based scope, the acquired data moves across the scope's PCI bus into the built-in PC, which can deliver data to a test executive, spreadsheet, database, or data-analysis program."

Software has come far in aiding instrument redeployment. The first instruments used proprietary programming commands, making it impossible to replace equipment in long-life test systems unless you were willing to rewrite code. Standard Commands for Programmable Instruments (SCPI) started the transition toward instrument replacement and redeployment by establishing a common set of instrument commands.

Instrument drivers carried SCPI to a higher level. They simplified programming, letting you more easily write application code. If an instrument moved to another test station, its driver went with it. Drivers, therefore, let you remove instrument-specific commands from your application code.

VXIplug&play standards advanced instrument programming still further. Virtual Instrument Software Architecture (VISA), which resides underneath instrument drivers in a software hierarchy, established a single set of commands that instrument drivers for VXI, IEEE 488, RS-232, Ethernet, and recently, USB, could use.

Interchangeable Virtual Instrument (IVI) drivers provide even more commonality among instrument classes. With these drivers, all scopes use the same commands, as do other instrument classes such as meters, power supplies, function generators, and spectrum analyzers. IVI drivers let you replace instruments with models from other manufacturers without changing application code.

While drivers ease the burden of redeploying instruments, the key to reusable code lies in software modules—specific routines packaged into callable code blocks rather than large, stand-alone executables. Modular code can help you avoid unmanageable "spaghetti" code. Each step in a test application should reside in a separate code module so you can reuse that code in new applications.

Most electronic devices require that you make the same measurement under different conditions, but with similar or identical steps. For example, you might measure amplitude and phase of an audio or RF transmitter at numerous frequencies and power settings. With reusable code modules, you simply call the module and feed it the necessary test parameters.

Commercial test executives such as National Instruments' TestStand can help you organize instrument setups and measurements into tests and help you organize tests for each UUT. Rather than write a complete application for each UUT, you write the test code and let the test executive handle the sequencing, limit testing, result collection, database access, and report generation. Thus, you can reuse code both within and across applications.

Test executives communicate with code written in several languages. You might be fluent in LabView while your colleague is fluent in a text-based language such as C, C++, Visual Basic, or the new .NET languages, Visual Basic .NET and C#. A test executive that works with Visual Basic 6 and Visual Basic.NET—two incompatible languages—lets you preserve your investment in Visual Basic 6 code while letting you write new applications in Visual Basic .NET or your preferred language (Ref 1).

Test executives let you redeploy software while instrument drivers let you redeploy hardware. You can also redeploy test assets when you upgrade a production test stand. You can, for example, reuse obsolete hardware by deploying it in field test. Because you've already written and debugged test code, you can use it to aid service engineers and technicians by letting them use some of the same code you use in production. Don't let your existing hardware or software sit on a shelf.