Intelligent Systems

SOFTWARE

Data Acquisition Software—
Choices, Choices, Choices

Part 1: Open vs. Closed Architectures, Proprietary Packages, and Programming Language Environments

You have tremendous latitude when you select from the software packages that are now available on the market. The best choice depends on your computer platform, operating system, programming skills, and application type. While some of these items are a matter of personal preference, others are not.

Mark Cejer, Keithley Instruments, Inc.

Since the introduction of Windows 95, the general trend in PC software has been to make computing more accessible through user interfaces that are more graphically oriented and require less in-depth knowledge of application programming. But this philosophy was associated with measurement and control software well before Windows became popular.

Prior to the introduction of the Windows environment, there were two fundamental types of data acquisition (DA) software—open or closed. In the first instance, most DA manufacturers supplied drivers or libraries for their products. This software added hardware control to popular DOS-based programming languages, such as interpreter Basic, compiler Basic, C, and Pascal. These languages were text oriented and presented little more than a command prompt from which you could develop all user interface, hardware control, data manipulation, and display functions.

The programming environment was said to be open for several reasons:

• The program was developed by the end user, who had access to all the code.
• The user was free to distribute or modify the program as needed to provide new features or to operate with different hardware.
• Commercial software developers might also develop software tools that could coexist with and enhance the user’s selected programming language and hardware.

Alternatively, you could opt for a proprietary, closed-architecture package designed to automate hardware control, data manipulation, graphing, analysis, and other functions. Such packages were also DOS applications, but many (if not most) were associated with the concept of “no programming.” Users generated test programs with pull-down menus and fill-in-the-blank forms similar to those currently in use.

Typically, these programming environments were purchased with drivers or libraries that supported a specific manufacturer’s DA products. You might develop application programs to accomplish specific—and even unrelated—goals, but you could encounter limitations because of a lack of control over proprietary aspects of the software. Furthermore, licensing restrictions might prevent a program developed on one computer from being legally shared with other users unless a runtime license was obtained for the other users.

Despite the attraction of no-programming application development, proprietary software still could present serious limitations. For instance, it was usually developed by third parties who didn’t manufacture their own test and measurement hardware. Therefore, software support for new hardware could lag behind the introduction of the hardware by weeks or months, as software developers acquired and learned the operation of the new hardware. Proprietary packages could also be expensive, whereas drivers offered by hardware manufacturers were usually bundled free with the hardware. Perhaps most significant, there was still a learning curve associated with the closed, no-programming software environment. The total cost of software plus effort might still equal that of using an open programming language.

Today, the most common PC operating system is some version of Windows rather than DOS, and the majority of software packages are Windows applications. In fact, there’s probably an entire generation of PC users who have never had to contend with a DOS prompt and all the problems associated with separate drivers for printers, monitors, mice, and other peripherals for each DOS application. All such support issues are now handled under a comprehensive Windows umbrella.

What can a software developer expect today in terms of Windows versions and programming languages on user platforms? There’s a mix of Windows 95, 98, Me, 2000, NT, and XP in the installed base for a variety of reasons, perhaps the most compelling being the adage, “If it’s not broken, don’t fix it.” Justifiably, users can be reluctant to spend time upgrading to a new OS when the old one is adequate.

The most popular DA programming languages are Visual Basic, Visual C/C++, C++Builder, and Delphi. Many test and measurement hardware manufacturers provide Windows-compatible ActiveX controls, Common Object Model (COM) objects, and other programming tools to facilitate program development using these languages.

New proprietary packages have also been introduced, such as National Instruments’ LabVIEW, Agilent (formerly HP) VEE, and Capital Equipment’s TestPoint. Although these programs are similar in scope to the DOS-based no-programming environments discussed earlier, they are Windows applications.

Which Way Do You Go?
The important question remains whether to use a programming language or to select a proprietary package to develop test software. Before considering this question, note that a program development environment may not be needed for a basic application. The start-up software supplied with some DA boards and instruments may be sufficient to satisfy simple test needs. There are also cost-effective, ActiveX-based utilities that can feed data directly into an Excel spreadsheet, where a user can take advantage of sophisticated graphing and analysis tools without having to program the hardware or the display and analysis routines (see Screen 1).

Screen 1. Excel add-in packages, such as ExceLINX, let you acquire and graph data completely within the Excel environment.

Assuming that more elaborate solutions are needed, let’s look at some of the criteria for clues in making a good choice.

