Intelligent Systems

SOFTWARE

Data Acquisition Software—
Choices, Choices, Choices

Part 2: Application Programming Interfaces, ActiveX, Program Timing Control, and Other Hardware-Related Topics

Software is the engine that's driving data acquisition systems. The trick is to squeeze as much juice as possible out of this resource.

Mark Cejer, Keithley Instruments, Inc.

The replacement of DOS by Windows, plus today’s increasingly complex test systems, have placed greater demands on data acquisition (DA) software and its development. Under DOS, programming a DA device was relatively easy. Multitasking didn’t exist. Typically, only one program at a time could take control of the computer, and it could engage in just one task at a time. DA equipment vendors usually provided extensions to popular programming languages (e.g., C, Pascal, and Basic) that added commands to control hardware and deal with data. Where this support wasn’t provided, you could still access the corresponding memory and I/O addresses with relatively simple commands, such as inp and outp in C, or peek and poke in Basic. Users sometimes resorted to simple for-next counters for timing that, although sensitive to processor speed, could provide reasonably consistent results on a given computer because the program didn’t share any system resources.

One big disadvantage was that each DOS application not only had to include DA drivers but also specialized drivers for the peripherals it might be used with (e.g., printer, mouse, and video). So, programmers and developers had to write drivers for a variety of hardware—not just their own products.

With the multitasking paradigm of Windows, Microsoft had to establish a new set of rules for managing communications with peripheral devices, as well as the timing of program execution. In most cases, programmers no longer need to develop drivers for peripherals and other generic system resources because they’re included in Windows or supplied by the hardware and software manufacturers. This lets programmers concentrate on the development of drivers for their own test hardware.

A Windows driver is no longer a single .exe file that’s loaded in memory or copied to a special directory. Rather, a typical Windows application consists of many files—such as .inf, .sys, .vxd, .exe, and .lib files—that require a specific installation process. Such installations might also include modification of the Windows registry, implementation of plug and play, alteration of the power management setup, or specialized resource management.

The installation process isn’t just a matter of copying files to a hard drive; it’s performed according to an algorithm that must be tailored to each version of Windows. Moreover, when Windows is upgraded from one version to another, the upgrade can easily create compatibility problems with previously installed device drivers. While everyone expects developers to upgrade these drivers, the process sometimes lags behind the introduction of new Windows versions. Furthermore, developers may fail to plan for all possible contingencies among all user machines and be faced with additional updates as problems are uncovered.

Under Windows, a test and measurement application might simultaneously acquire data from multiple devices, control a time-sensitive process, graph data, save data to a database, and make them available on the Internet. Windows is a message-driven, event-polling system with nonpreemptive scheduling, which means that it can’t guarantee interrupt response times. A time-critical application that encounters long or unpredictable delays might fail. Tests such as the one described above impose more demands on device drivers and other system resources and can make it increasingly difficult to achieve precise timing.

The Application Programming Interface
The application programming interface (API) simplifies common tasks that the software must perform with hardware and makes communication between the device driver and the test application transparent. The API acts as liaison between the device driver and the test application, so end users rarely have to communicate directly with a device. Therefore, it’s important for a driver developer to know how users will program or configure the hardware before building the driver foundation under the API.

Typically, the API is part of the driver package and should be designed first when a device driver is developed. The ActiveX control interface is an example of an API that plays a significant role in simplifying development of test programs for DA and other applications. Other types of APIs include Component Object Model (COM) objects, dynamic link libraries, and support modules for Visual Basic, Visual C/C++, and other programming languages.

The API can be an important component in obtaining results from a test application. For example, streaming digital data to disk at 100,000 sps requires high-speed DA hardware and API tools that can transfer data quickly and efficiently to disk. Similarly, accurate logging of temperature data requires not only good measurement techniques and cold junction sensors but also a cold junction compensation algorithm in the API. Ideally, the driver software will automatically support all necessary hardware features. However, developers and end users should pay close attention to the features and limitations offered by a given API.

Hardware Independence
Hardware independence is an important feature of the ActiveX API because it can increase the longevity of test application software. Given the fast-paced change of PC technology and the frequent obsolescence of data communications hardware, it’s also a critical cost issue.

For example, consider how quickly the transition from RS-232 to USB and FireWire is occurring. The degree of portability of an API helps determine whether the software will have to be rewritten with every hardware upgrade.

ActiveX Controls
Although a device driver must change with a significant hardware change, the API that the user sees doesn’t have to change, especially if it’s based on ActiveX.

ActiveX is a set of rules governing how different applications or software components interact and share information in the Windows environment. Developers have been shifting rapidly to component-based software architectures, so ActiveX controls are among the most important features in an API.

