Characterizing analog components in an R&D lab requires many voltage, current, gain, or impedance measurements. Often, these measurements must occur over a range of temperatures and power-supply voltages. Automated test systems can provide measurement consistency and relieve engineers of the tedious task of manual data recording.
Each analog component usually requires a unique set of measurements, often with test equipment that differs from component to component. If the time to reconfigure an automated test takes longer that the time needed to record the test data, there's no point in automating. To get the most from test automation, you must design test software that lets you quickly write new code and integrate it into the system.
Many engineers use LabView, a graphical programming language, to program automated test stations. Programming in LabView involves constructing code segments called VIs (virtual instruments) from graphical representations of operations such as loops, conditionals, or math functions. The LabView programming language, called "G," moves data between the VIs using "wires" (lines of data flow) in functional block diagrams. LabView lets you organize functions into a hierarchy of VIs that called "subVI," which are simply VIs called by higher-level VIs.
Because of its graphical nature, LabView provides a high degree of parallelism, supporting simultaneous, coordinated operations. LabView's built-in support for common instrumentation buses such as GPIB, USB, and Ethernet eases creation of instrument drivers.
In the R&D lab at Santa Clara University, test software often controls six or more instruments that provide stimulus and measurement functions. We frequently change instruments because we have a continuous stream of devices under development. During execution, DUTs (devices under test) may fail catastrophically, potentially damaging test hardware. Test-system software needs provisions for swift, safe shutdown. It's design must efficiently let us retrofit new fault-management code in response to previously unanticipated failure modes.
Figure 1. The LabView code shows the main subVIs of an analog test: setup, test, and tear down.
Code development for analog R&D involves frequent customizations of test code for an ongoing pipeline of many projects. Some code may only be run on a few occasions and then be discarded. Therefore, development times must be short.
Follow the jump directly to the article on Test & Measurement World to see the methodology that allowed the Santa Clara University team to develop new LabView code in one or two days.