The Learning Curve. When choosing between open- and closed-architecture approaches, ease of learning is a matter of concern. While a natural inclination is to assume a closed architecture is easier to learn, this is not necessarily the case. As Windows has evolved into a simpler, more graphical environment, so have the user interfaces of Windows-based programming languages. Furthermore, instrumentation products frequently use ActiveX and COM technology, which can speed and simplify hardware control and other programming tasks in languages by allowing program tools to be recycled. As a result, the look and feel of language-based programming have become much more like proprietary software packages.

Perhaps more important, the effort needed to learn programming, then develop and maintain programs, may be surprisingly similar for open and closed environments over the lifetime of a DA project. Proprietary packages might be quicker to learn, but eventually, you’ll want to do something that the software simply doesn’t support. Although the open environment can require more effort initially, it offers many advantages later, such as higher speed, easier customization, and the promise of expansion, to name a few. User-developed software components often can be recycled for new programming tasks, reducing development time of subsequent projects.

Text-Based vs. Graphical Syntax. The interface a software package presents to the user can be text based or graphical. DOS and DOS-based programming languages (e.g., interpreter Basic) are classic examples of text-based software. Although Visual Basic and Visual C/C++ are graphics intensive, they’re still considered text-based languages because the code behind the graphical user interface (GUI) is written in text format. Windows and Windows-based programming languages provide varying degrees of graphically based software in which objects can be dragged and dropped or processes can be connected by drawing simple lines (wires) from one icon to another.

The issue of choosing between text- or graphics-based software revolves around which method is the most intuitive to learn. The answer is mostly a matter of personal preference. For example, text-based programming has a top-to-bottom organization that is similar to the English language. On the other hand, graphical syntax can be considered more intuitive and easier to remember because it’s based on pictures rather than alphanumeric characters. Also, the wires and icons approach is less susceptible to typing errors and other syntactical errors that can occur in text-based languages.

The top-to-bottom organization of text-based programming is invalid in a graphical language, so there must be another method to establish the order in which instructions are implemented. In the text-based example in Figure 1, C = A + B executes before D = E + F.

Figure 1. Text-based and graphic-based programming require different methods of ensuring that commands execute in the proper order.

The graphical method requires an additional wire connecting both + icons to accomplish the same thing. In LabVIEW, the wire is referred to as artificial data dependency, and its only purpose is to establish the execution order.

Program documentation is another issue to consider when choosing between text- and graphic-based programming. Documentation is more or less automatic in text-based programming because the program can be printed with nonexecuting comments to explain lines of code. In the graphical method, wires and diagrams may be difficult to consolidate on a printed document. This complicates documentation, which may become quite tedious in a long and complicated program.

Programming Efficiency. Program execution speed and response can be important, even critical, to the success of a test and measurement application. Typically, a proprietary programming package adds extra software to a basic DA engine to provide simplicity and automation for the user.

Every current proprietary development package is itself a Windows application, typically written in a C/C++ environment. This architecture places additional software layers between the application software and the hardware. The extra overhead that results can affect the ability of the program to perform satisfactorily in critical applications. This typically shows up as less-than-optimum execution latency, multithreading, and control over thread priority. Although there are Windows tools that can help optimize a program, they may be hidden by additional layers of abstraction in proprietary programming methods.

Another point to consider is that proprietary programs are developed for a broad range of users, so a broad range of functions must be built into the package. At the same time, code must be limited where possible to keep the programming job manageable. As a result, some DA tools or Windows services may be excluded from the software, or the full range of functions available in a given hardware product may not be available. That means the software can have significant limitations or fall short in the future. In contrast, a customized test application developed in an open environment can be limited to only the DA tools and Windows services required for the job, then expanded as needs change.

Windows Messaging and Event Management. Messages and events are the processes by which Windows manages its multitasking system and shares keyboard, mouse, and other resources. This is done by distributing information to applications, application instances, and processes within an application. Typically, proprietary packages don’t use Windows events and messages efficiently. In contrast, events are the fundamental element of the Visual Basic programming environment. For example, consider a DA application running in the background. With event-driven processing, the application can use the CPU for additional tasks, such as database or network access, rather than constantly status-polling to determine if data are ready for collection. When data are available, a device driver notifies the application by sending the proper event or message through Windows.

The tight coordination between data availability and CPU execution means that programs written for event-driven processing are robust and portable across computers of vastly different CPU speeds. If an application was developed with Visual C/C++ and ran successfully on a 100 MHz Intel Pentium processor, it will very likely run on a 433 MHz Celeron processor. This may not be the case for an application developed with a proprietary package, especially if it uses simple, time-sensitive loops or other polling approaches.

