Blend Text and Graphics to Create Test Programs

Competing test-program development environments offer bewildering combinations of text and graphics tools that can help you get your test software up and running. Your choice may be a matter of personal taste.

Rick Nelson, Senior Technical Editor -- Test & Measurement World, 10/15/2000

Graphical test-development programs are well-established tools of the test engineer, and users can exhibit an almost religious devotion to their chosen packages. What works for a colleague might not be best for you, however. If you are considering a test-development package for the first time, you should choose one that lets you build on the programming or engineering skills you already have. To help you decide, I looked at four programs: Agilent VEE from Agilent Technologies, ATEasy from Geotest, LabView from National Instruments, and TestPoint from Capital Equipment Corp. (CEC).

A word of caution: No magazine article—or for that matter no CD-ROM-based tutorial or example that accompanies these programs—can make you instantly proficient. If you’re new to these tools and need to get a test application up and running tomorrow, you’ll need to enlist an expert. To become an expert yourself, you’ll need to attend training sessions for the program you choose. In this article, I aim to outline the programming styles embodied in each environment. After reading this article, you should spend some time with demo versions of the packages that most appeal to you before making a final choice.

A bromide addressed to sales representatives says: “Tell customers about their lawns—not about your grass seed.” The online tutorials and literature that accompany the packages I evaluated tended to ignore this instruction. The authors have assumed a burning desire on your part to understand how their programs work—not how to solve your test problems. In an attempt to address the basics of how you would handle a test-development project using each program, I imagined a test of a simple DUT: My imaginary DUT adds a random noise signal in the range of –0.5 V to +0.5 V to a 0 to +10-V input. My imaginary test applies a 0 to +10-V ramp to the DUT and measures the output.

Writing Source Code

Because I could describe my imaginary test application in a couple of sentences, I believed I could quickly write the corresponding test program in a few lines of text-based code. (Full disclosure: As a writer, I admit a bias toward natural-language-like, text-based programming tools.) ATEasy provides strong support for text-based programming, so I fired it up and got started.

ATEasy is essentially a framework that embodies your test software components (such as instrument drivers, test programs, variables, and run-time graphical interfaces) within a Windows Explorer-like tree structure. This structure lets you break your code into brief, reusable, easy-to-write, and easy-to-debug segments that will execute under control of ATEasy’s test executive. Figure 1 shows the expanded leaf showing my noisy-DUT test, which I called NoiseTest.

I typed in the brief source code. The on-time compiler’s debugger quickly pointed out my typos and indicated what lines contained errors and what was wrong with them. The source-code editor includes an autocomplete function that helps minimize syntax errors. The editor also provides menu-driven command insertion; I didn’t use it, but it could be particularly helpful for infrequently used commands.

NoiseTest uses a “for” loop to simulate a 10-step, 0 to 10-V source voltage ramp. ATEasy’s random-number function, rnd(), plus some scaling and offset operations simulate the DUT’s –0.5 to +0.5 V noise. Test results appear in a log file. For a run-time application, ATEasy can direct program output to a graphical user interface that simulates instrument panels. The panels can represent meters, oscilloscopes, and pass/fail indicators, and also can include actuators such as switches and sliders. Within the development environment, you can store panel GUI designs under a leaf labeled “forms” within the ATEasy tree structure. A Visual Basic-like forms editor lets you modify the run-time graphical interface.

Figure 3. The venerable "for i=1 to N" statement becomes a graphical symbol (left) in LabView. Loop parameter N is a 32-bit integer (indicated by the I32 designation) provided by a virtual-instrument front-panel control (right).

Figure 4. (top) A virtual-instrument panel and (bottom) a source-code diagram window characterize LabView projects. For my application, panel controls included a loop-count input, a noise-offset adjustment, and DUT input and output waveform displays. In the diagram window, the pair of dice generates a random number between 0 and 1.

Figure 5. (top) Drop-down menus let you select devices like function and noise generators in Agilent VEE. (center) You can also use menus to select data-display options ranging from meters to graphs. (bottom) I used a function generator, noise generator, adder, and an x-y trace to implement my noise-test application. The graph shows DUT input voltage in red and DUT output voltage in yellow.

Vendors Mentioned in This Article Agilent Technologies, Palo Alto, CA 800-452-4844; ftp.agilent.com/pub/mpusup/ agilent/vee/vee.html. CEC, Billerica, MA 978-663-2002; www.cec488.com. Geotest, Santa Ana, CA 888-837-8297; www.geotestinc.com. National Instruments, Austin, TX 512-794-0100; www.ni.com.

Like ATEasy, TestPoint provides easily readable text source code. Unlike ATEasy, however, TestPoint affords a distinct graphical orientation to its development environment. When launched, TestPoint displays a “stock” of objects (Fig. 2, upper left) as well as a blank instrument panel and object window. Program development involves dragging these “stock” components to the object window. Actuators (such as switches and sliders) and indicators (such as meters and waveform displays) dragged to the object window appear on the instrument panel, too.