An ActiveX control (formerly known as an OLE or OCX control) is a user interface element that takes advantage of the standards for information exchange and functional modularity among Windows-based applications. ActiveX controls are based on COM technology, a software architecture that allows applications to be built from software components. This technology provides many benefits, including easier integration, scalability, and reusability, as well as language independence, cross-platform compatibility, and context-sensitive help.

A major benefit of ActiveX is its use of a single, simple object to replace many lines of code for common functions. This lets programmers create reusable software components that can be interchanged without the need to rewrite entire applications. Interchangeability reduces development cost and extends the life of an application.

Figure 3. ActiveX1 acquires data from the measurement device, ActiveX2 performs the analysis, and ActiveX3 graphs the data. The code shows the simplicity of programming with ActiveX controls. In this component-based open architecture model, each of the ActiveX controls is an independent entity, which could be supplied by more than one vendor.

For example, an application originally written for a 16-channel 100 kHz analog I/O board could be used with a 64-channel 300 kHz analog I/O board simply by replacing an ActiveX control that describes the characteristics and functionality of the DA device. Figure 3 shows a snippet of code that uses three different ActiveX controls. (The figures in Part 2 are numbered consecutively from those in Part 1.) ActiveX1 acquires the data from the measurement device, ActiveX2 performs the analysis, and ActiveX3 graphs the data.

The code shows the simplicity of programming with ActiveX controls. In this component-based open architecture model, each of the ActiveX controls is an independent entity, which could be supplied by more than one vendor.

Test and measurement manufacturers and third parties have developed thousands of ActiveX controls, which strongly support and benefit open architecture software systems. These properties of ActiveX and its underlying model protect your software investment by making applications more portable and by simplifying hardware upgrades. While it’s natural for a given test and measurement vendor to maintain the same driver interface and syntax across all its hardware and languages, software reusability is particularly challenging when using multiple vendors.

FIFO Buffer Overruns
A first-in, first-out (FIFO) buffer is a temporary memory block found on most DA devices. FIFO memory can serve as the onboard memory where data are stored before being retrieved by the device driver. When a sample is read out of a FIFO buffer, its space can be reused by incoming data. To make data streaming more efficient, the buffer typically asserts an interrupt when it’s half full, signaling the device driver that it’s time to retrieve the data. At that point, the driver launches an Interrupt Service Routine (ISR) to read the data and wait for the next interrupt.

Figure 4. FIFO buffers provide high-speed temporary data storage that compensates for the relative slowness and inconsistent speed of data acquisition buses.

FIFO buffers compensate for software and operating system latency to help prevent loss of data. For example, when a program streams data to a hard drive, the FIFO buffer helps keep sequential data contiguous while the application writes it to disk (see Figure 4). During this process, there’s a race between the data intake and data output read by the device driver. Ideally, to avoid a buffer overflow, the data-out speed should be faster than the data-in speed. If the buffer fills up faster than the driver can retrieve its output, a buffer overflow error occurs. Incoming data have no place to be stored, so it is lost.

The Role of DMA
Direct memory access (DMA) is a means of performing I/O without involving the computer’s CPU. Bypassing the CPU permits direct data transfer from the DA device to memory and results in greater throughput.

During a DMA transfer, the CPU can perform other tasks without affecting data transfer speed. Typically, the DA device transfers a complete set of data to the computer by initiating multiple 64 KB DMA transactions. At the end of each transaction, the device driver generates an ISR and handles the ensuing process. The DA device can chain multiple DMA transactions, making the process even more efficient by reducing the number of ISRs.

There are two styles of DMA design. Bus master DMA is used with the PCI bus, and system DMA is used with the ISA bus. With bus master DMA, the PCI board contains all the control circuitry necessary to initiate a DMA transfer. With system DMA, the support circuitry resides on the motherboard and is shared among all ISA peripherals. Bus master DMA is more efficient than system DMA, and the PCI bus operates at a higher data transfer rate than the older ISA bus. In either case, DMA requires critical coordination between hardware and software. The hardware must have the proper circuitry, and the software must implement the proper procedures for successful DMA operation.

Polled vs. Event-Driven Control
In a polled system, the computer checks many devices to see if they’re ready to send or receive data. In the context of a DA system, this typically involves reading or writing a single value from or to a data I/O channel. In a Windows-based PC, the operating system schedules the time between polled readings, so it’s not deterministic. In other words, the time at which Windows will initiate an operation cannot be known precisely. Its operation depends on a number of system factors, such as computer speed, operating system, programming language, and code optimization.

By way of comparison, a deterministic DA system is one that collects data having discrete values and direct cause-and-effect relationships with the physical phenomena they represent. This implies a strong time relationship between the data and the underlying phenomena.