Debugging. Efficient debugging is critical to the success of a software development project, and limited debugging tools can increase development time and stall progress. The component-based architecture of today’s open programming systems simplifies software development and debugging. Extensive and powerful debugging tools are available with Visual C/C++ and Visual Basic.

Application Deployment. Application programs are sometimes created by software developers and then distributed to end users. Deployment can be problematic for applications developed with proprietary packages because the user does not have the development package. The difficulty lies in the run-time program that is part of the proprietary layer. Deployment is less of a problem with COM-based applications because the compilers are smaller and more efficient, and the run-time library is usually part of Windows.

Software Development Under Windows
To create a successful system, the interaction between the hardware and software must be well understood, and application programs must be developed for optimum results with them. This task is challenging in the present environment because of rapid changes in PC hardware, operating systems, communications buses, and software development tools.

Preventing problems requires application-development planning based on knowledge of the software structure. These principles will apply to PC-controlled systems using both plug-in boards and stand-alone instruments with GPIB (general-purpose interface bus, also known as IEEE 488), USB (Universal Serial Bus), and other digital communications buses.

Software Structure. Typical automated test application software can be represented as a series of layers (see Figure 2).

Figure 2. The API software structure provides orderly communication and control between the user's application and DA hardware.

In the Windows operating environment, the test application communicates directly with the Application Programming Interface (API) and device drivers to control the test and measurement hardware.

Device Drivers. A device driver is the software interface between a computer’s operating system and any DA plug-in board, GPIB instrument, or communications interface attached to the computer. The driver is the abstraction layer that shields the program developer from the complexities of a hardware device. All the commands to and from the hardware are ultimately executed by device drivers. Therefore, they are key elements in both the development and implementation of test application software.

Let’s examine the role of a driver in more detail. Much like a printer or mouse device driver, a DA driver is essential to the hardware’s operation. It permits communications with the DA device. The PC subsystems that each hardware device needs to use, such as RAM and I/O addresses, are protected by the operating system. A user cannot communicate directly with these subsystems but requires a device driver that acts as a mediator between the test application and the operating system kernel (i.e., a set of operating system programs that implement primary system functions).

This layered architecture provides robustness, portability, maintainability, flexibility, and other features and requirements that computer users demand. Imagine if the operating system didn’t prevent direct access to its sensitive areas, and device users had to write their own protocols to gain access to hardware functions. This would be intolerable. Oddly, the pre-Windows DOS operating system behaved in much this way. Most programs written for DOS included mouse, video, printer, or other specialized drivers designed to work only with that software.

Driver Development. A Windows device driver is written in Microsoft Visual C/C++ and is an extension of the core operating system. A device driver (typically a .SYS file) is executable code that loads in the PC’s RAM. Device drivers receive more attention, flexibility, and full unprotected access to system memory and hardware. As such, device drivers must follow specific rules for interfacing with the rest of the operating system. The Windows Driver Model (WDM) is the latest specification by Microsoft for coding common binary device drivers that are compatible with Windows 98, 2000, and XP.

The multitasking, multithreading, and multiprocessing of today’s PCs further elevate the role of device drivers. A device driver should, at a minimum, handle the most likely multitasking scenarios that could affect operation of its hardware device. A typical PC has many drivers running on it (e.g., video, mouse, printer, keyboard, networking, and disk controllers), so each driver should ideally be designed to coexist with all other drivers, be robust (i.e., crash resistant), and consume a minimum of memory, processing time, and other system resources.

Developing a robust device driver is challenging because of the sensitive interrelationship between it and the operating system, as well as the virtually unlimited variety of multitasking conditions in which it might be used. Developing a good device driver requires intimate knowledge of both the hardware device and the operating system software. Many Windows crashes are due to unpredictable conflicts and malfunctioning device drivers.

Next Time
Part 2 of this article will examine such issues as APIs, the benefits of ActiveX, program timing control, and other hardware-related topics.

SIDEBAR:

What Is ActiveX? An ActiveX control is a self-contained program or component that can be run in an ActiveX-compliant environment, such as a Windows-based application or a program written in a language such as Visual Basic, C, and C++. ActiveX controls make programming a modular, easy process. Instead of being concerned with programming details, the programmer has only to set up the necessary ActiveX properties and execution methods. For example, to graph a trace on screen, the programmer might have to set the number of points and the trace color and then pass the data to the ActiveX control. There’s no need to understand how to deal with screen pixels, connect data points, or draw a bit map for the background.

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.