Managing test code provides flexibility

Software development in a dynamic analog R&D environment requires sophisticated project management to meet tough time challenges.

Darryl Phillips and Talal Al Attar, Center for Analog Design and Research, Santa Clara University -- Test & Measurement World, 1/17/2012 3:38:23 PM

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.

The R&D lab at Santa Clara University includes an automated system for testing analog components. Click on Figure to enlarge

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.

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.

We've developed a methodology for efficient project execution that lets us develop new LabView code in one or two days. Here is a five-step process followed by programming tips that you can use in your project. Performing these steps requires understanding the typical analog test.

Prepare an early vertical-slice prototype.

1. Partition code for better LabView IDE speed.
2. Proliferate a comprehensive collection of modular code.
3. Refine the solution during application to initial test cases.
4. Deploy the polished solution in a reusable way.

Figure 1. The LabView code shows the main subVIs of an analog test: Setup, Test, and Tear Down. Click on Figure to enlarge

Analog tests typically consist of setup, test, and take down, as illustrated in Figure 1. Setup resets the instruments to a known state, clears old data and error messages, configures registers for communication, sets the desired operating modes, and connects the test equipment to the DUT. The code also sets status registers, which will make errors and command completions detectable. For example, the code may need to set the OPC (operation complete) status bit. That forces the instrument to raise a service request when done executing a command, which coordinates data transfer.

A test typically consists of a hierarchical stack of subVIs implementing nested loops, as illustrated in Figure 1. Each loop sets a parameter of the test. For example, a load regulation test may consist of a loop that steps load current, inside of loops that step supply voltage, ambient temperature and output voltage settings. Note that this and the following figures are simplified sketches. The real production code is too complex for instructional purposes.

Take down, the inverse of setup, returns the instruments to a safe ending state. The only detail added here is that power sequencing is often critical when testing analog circuits. Power-supply voltages should stay active until after the system de-energizes the DUT's signal inputs. This kind of power sequencing prevents activation of internal power circuits from latching-up and potentially destroying the analog IC.

Narrow Layered prototype

Figure 2. Develop the hierarchy of function calls (subVIs in LabView) from the user interface down and the instrument calls up, meeting in the middle. Click on Figure to enlarge

Begin development of the LabView test software with an in-depth layered architectural prototype of the entire test software system. The prototype should encompass all the details of how the system will operate but still minimize initial development time. For example, prototype the instrument driver layer by choosing a single representative instrument such as a benchtop power supply. Then refine the architectural details of instrument control and data reporting. Construct the prototype from the bottom-level instrument calls up and from the top-level user interface down, meeting in the middle (Figure 2). Use this step to get the code right the first time, before bugs can proliferate across all your code files. Start this step early because it requires time for thought.

When designing the prototype, anticipate future features and requirements, even if they're not included in the initial implementations. Add features such as safety shutdown and status reporting. Implement each feature in a modular way and include the "hooks" in the initial test code to add them in the future if necessary. Because G is a drawn language, including provisions for additional features will pay off as the system expands.

Pay attention to modularity and to how the system will pass information. Doing so enhances VI reusability. In particular, be careful about how the system passes test-configuration parameters through the hierarchy. That's especially important when you make modifications to add more test loops to the stack or when you add instruments. Implementation and coding styles that work for small projects may lack the ability to scale into a larger system. The following tips will help you build an initial prototype.

Tip 1: Type-define all custom data

Figure 3. For automatic updating, type define LabView clusters and enumerations-see "Type Def" at the top of the screen-to include the attributes of a loop control function such as equipment used, starting value, and step size. Click on Figure to enlarge

behind-the-scenes database that automatically updates all instances. Type define custom data by saving them in files as controls, with the Type Def. setting selected (Figure 3). Be sure to instantiate the custom data from the Controls Palette or Functions Palette to ensure that you're using a type-defined copy.

Tip 2: Use objects to abstract instrument interfaces
Modern instruments use a variety of communication interfaces such as USB, GPIB, and Ethernet. We recommend that you manage all communications through object-oriented programming techniques. To do that, create an interface parent class and then create child classes for each interface. The classes can share a common set of member VIs implementing interface communications such as read, write, and check status. This kind of structure lets you add or change interfaces without breaking the test code.

