Although the answers to these and other questions are important in determining which software and hardware features are necessary to your application, the quest for the right data-collection package need not be overwhelming. This article offers a first step in understanding the basic elements of data-collection software packages.

Regardless of your application requirements or programming skills, you can find a package that will suit your needs. Companies produce easy-to-use and flexible software for all skill levels. Computer software and hardware also have evolved to enable data collecting across the Internet as well as real-time data collection, analysis and display.

Unfortunately, the term has various meanings, depending upon the application. For example, if you were performing a PC-based data-logging application that acquires data from a plug-in board and graphs it to the screen, you would probably seek to view the data immediately -- in what some might consider real-time. More than likely, you aren't concerned about when the data is actually logged, only that you view it on the screen as it is acquired. This denotation of real-time resembles our example because we are only seeking a software-hardware combination where we can view the raw data and frequency components on the screen without delay.

Alternatively, if you were performing a control-loop application or an application where decisions must be based on each data-collection point, real-time signifies determinism and repeatability. In other words, how reliable or reproducible is each control or decision loop? An application example is an aircraft's wing flutter control system, which meas-ures vibration and strain on a wing. A control algorithm is executed based on the vibration and strain data to produce a desired output signal for the wing stabilizers. The loop rates for the stabilizer controls must run at set rates (i.e., deterministic loop times), to be effective in canceling out flutter. It's very important that the stabilizer control loop is robust and never misses a calculation at the set times.

Many people erroneously assume the term real-time simply means really fast. But, as in the case above, even a very slow system can be real-time if the time for given operations is known and repeatable. Conversely, an extremely fast system may not be real-time. It's important to identify whether your system requires hard or soft real-time performance. Soft real-time performance means a given operation will complete within a maximum specified time limit most of the time. Hard real-time performance means an operation will complete exactly in a known specified time consistently. With this in mind, the data logger example would have a soft real-time requirement, while the flutter control example would require a hard real-time system. In general, there are more soft real-time applications than hard.

Our application requires that the software and hardware access the waveform of N samples, perform the Fast Fourier Transform analysis and display the graph before the next N samples are acquired. It requires only that the data is analyzed and displayed in a graph before the next N samples are collected; thus, the processing or graphing can occur at any time within the N sample period. Because we're only viewing the data, missing a calculation won't produce catastrophic effects. Therefore, our example system has soft real-time requirements that we'll need to address in our software selection.

  Turnkey data collection -- These software packages are designed to control one specific application. They are very easy to use, require no programming and need only limited setup. Turnkey software usually includes a graphical interface designed to emulate a stand-alone instrument and features menus for setting up the program. These packages don't require any software other than the computer operating system to develop an application.

However, turnkey software lacks flexibility and can't be used in applications other than that for which it was designed. If some other capability is needed in the software, then users must rely on the manufacturer to add it.

  Language interface software -- This software is designed specifically for the conventional language programmer. It offers a collection of subroutines or function calls from conventional programming languages such as Pascal, C/C++ and BASIC. Working in one of these languages, users write and compile the code, then link it to language interface software to acquire data from the instrument. Some language interface software includes examples to demonstrate how to use the software with conventional languages. However, users must still know how to program the language in order to make the software work for an application.

Once the data is acquired into memory, users must apply their own programming skills or separate analysis and graphics libraries to process and display the data.

  Add-on tools -- This type of software, which usually consists of files or components that can be added to another application, delivers data-collection capabilities to a familiar development environment. Examples would be add-ins for Microsoft Excel or ActiveX controls for Visual Basic. With a Microsoft Excel add-on tools package, users working in these programs can collect data directly into a spreadsheet for analysis. Some programming is required with this software.

  Virtual instrumentation software -- These packages consist of application development software that allows users to create simple or sophisticated measurement and automation systems. Working with popular development environments, such as National Instruments' LabView or LabWindows/CVI, users can quickly and easily acquire, analyze and display data as well as monitor and control a variety of processes. Virtual instrumentation usually features capabilities for creating a graphical user interface, which can emulate a stand-alone instrument.