Typically, DA running in the background, using DMA- and ISR-driven operations, is under the control of the DA hardware. The hardware notifies the user’s application when the task is complete. The time between background readings is clocked by the DA hardware and is independent of Windows timing.

During a background data transfer, the DA hardware interrupts the CPU. The driver handles the interrupts by transferring data into application memory space. When the requested background operation is finished, the driver posts a Windows message or event to the application, which responds to the event and manipulates the data. Windows uses events and messaging to distribute information to applications and processes within an application, thereby managing its multitasking system. Event-driven programs result in a more deterministic system.

It’s easy to program an application that uses polling. Polling can be appropriate with slower, non-time-sensitive operations, such as programming discrete steps in a power supply’s output or reading precise voltages from a nanovoltmeter.

Trying to squeeze high speed out of a polled application will probably lead to unacceptable results. In applications that use high-speed DA boards for faster sampling rates, event-driven programming is advised. Event-driven programming schemes are less dependent on operating system timing, reducing latency problems.

Tight Control
A programmer can take advantage of Windows events and messaging by using Visual C/C++ and Visual Basic programming tools to create a deterministic application that runs fast and provides tight control. Rather than constantly status polling to determine if data are ready for collection, such programs can use the CPU for additional tasks (e.g., database or network access) until interrupted by the DA hardware.

This tight coordination between data availability and CPU execution also makes event-driven applications more robust and portable across computers of vastly different CPU speeds. The hardware deployed for real-time applications in Windows is important. Event-driven programming may be necessary but is not necessarily sufficient for some real-time applications.

Contrary to what the words might indicate, real time tends to be a relative term, the meaning of which varies with the application and user requirements. In some applications, users consider a response time of 100 ms to be a real-time response. In a different setting, a 1 ms response might be needed. The Windows operating system—whether it’s Windows 95, 98, Me, NT, or 2000—isn’t well suited for fast, real-time applications.

Real-time applications tend to work better with dedicated operating systems running on embedded processors. This implies instrument or DA hardware equipped with a digital signal processor (DSP) or microprocessor. The DSP or onboard processor performs many of the functions that would otherwise be performed by the computer’s CPU.

The dedicated-DSP or -CPU approach eliminates problems associated with Windows running tasks in the background that aren’t under a user’s control. These background tasks use up CPU clocks and interrupt requests, so the test application must share system resources. Some applications actually perform better when programmed and run on a DOS system, particularly if the hardware and software are designed around the operating system.

The design of every operating system (e.g., Windows, DOS, and Linux) attempts to balance conflicting demands but tends to be optimized for certain types of tasks. A test system developer must weigh these tradeoffs. The ultimate selection will invariably involve compromises between flexibility, functionality, ease of use, robustness, and reliability.

Managing Speed and Accuracy Tradeoffs
Throughput is an issue in most production test applications, so a developer must look for programming techniques that speed up processing and maintain accuracy. In particular, the programmer should avoid an error that can occur when using a PC that is faster than the instruments attached to it. In this situation, the user can get a false sense that the system is faster than it actually is, which can lead to inaccurate test results. The problem arises because the application software outpaces the hardware. Sometimes, the hardware driver package will take care of these timing issues; in other cases, the user must adjust the application program as outlined in the following example.

In a typical production calibration system, the application program commands the calibrator to apply a certain voltage stimulus to the device under test (DUT) before measuring its response. Both the calibrator and DUT need a certain amount of time, often seconds, to settle to the required state (stimulus or response) before the program commands a measurement. If that amount of time isn’t accounted for in the program, the calibration process will be inaccurate.

Typically, programmers hard-code wait times, so this isn’t an issue. But in production tests where throughput is critical, there’s a downside: the wait time can be longer than is actually needed. Rather than hard-coding a specific wait time, the programmer can create an algorithm that uses feedback from a calibrator (an instrument-ready bit) to acknowledge that the stimulus voltage level has been reached. This means the program can proceed to the DUT response measurement. The measuring instrument can provide a similar signal after it’s acquired the data following a delay, based on its own internal program. This type of programming approach results in higher production rates.

For further reading on this and related topics, see these Sensors articles. "An Argument for Open Source Software," January 2002 "Data Acquisition Software: Today and Tomorrow," March 1999 "Making Ethernet Work: The Software Behind Successful Data Acquisition," February 1999 DA Special "The Changing Role of Software," March 1998

Home | Contact Us | Advertise © 2009 Questex Media Group, Inc.. All rights reserved. Reproduction in whole or in part is prohibited. Please send any technical comments or questions to our webmaster.