Tip 3: Implement the instrument drivers using objects
Use instrument-driver objects derived from a common parent class to improve instrument interchangeability and code portability across lab benches. LabView version 8.2 added support for objects. When implemented as member VIs of objects, instrument driver VIs can share the same names and a common interface, simplifying code construction. Even better, when instrument driver objects are carefully implemented from a common parent, you can exchange them without modifying the test code (Figure 4). Doing this also lets the system select, add, and remove instruments during test execution. Unimplementable commands, such as Set Source, when applied to a DMM, can return NULL values in the member VIs of the parent class.

Figure 4. LabView instrument-driver VIs set up as members of parent/child classes let VIs automatically change as your instrument needs change, without rewriting the test code. Click on Figure to enlarge

Tip 4: Use templates to create modules for top and mid-level code.
Creating top-level tests and GUIs from common templates lets you add or exchange them quickly, without breaking the test-system GUI VIs. Templates also help to modularize mid-level code. As the reusable, modular VIs accumulate, test development will accelerate tremendously and quality will improve if you use templates.

Tip 5: Pass Test Data in Arrays
When characterizing analog ICs, you will need to add and remove instruments from the tests. As a result, the quantity of parallel paths carrying setting parameters and measurement data will also change. Adding and removing data flow paths is time intensive and tedious. Instead, implement the data flow paths using arrays (Figure 5). This technique can be extended to the instrument parameters themselves, which lets the test software add, remove, and update instruments. In this example, Measure.vi takes an array of settings, imparting the ability to take measurements from any arbitrary quantity of instruments. The output data-flow paths are arrays as well, supporting any arbitrary quantity of data. The output data-flow array paths can then be indexed to extract data for saving, graphing or analysis.

Figure 5. This LabView VI passes data between subVIs in arrays so that the quantity and type of instruments, settings, and measurements can change without rewriting the test code. Click on Figure to enlarge

Tip 6: Take dummy measurements first
Dummy measurements instruments such as DMMs a chance to autorange, which gives the test circuit time to settle from range changes before the system collects data.

Tip 7: Minimize DMM clicks
Some DMMs click their relays unnecessarily in response to "measure" and "configure" commands, causing relay wear. Instead, query the instrument to verify the measurement configuration and send only a "read" command if the configuration is correct.

Tip 8: Record the test conditions with the results when collecting data.
When revisiting data or when analog product bug symptoms arise, you'll want to know the test conditions. So, include measurement setup information and test conditions when recording the test data.

Tip 9: Save test graphs
An automated test system can collect more data than needed. Ease analysis by either saving pictures of the test GUI graphs or automating graph generation through Microsoft Excel.

Partition the code

No software development environment is perfect and each embodies engineering tradeoffs. For use in analog device testing, LabView has many advantages but one relevant flaw: The IDE (integrated development environment) is single-threaded with the compiler such that compilation ties up the development interface. Furthermore, compilation initiates spontaneously as projects are opened and saved. For small projects, the impact of single-threading the IDE is trivial. Analog R&D projects can, however, easily accumulate several thousand source-code files. As the number of source code files in the project exceeds around 1,000, the development IDE begins to slow down.

Careful code partitioning can maximize LabView IDE speed when working on large projects. Partition the code into top-level GUI code and operational code. Restrict use of clusters to the top-level GUI code. Then, transition to classes for the middle and bottom-level operational code. This technique eliminates unnecessary time for redrawing clusters during compilation, improving large-project speed.

Proliferate a comprehensive core collection of modular code

Use the initial instrument drivers, mid-level code, and tests as templates to proliferate the vertical-slice prototype into a comprehensive development platform. Complete this step before beginning operational test development for the project. The most common mistake is starting software development too late. Preemptively create a collection of VIs that can be quickly connected to build new tests or modified into new VIs as a countermeasure for that mistake.

Refine the solution during application to initial test cases

Many requirements, changes, and bugs don't appear until you apply the test software in real-world projects. Therefore, apply the test software to a representative selection of initial cases before final, full-scale deployment. Most likely, a comprehensive revision of the test code will be required at this point so allow time to solve these problems. You can identify and complete any necessary major architectural changes while the code base is relatively small, which will minimize time and effort.

After exercising diligence in implementing all these tips during creation of your LabView-based test system, you'll have a utilitarian work of value that you can be proud of. Finally, you should vigilantly follow through with modular programming. Doing so will ensure that a critical mass of code accumulates for accelerating future development work. With care, you can achieve 1-2 day development times.

Darryl Phillips is a graduate engineering student at Santa Clara University. Talal Al Attar is a professor at Santa Clara University. E-mail darryl3@ypresian.net.