Should you upgrade your old test system?

Upgrading a test system costs money and takes time, but it can increase your productivity.

Paul G. Schreier, Contributing Technical Editor -- Test & Measurement World, 4/15/2001

If your boss insisted you use a 286-, 386-, or even 486-class PC on your desk, you’d probably ask for a new computer or look for another job. So, why would you settle for an outdated computer on your test stand? If you have test stands built around equipment that’s more than a few years old, you may have to start thinking about upgrading or replacing all or part of those systems.

Upgrading a legacy system isn’t as isolated a problem as you might think. Chandran Nair, VXI/PXI product marketing manager for National Instruments (Austin, TX), estimates that 20% to 30% of the test stands he sees in the field qualify for legacy status. These systems are built around a PC running DOS, maybe Windows 3.1, or Unix. The systems often contain XT-bus or AT-bus test instrument cards or rack-and-stack units that engineers can no longer maintain or replace.

Upgrading an older test system can be a painful experience, and sometimes it’s easier to replace the system entirely. If you decide to upgrade or replace your test stands, plan for future upgrades. Work with interchangeable instruments; use drivers that let you change instruments without writing new code. Write software that isolates low-level, hardware-dependent aspects from the rest of the program.

Before you can decide when to upgrade, you have to decide if you should upgrade, especially if your existing system works well. Indeed, some people aren’t convinced that upgrading just to get the latest bells and whistles is worthwhile.

Roger Southwick, an EMC engineering consultant (Silver City, NM), questions the wisdom of upgrading a working system. Southwick says moving from DOS to Windows won’t necessarily get you more accurate data; only better instruments and measurement techniques can do that.

Southwick uses PowerBasic for DOS (Ref. 1) to develop his EMI test software because of DOS’s smaller and faster programs. He runs his software on an enhanced 486 CPU running at 133 MHz. For his application, a faster processor won’t produce measurements in less time because the IEEE 488 bus and instruments limit the test time, not the software or operating system. Southwick’s system uses a spectrum analyzer, so the program sits idle during sweep times. As for visual displays, PowerBasic supplies a graphics mode. Because DOS programs are fast, he saves the data in an array and replots it as needed.

Sooner or later

While your old test stations may work today, they may eventually break down. If an instrument breaks, you may not be able to get a direct replacement. And manufacturers may not support old hardware or provide technical support, and they probably won’t fix any bugs in the drivers.

Modifying or upgrading test programs can be tricky in legacy systems. The system’s software may still run, but no one may know how to program it anymore. Development software that’s fallen by the wayside includes Keithley’s Asyst (DOS), Wavetek’s WaveTest, and Tektronix’s Tek TMS (Windows 3.1).

A different scenario

In production, upgrading or replacing your test stand may improve throughput or enhance your yield—unlike in Southwick’s application. An improved test stand may pay for itself in terms of increased yields.

Figure 1. This production test station required a thermal chamber to maintain the temperature of voltage references under test. Courtesy of Agilent Technologies.

Figure 2. Custom VXIbus cards hold voltage references under test inside the equipment rack, eliminating external power supplies. Courtesy of Agilent Technologies .

Bert Kolts, manufacturing development engineer at Agilent Technologies (Loveland, CO), designed a test station that improves yield and throughput of voltage references for his company’s 3458A precision DMMs. With the old station, technicians placed 576 UUTs into a temperature chamber (Figure 1). Switch matricies (in Figure 1 next to the computer) connect the UUTs to a 3458A for measurements. The rack on the other side of the chamber holds power supplies.

The new system (Figure 2) doesn’t need a temperature chamber because it controls its own rack temperature. The custom VXIbus chassis holds 384 UUTs. The VXIbus chassis supplies power to the UUTs, eliminating external supplies. These improvements cut the system’s footprint by four times. Shorter signal paths, a result of mounting the UUT in the chassis with the switches, reduced system noise by three times.

The spectrum analyzer at the top of the rack adds a feature missing from the old system: RFI detection. According to Kolts, the system reruns tests that occur when the spectrum analyzer detects too much RFI in the plant. Fortunately, excessive RFI is rare, so the system rarely has to rerun any tests.

Even with just 384 UUTs as opposed to 576, the new system produces just as many good parts per week as the old one. Kolts says the new system improved test yields by 28% and cut test time from 7.5 hrs to 3.5 hrs. In addition, the software performs more statistical calculations than the old system. The additional data lets engineers better predict the voltage references’ performance.

If you think your test stand needs improvements, you’ll have to sell the idea to management. You’ll need to know how long the products your test stand must test will be produced. When Kolts designed and built his new test stand, he knew the end of the 3458A’s life cycle was nowhere in sight. Likewise, military and aerospace automatic test systems often must operate for at least 20 years. But not all test equipment will have such a long production life. Many instruments once had production life cycles of at least a decade—today, life cycles of less than five years are common. Short life cycles mean you may have a hard time replacing old equipment.

Upgrading your code

As with any engineering project, hardware is only half of your development. When replacing or upgrading a test stand, you may want to preserve as much of your legacy code as possible. Unfortunately, legacy code is often difficult to upgrade. For example, its author may have left the company, the code likely doesn’t follow any of today’s standards or methodologies, and so on.

It’s not difficult to understand why legacy code is often in rough shape. Electrical engineers, not computer scientists or professional programmers, programmed test stands. “I look at the code I wrote 20 years ago and cringe,” says Mike Karin, R&D project manager at Agilent Technologies (Colorado Springs, CO). At that time, most managers demanded productivity and did not give much thought to the code’s structure or legacy potential.

In automated test’s early days, engineers wrote their test applications in interpreted Basic and sprinkled in instrument-specific I/O statements that sent commands and received data strings in a program. Because of its built-in formatted I/O capabilities, Basic matched well with the formatted ASCII command and data strings used to control message-based, IEEE 488 instruments.

These early test-program authors didn’t have the test executives and instrument drivers that now separate high-level test operations from low-level hardware-dependent routines. In many cases, engineers didn’t liberally add comments to their test programs, either. They wrote a program that worked and dropped the development there.

The quality of your legacy code impacts its reuse value, says Alex Ivchenko, R&D engineering manager at United Electronic Industries (Watertown, MA). If a DOS program is split into well-defined parts, you might be able to preserve certain processing routines. In some cases, you’ll encounter “spaghetti code” where the user interface, data-processing routines, and low-level hardware-dependent functions are mixed together making calls back and forth with GOTO statements or equivalent functions.

If you are writing new test code, make the new program operate in a similar fashion to the original one. For instance, keep screen controls in similar locations and don’t change hot-key assignments. Otherwise, the transition to the new environment will be more difficult for your production people.

Whether you replace a single instrument in a test stand or you build a new system, you can expect to write new code. Often, the new equipment lets you add tests that were time consuming or difficult when you built your existing system. T&MW

References

1. Learn about PowerBasic at www.powerbasic.com.

2. Keithley no longer supports the Asyst software. You can download it free from: www.keithley.com/techsupport/boards/legacy.html. Editor's Note 10/24/03: This software is no longer available for download at the Keithley site.

Paul G. Schreier is a freelance technical writer. He is the former editor of Personal Engineering & Instrumentation News and chief editor at EDN magazine. He has a BSEE and BA from the University of Notre Dame and an MS in engineering management from Northeastern University.