To move my NoiseTest program to TestPoint, I dragged a “Start” button and two indicators (one to display input ramp voltage and one for DUT output voltage) to the object window (Fig. 2, lower left); they appear on the instrument panel (upper right) as well. Realizing I would need a program loop and a math function to complete my program, I also dragged loop and math symbols from the stock window to the object window.

With necessary objects at the ready, I double-clicked the “Start” button in the object window to display the “Object ‘Start’” source-code window (Fig. 2, center right). To begin programming, I dragged the loop object into the source-code window, resulting in the automatic generation of source-code line 1 as well as prompts to enter loop numerical parameters (0, 10, and 1, for my program).

Then, I dragged the source voltage indicator into the source-code window and was prompted to specify what data to display (in this case, the loop index value, representing DUT input voltage) and whether new data should replace the existing display data or be appended to a new line (I chose to append the new data). Next, I dragged the math object into the source-code window and added a formula for calculating DUT output voltage: Subtract 0.5 from a random number between 0 and 1 and add the result to a variable a (in this case, the input voltage represented by the loop index). Adding the DUT output indicator to the source-code list and specifying that the indicator should accumulate DUT output data completed the development task.

All Graphics, All the Time

For text aficionados, moving to LabView is like moving to the Twilight Zone. The venerable “for i=1 to N” statement is gone, replaced by the graphical symbol shown in the left-hand window of Figure 3. LabView is a data-flow programming environment, and almost every object has data inputs or outputs. In LabView, the loop parameter N is no longer an integral part of a line of source code. It’s an input. In Figure 3, it’s an input from a control that occupies a virtual-instrument front panel along with switches, status indicators, and waveform displays.

A LabView project involves two windows: a virtual-instrument panel (Fig. 4, top) showing controls and indicators and a diagram window (Fig. 4, bottom) showing graphical source code. Working in panel mode, you can drag actuators and indicators from a “Controls” toolbox onto the virtual instrument; corresponding symbols will appear in the diagram window. Working in the diagram window, you can add mathematical, logical, file-control, and other operations to your source code by dragging them from the “Functions” toolbox. A wiring tool from the “Tools” toolbox lets you connect the functions.

In my diagram, all functions reside within the for loop outline, indicating that they will operate repeatedly (11 times here, representing 11 voltage steps from 0 to 10 V) under loop control. The loop index, i, represents DUT input voltage; it’s converted to a double-precision number by the DBL symbol. The dice graphic generates a random number between 0 and 1. The noise-offset value subtracts 0.5 from the random number to center the noise representation around 0.

Adding Text to Blocks

The function and control symbols in LabView can be cryptic to novices, and beginners might find the drop-down menus of Agilent VEE (Fig. 5) easier to use, at least at first. To implement my noise-test program, I selected a function generator, noise generator, x-y plot, and a formula, which in this case simply adds two inputs. The noise generator and formula represent the DUT; the graph plots DUT input (red) and output (yellow) waveforms. Similar to the other packages, VEE provides a panel view for run-time use; the panel view suppresses the wires and function-block details, providing only the graphics an operator needs to run, not modify, tests.

The VEE function generator I chose generates a sawtooth wave centered on zero with a user-specified, peak-to-peak amplitude. To mimic the 0 to 10-V ramp I simulated using a loop in the other programs, I used the first 5 ms of a 20-V, peak-to-peak 50-Hz sawtooth wave, plotting 11 points.

Delving Deeper

All four of the programs discussed here are capable development environments for test applications. I only introduced the methods used to perform basic operations in each. Your comfort level with the various combinations of text and graphics capabilities will help you determine which program is right for you.

Beyond the basic operations, you’ll need to consider other factors. If your programs will be deployed on old computers in a production environment, speed might be an issue. ATEasy and TestPoint are event-driven packages that can run faster than data-flow programs like LabView and VEE. While LabView and VEE can take up processor power by continually monitoring virtual-instrument controls such as front-panel push buttons, event-driven programs can rely on the Windows operating system for those tasks without imposing processor overhead until a relevant event occurs—for example, if an operator clicks a “Start” button. For slow computers or for applications having hundreds of buttons, the performance differences can be significant.

In addition, you’ll have to consider how easy it will be to debug and document your program and for others to understand how it works. Despite my preference for text, I have to admit that the VEE display in Figure 5 is easy to understand. The corresponding LabView implementation (Fig. 4) is slightly more cryptic for novices, but not for experienced LabView programmers. The clarity of either diagram could degrade rapidly, however, as the number of blocks increases, requiring you to scroll across many screens to take in the complete picture. VEE function blocks can be minimized, but then they no longer display the parameters that provide much of the clarity. All in all, there are no clear-cut winners—the programs offer a range of unique features you can employ according to your needs and abilities. T&MW

 You can contact Rick Nelson at rnelson@cahners.com.