Code behind the icons drives test languages
Don
Rick Nelson, Senior Technical Editor -- Test & Measurement World, 4/15/2001
Graphical programming environments and high-level languages (HLLs) make it fast and easy to develop test applications. (Ref. 1 provides an introduction to the look and feel of several such programming tools.) Ultimately, however, the graphical icons or HLL statements (Figure 1) must give way to binary code that executes on your PC’s processor. The way a programming tool creates that binary code can lengthen the time it takes you to debug your test program as well as the time your finished program takes to execute in the production environment. Several factors can limit the throughput of a measurement system. The measurement delays within the instrumentation you are using are the most significant. If it takes a DMM a second or two to acquire a reading, the time your processor spends storing the measurement result or calculating a running average based on it will be insignificant. But if you require more extensive calculations, if your processor must monitor many potential input channels, or if your application is deployed on relatively slow legacy PCs (Ref. 2), then processing times can become significant. In these cases, you’ll want to ensure that the development environment you choose will yield a run-time executable that doesn’t bog down production-test throughput. A test-program’s execution speed can depend on two factors inherent to the program itself (that is, independent of system-processor clock speed and memory capacity): the raw execution speed of the code that each of its graphical objects represents, and the efficiency with which the compiled or interpreted code takes advantage of available system resources. The execution speed of each object will in turn depend on whether the code is compiled or interpreted. If compiled, then the development program compiles a binary-code version of the entire graphical interface plus HLL text before execution. If interpreted, the development program generates binary-code representations of graphical or HLL text program objects as required during execution. Geotest’s ATEasy takes an intermediate approach, called just-in-time compilation, in which it compiles only the code required to verify the operation of program segments containing recent changes. Keep in mind that the performance you get in the lab won’t necessarily represent the performance you’ll get on the factory floor. Programs that run under interpreters in the development process may seem slower than complied programs. Yet most interpreted programs come with compilers that generate Windows executables whose performance may be competitive with that of compiled ones. (See Table 1 for a list of test-program development environments.)
Figure 2 illustrates the compiler and interpreter choices and tradeoffs you can make in the development and run-time environments. If you’re the type of programmer prone to repeated trial-and-error efforts to get a program to work, you might benefit from employing an interpreter in the development environment. Your code will run slower than equivalent compiled code would, but you can quickly make changes and rerun your program. This process can be advantageous if you’re developing a large program that includes many conditional branches that don’t execute each time you run the program. With a compiler, if you make a small change to one branch, you’ll need to wait for the entire program to recompile before you can try out your change.
All the programs listed in Table 1 support compilation of executable files that you can distribute to the production floor. (Agilent VEE requires that target machines include a run-time support executable as well as the application executable.) Production-floor personnel can’t alter these programs; so, to accommodate product changes, you’ll need to update the test program in your development system and recompile and redistribute the Windows executables. If you anticipate testing a variety of DUT types requiring frequent yet minor test-program modifications, you might want to deploy one full-blown development system on the production floor. Programs upgraded on that system could be quickly distributed to the run-time-only platforms. Tweak performance When you command a program to execute the binary code underlying a graphical icon, you have no control over the number of clock cycles and the amount of memory the execution will consume. If brand X’s fast Fourier transform (FFT) icon compiles into code that requires an excessive amount of processor clock cycles to execute for a particular set of data, all you can do is evaluate another program’s FFT performance and hope it’s fast enough to meet your requirements. (Of course, you could augment brand X’s built-in library with your own assembly-language FFT implementation, but if you’re writing FFT routines at that level, a graphical programming tool would probably be a poor choice for you to begin with.) Poor performance can stem from an inefficient numerical algorithm or from a compiler or interpreter’s inability to exploit system features such as multiprocessing. Because you can’t control either of these factors, your only choice is to find another program with a better algorithm or one that can automatically divide program execution into multiple threads that can execute independently on multiple system processors.
Program performance, however, depends on much more than the execution speed of the code behind each icon. When you start connecting icons and adding your own user functions, you start gaining control over how efficiently your program will run. In general, keep the number of icons your program requires to a minimum. For example, in the Agilent VEE program of Figure 3, the single formula block in the lower thread, which calculates (A+B)C/D, is more efficient than the separate addition, multiplication, and division blocks in the top thread (Ref. 3). Other speed-enhancing tricks you can take advantage of in VEE include performing calculations on arrays of data—if you need to calculate the square root of each of a series of measurements, for example, store all measurements in an array and then extract the square roots in one operation. In addition, you can speed execution by minimizing VEE graphical elements before running programs. In Figure 3, for example, the meter connected to input C in the top thread is shown minimized in the bottom thread; when the bottom thread runs, it needn’t spend time rendering the meter with updated needle positions. Multiple threads The two threads of Figure 3 shouldn’t be confused with the multithreading feature of some programs. The threads in Figure 3 constitute separate program threads because they can operate independently. A program featuring multithreaded capability can assign independent threads to independent processing resources. Such a program allows you to define threads (or will automatically detect threads) while compiling multithreaded code that efficiently divides program operations among multiple processors on multiprocessor systems. Or it could isolate real-time-critical tasks from background tasks to permit pre-emptive operation of real-time-critical test tasks on single-processor systems. LabView will establish such threads for you, maintaining separate user-interface and I/O threads. A LabView properties function lets you assign priorities to various threads in a program (Ref. 4). Graphical programs such as LabView help you see which parts of a program can be separated into threads. In Figure 3, for example, it’s clear that the threads are completely independent—neither depends on the other for intermediate results.
Text programs, too, can employ multithreading. ATEasy, for example, which incorporates HLL programming modules organized within a graphical tree structure, uses simple command sets to let you create threads (Figure 4), which it then manages in background. ATEasy establishes native Windows threads and allows you to use the Windows API (application programming interface) to change thread priorities. Any thread can take control of the user interface and can call COM and ActiveX objects. Monitoring performance With some graphical programs, you can improve program performance if you know where your program is spending its time. For example, LabView’s performance-profiling function (Figure 5) indicates processing time and memory usage devoted to the virtual instruments represented by the program. If you learn that some noncritical tasks are hindering the operation of real-time-critical ones, you can insert wait commands in the noncritical functions to ensure they yield system resources to real-time operations. Data-flow vs. event-driven Finally, you'll want to consider whether the programs you are considering are data-flow or event-driven programs. A data-flow program uses its own loop functions to monitor controls; an event such as actuation of a switch is detected only when the program periodically queries that switch. For an event-driven program, actuation of a control essentially generates an interrupt that immediately influences test-program operation.
Manufacturers hotly debate the merits of the two approaches. According to CEC (Ref. 6), its event-driven TestPoint program with 25 buttons and 25 displays runs 100 times faster than a data-flow program with five buttons and one display. Not so, counter proponents of data-flow programs. To see some examples that can help you determine which program might best meet your development and performance needs, see " Benchmarks". T&MW References 1. Nelson, Rick, “Blend Text and Graphics to Create Test Programs, ” Test & Measurement World, October 15, 2000. p. 6. 2. Wilson, Dave, and John Hanks, “Should You Upgrade to a 500-MHz PC? ” Test & Measurement World, October 15, 1999. p. 33. 3. VEE Pro User’s Guide, Agilent Technologies, Palo Alto, CA, 2000. 4. Dorst, Norma, “Using LabVIEW to Create Multithreaded VIs for Maximum Performance and Reliability,” Application Note 114, National Instruments, Austin, TX, 2000. www.ni.com/pdf/instrupd/appnotes/an114.pdf. 5. “LabVIEW Performance and Memory Management,” Application Note 168, National Instruments, Austin, TX, 2000. www.ni.com/pdf/instrupd/appnotes/an168.pdf. 6. TestPoint Competitive Analysis, Capital Equipment Corp., Billerica, MA. www.cec488.com/tpcompet.htm. Rick Nelson received a BSEE degree from Penn State University. He has six years experience designing electronic industrial-control systems. A member of the IEEE, he has served as the managing editor of EDN, and he became a senior technical editor at T&MW in 1998. E-mail: rnelson@tmworld.com. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| So, (1) what's the fastest program, and (2) should I buy it? Answers: (1) We don't know, and (2) not necessarily. As far as answer 2 goes, keep in mind that program execution times for most applications on today's PCs are insignificant with respect to measurement times, in both the development environment and the run-time environment. In the development environment, the time you spend inserting and wiring graphical icons and adding HLL code will far exceed the time it takes to run your code. For large programs in compiler-based development environments, the additional compilation times required as your entire program recompiles to accommodate minor changes will give you enough time to be irritated with yourself for having erroneously wired node A to node C instead of node B, but compilation times are unlikely to represent a significant portion of your development effort. Programmer productivity—not execution speed—is the key bottleneck in program development. To that end, the development system whose graphical user interface you find easiest to use is your best bet. Similarly, instrumentation delays are usually the biggest time wasters in the production run-time environment. The second is likely to be operator error. So, your money might be best spent on faster instruments and on developing foolproof operator graphical interfaces—not on faster programs.—Rick Nelson |
