PC-based data acquisition cards and software have been around for more than a decade¾ and instruments-on-a-card have been available almost as long. Initially used only in the lab, PC-based test and measurement equipment has since successfully migrated to the factory floor. Even the earlier capacity and programming limitations have been overcome with a variety of hardware and software products available today.
With the introduction of fast, multitasking PCs and large memories, there are few production test applications that cannot be satisfied by PC-controlled automatic test equipment (ATE.) In many of these applications, the instrumentation hardware can reside in PC bus slots. Certainly, some applications will benefit more than others, such as when space is limited, test requirements change frequently, or a common user interface is required across different production testers.
Data Acquisition or Test and Measurement?
At this point, we need to distinguish between data acquisition (DA) and test and measurement (T&M) applications. DA systems are used where continuous monitoring of a variety of analog (sensor) data is required; for example, in multiple processes. In these types of applications, it is important to be able to create a variety of graphical user interfaces (GUIs) in the form of virtual instrument panels.
In contrast, T&M applications involve short time-frame procedures, although they may be repetitive. A typical example is an amplifier test, which involves stimuli applied from multiple sources such as a function generator and readback power supply, and measurements conducted with an instrument such as a wattmeter. These procedures typically take from 1 s to 5 min.
In a production setting, all measurements and control are accomplished automatically by the ATE. Typically, fewer GUI panels are required for ATE than DA systems, and those panels that are used make life easier for operators by prompting them through procedures (Figure 1).
Both types of systems can be satisfied with PC-based hardware and software. But in each case, it is best to select hardware and software specialized for either DA or T&M as the application demands.
Selecting Hardware
PC-based ATE, along with current test-development software, provides the features needed for most production environments. Instrument cards installed in PC bus slots, or even in a separate chassis, provide excellent functional/space density in these systems. With the advent of local and PCI buses, PC-based configurations are faster than many VXI systems. In any event, test-development software can be used to create or modify test programs for PC-, VXI- and GPIB-based systems.
Given this flexibility in test-development software, what is the special attraction of PC-based systems? As is true of many engineering designs, the answer involves form, fit, function and cost.
GPIB-connected instruments make for physically large systems, and the SCPI command set typically used with such systems offers limited programming capabilities. Such systems still make sense when most of the capabilities of the instruments are used. Instruments-on-a-card may have more limited function sets, but they often are sufficient, much lower in cost and take up far less real estate.
VXI-based systems offer larger test capacity and greater networking capabilities, but test programs developed in the past were frequently custom-designed for very specific test and measurement functions on the shop floor. As a result, these systems may not offer the flexibility needed when developing today’s production testers. Also, the capital investment in these systems tends to be higher than the cost of a PC-based system with the same set of functions.
Test-Development Environment
Cost-effective ATE depends a great deal on test-program development software features. Regardless of the hardware platform, the software must allow a test engineer or programmer to quickly and efficiently write, test and debug production test routines. Often, some of the test functions remain unchanged when new products and test equipment are incorporated in a manufacturing line. In these situations, the development platform should allow easy reuse of previously written test-program code and drivers. When acquiring a new test-development package, there also are advantages if it is compatible with older equipment.
In other words, the software should be transparent as far as the user’s control of hardware is concerned. It should not make any difference which form the hardware takes—PC card, GPIB card or VXI card. In a flexible test-development engine, you can change the physical hardware without changing the basic test program if the same functionality exists in the different hardware versions.
In a production environment, three criteria should be applied when making a decision on the test-development software platform:
User’s background and experience.
Ease in writing and reusing test-program code.
Ease of maintenance, such as program modifications or updates.
DLLs Simplify Programming
One of the attractions of a PC-based system is the ease and convenience of developing the test program in a Microsoft Windows environment. This environment provides a good GUI and an architecture using Dynamically Linked Libraries (DLLs.) Its familiar C-based development tools are independent of the test-development software, but can be easily attached to the environment of the latter. The resulting test programs can be used on many ATE platforms, providing a high degree of portability.
The use of DLLs is very important, because they are linked to a program in a dynamic fashion during run time, as needed. They reside as separate files or drivers with executable C-code and are called when initialized by the test executive or other executable program. This allows for the separate development of DLL files and their modular use with different ATE systems.
The test-development software should provide an easy method of attaching DLL drivers and similar files to the test executive (Figure 2). For example, in ATEasy from Geotest, drivers and other routines are hooked to the test executive by incorporating the command set of a DLL into its high-level program editor. The resulting DLLs become generic test-program elements that can be used in a variety of ATE.
Besides their programming efficiency, modular DLLs also speed up test and debug operations. This can be illustrated within the context of the test-development software structure shown in Figure 3.
A hierarchical structure facilitates working with command sets as programs are developed or modified. For example, once driver DLLs have been created (with C-code, or with the development program’s driver editor), the command sets are available within the program editor. The DLL commands can then be executed within program scripts.
In the ATEasy software, the program editor works in a virtual interpretive mode, so a script program can be executed line by line. A test-program developer does not have to compile and debug separately.
This is very valuable when it comes to testing new drivers and other DLLs before integrating them into a test program. A single line of code can be written, the object file ported to the target system and the code line immediately executed to see results. The test engineer can easily work on only the part of the system that needs to change.
Methodology Boosts Efficiency
It is easy to overlook or underestimate the benefits of the methodology used in a test-program development tool. Still, methodology is often the key to ease of programming and reuse of various software components.
By understanding and taking full advantage of the modular structure in a test-development engine, development time and costs will be reduced. Benchmarks show that such engines can reduce development time by as much as 80% compared with high-level languages. These engines also make maintenance and upgrades of test programs much easier.
Another advantage of this software approach is broader ATE support. If different developers and ATE systems use the same development platform, there are fewer continuity problems when the original test-system programmer moves to another company or division. There also is a familiar test-system interface consistent for different testers, providing shorter learning curves and more intuitive use by operators.
Because it is getting easier and less expensive to implement ATE applications with test-development engines, test programs are becoming more like off-the-shelf software. As this happens, test engineers are less likely to care which type of computer platform is used as long as the necessary functions and performance are available. Still, PC-based systems are likely to be the platform of choice for many manufacturing ATE developers, simply because of the lower cost.
About the Author
Jacob Goldman is the President of Geotest. Prior to founding Geotest and predecessor companies, Mr. Goldman was an Engineer and Product Manager at Fluke. He also worked in the Israeli aircraft industry as an ATE engineer specializing
in digital testing. Mr. Goldman is a graduate of Beer Sheva University in
Israel. Geotest, 18242 W. McDurmott, Irvine, CA 92714, (714) 263-2222.
Copyright 1996 Nelson Publishing Inc.
June 1996