Software Details Spell Success

Today, most testing requires computer-based instruments that control test stimuli and record test results. Choosing the right software, whether it's a test development environment such as LabVIEW, Test Point, or Agilent Vee, or a traditional programming language such as Visual Basic, C, or C++, requires lots of work. After you get beyond price and standard features, look at the details. The four points described below—driver software, measurement capabilities, software investment, and data sharing—may seem mundane, but ignore them at your peril.

First, know your drivers. Engineers must ensure their test application software can communicate with the instruments they need to control. That communication requires drivers, usually supplied by an instrument vendor, but sometimes available from a third party. An instrument driver, or library of drivers, should explicitly state that it can work within the environment or language you plan to use. (The previous "Test Experts" column covered drivers in detail. Go to www.designnews.com/article/CA375681).

Engineers often take drivers for granted, but drivers don't necessarily exist for all languages or development environments. You may find, for example, that an instrument comes with drivers for C/C++, but not for Visual Basic (VB). When engineers plan to upgrade an older system, they may discover the only "driver" is an old manual that describes IEEE-488 commands. As you research instruments and software for a new test system, make a chart that relates needed instruments to the corresponding drivers provided for various languages. If at all possible, avoid writing your own drivers.

Test development environments often come with "wizards" or "assistants" that guide developers through instrument setup and control. These tools make it easy to get started by automatically configuring instruments to make specific measurements. Some driver libraries offer soft front panels—a virtual display of an instrument's controls. Manipulating virtual controls lets developers quickly test instrument communications and configurations. If you lack a driver, Instrument I/O Assistant in National Instruments' LabVIEW Express 7 will help you establish instrument computer communications.

Second, consider measurement capabilities. All software comes with fundamental math operations, and add-in libraries often supply curve fitting, Fourier analysis, and other functions. But what happens when you want to measure a signal's amplitude, phase, or power. Those functions come as part of test development environments. Most general-purpose languages lack such analysis functions, so if developers need them, they have to write them. That's an important distinction between test development environments and general-purpose programming languages. The latter may provide great flexibility, but the former can get a test system running quickly without much programming.

Twin Peaks: Test development software lets users quickly plot results and incorpoate them in reports, company databases, websites.

Test development environments also provide the capability to easily add user-programmed measurement capabilities. Here's an example: Engineers need to measure the amplitude of a voltage spike on a signal. They combine existing functions to acquire the signal and extract the spike's amplitude. They then place the new function in a library for later use. Software aimed at test applications should let developers define this type of special measurement, which they and others can use again and again. Developers don't have to worry about the data's format, where the data comes from, or where it goes.

Third, protect software investments. You shouldn't have to continually upgrade software and switch to new programming techniques. Software suppliers should make it easy to take advantage of new capabilities, such as XML and .NET code, without forcing you to abandon existing software and tools. Microsoft, for example, provides tools that help convert older VB source code into a VB .NET (dot-net) program. But, only about 50 percent of existing VB code "migrates" without modification. That's not the sort of change a development team wants to face when a vendor introduces a new technology.

As you evaluate software choices, look for communities of active users for specific tools. A group of active participants can put you in contact with others who went through a similar evaluation process and who have similar applications. User group meetings and e-mail forums are set up to let you discuss ideas with colleagues. Good manufacturers nurture their users and pay attention to gripes, requests for new features, and similar communications.

Look for suppliers that offer good documentation, third-party alliances, and comprehensive training. Companies also offer short seminars at which they demonstrate their products and make available their software experts. Those types of activities usually show a commitment to good support and attention to detail.

Fourth, share your data. After a test system acquires data, users need to view it. Some development environments and languages can easily export data to programs such as Word and Excel. But test systems also may need to transfer results to a corporate database, post test results on a web page, or automatically send reports by e-mail. So, when looking for test development software, keep these added requirements in mind. Even if an application does not need these capabilities now, future users may ask for them. Even non-networked test applications should quickly generate reports, plot data (often in color), and offer flexible reporting formats that developers and users can adjust to their needs.

In Full Control: Complex text systems can move a sample, inspect it, as well as perform electrical measurements, all under control of test software. Test applications require careful integration of measurement, motion, in addition to vision functions.