However, these packages aren't limited to those applications alone. Unlike traditional instruments, whose functionality are limited to the electronics technology that drives them, virtual instruments leverage their power from low-cost computers with superior processing power and performance. The virtual instrument's functionality is user-defined, which offers the greatest flexibility in application development.

Additionally, most of these packages include easy-to-use Wizards that assist in application development. Wizards streamline data-collection development through automatic, point-and-click program generation. Users simply describe their measurement connections from a list of common options such as analog input or digital input/output. The software generates a ready-to-run program that meets their specifications.

After defining the application's requirements, consider your own capabilities as the application developer and what position you want to take on the Ease of Use vs. Flexibility Curve shown in Figure 1 on page 29. This step lets you narrow your search to a software class. For example, if you have little or no programming experience, then you should rule out language interface software. If the application is simple, you may be able to accomplish it easily with turnkey software. Similarly, if the application requires customized timing and processing, sophisticated control, future modifications or much flexibility, then virtual instrumentation software would more than likely prove your best choice.

Another selection consideration is the diversity of hardware and operating systems you'll be using. Some data-collection software works interchangeably with hardware on varying bus architectures such as PCI, parallel port, PCMCIA and USB. This open architecture capability allows users to develop the application once and apply it to other hardware platforms.

Make sure the software can handle all the data-collection hardware required for the application. Some hardware products are more suited for low-speed, DC-class measurements because they have good stability and can interface to a large number of channels. Some products are more suited for high-speed, AC-class measurements because they have anti-aliasing filters and can transfer data to memory without using the microprocessor's computational bandwidth.

Also keep in mind that a hardware's capability doesn't guarantee the software will work with it, especially if the hardware and software come from different manufacturers. Most data-collection software can perform basic read and write functions for analog, digital and timing  I/O because these functions are easy to write.

With most applications, however, this simple I/O capability is not enough to properly develop the application. It may require double buffering, analog triggering, event-driven messaging or even simultaneous sampling capabilities. These aren't always available in software packages because they require more sophisticated programming on the manufacturer's part.

It also makes sense to ensure the software will run on operating systems you may migrate to in the future.

Microsoft Corp. currently produces the most widely used operating systems for PCs. However, Windows operating systems don't have a real-time architecture, and this can present a challenge in meeting some real-time system requirements. Numerous real-time operating systems are available, including PowerMAX, Phar Lap ETS and VxWorks, but compatible software and hardware choices for these often are limited.

Most data-collection software and hardware is produced for Microsoft operating systems. And while the compatible software might not satisfy fast hard real-time requirements, we only need a soft real-time system to meet the needs of our example. Therefore, the Windows operating system should suffice, but we can ensure this by choosing data-collection hardware to make up for operating system limitations.

The type of data transfer will directly affect the real-time capability of your system. Programmed I/O -- i.e., directly reading from or writing to data registers on the data-collection hardware -- requires the  microprocessor to time and move every data point. This type of transfer capability is very limiting because the microprocessor must move all the data. Consequently, the data-collection system's timing won't be very accurate if the microprocessor must determine when the data transfers take place or work on another task.

With interrupt transfers, dedicated hardware timers can control the timing of the acquisition process but still require the microprocessor to transfer all the data. However, Bus mastering (PCI) and direct memory access allow a data-acquisition plug-in card to stream data continuously to a host computer memory without help from the operating system. The data-collection software simply retrieves data from computer memory and processes it. For compiled data-collection software, this task can be quite fast.

In terms of our real-time example application, we would do well to choose a data-acquisition card that supports DMA. The software would then read in data from computer memory, apply the FFT and graph the data. To view the results in soft real-time only, we must be able to perform this calculation and display the data at a rate between 10-20 Hz. Modern desktop computers should be able to handle these rates, but to be safe, we should make sure the data-collection software is compiled for optimum speed.

A final reminder: Spend time at the beginning of the selection process evaluating the trade-offs of different data-collection software and their manufacturers. This will pay off in the long run by reducing the time it takes to develop your application. If you've narrowed your selection down to a couple of packages but still can't decide, then request a software demonstration package from the manufacturer.

You can easily pinpoint the software that's right for you by keeping these tips in mind. When you know your application needs and your own strengths, you've taken the first step toward the right data-collection software and increased productivity.