Seven tools for building data acquisition applications in Windows--without writing a single line of code
Ira Eglowstein
Ask anyone who has written data acquisition or control software from scratch--it's a tedious and time-consuming process. A large acquisition and control application written in C or BASIC could take weeks or months to complete. Imagine building that same solution in hours. That's exactly what graphical programming environments claim to do for data acquisition. A window replaces your text editor, icons replace subroutines, and lines and arrows determine the data flow.
If you're an engineer or scientist who wants to sample signals from a test source or take measurements from an ongoing experiment, perhaps you've been scared away from data acquisition by the thought of learning C or BASIC. Graphical
programming environments also empower nonprogrammers to build data acquisition solutions.
Perhaps you're from the old school and can't imagine developing an application by dragging lines between graphical elements. These environments can work as front ends for your custom code. You may be a wizard with the low-level drivers for your hardware, but you don't want to spend the time writing math functions or graphing routines. These environments support external code or share data with other Windows programs.
Graphical programming environments have other significant advantages, as well. Developing a system with one of these environments takes less time and could save your company a considerable amount of money. Graphical programming may also leave you with applications that are easier to reconfigure as your needs change. Finally, it's harder to make programming errors in a graphical environment because you select actions from a menu instead of typing in keywords and program statements. If the syst
em builds the syntax for you, you're less likely to make syntax errors in programming that can eat up a lot of debugging time.
None of this is to say that graphical programming is going to replace the countless data acquisition libraries available for conventional programming. Graphical environments have their limitations, too.
Acquiring Without Code
This review focuses on seven products: Capital Equipment Corp.'s TestPoint, Data Translation's DT VEE, HEM Data's Snap-Master, Intelligent Instrumentation's Visual Designer, Laboratory Technologies' Notebook, National Instruments' LabView, and Strawberry Tree's WorkBench PC. All run under Microsoft Windows and claim to provide complete data acquisition functionality without requiring you to write a single line of code. For hardware support, these products handle a selection of internal data acquisition boards, and they provide a graphical programming environment and analysis functions to process the acquired data. (One product, DADiSP from DSP Deve
lopment, is not included here because its focus has a subtle but important difference: It's primarily an analysis tool that supports data acquisition through optional modules.)
Programming a data acquisition and control solution in a graphical environment involves selecting icons from a library of iconic functions and arranging them onto a working surface (variously called an instrument or a panel). Each icon has specific setup conditions that are often accessible by double-clicking on the icon once it's been placed. Selecting an input channel from your data acquisition board can be as easy as opening a document from your word processor. Once the icons are in place, you describe the data flow by connecting the icons in some logical fashion. In some products, this connection is visual as well as logical, taking the form of arrows showing the data flow. In other products, the data flow is managed by descriptive action panels.
To better facilitate sharing the data between your data acquisition envi
ronment and your other Windows applications, most of these products support DDE. For example, you might grab a series of acidity readings from a pH meter and, through DDE, channel them to a chemical analysis program for processing. If your application requires producing graphs that are beyond the data acquisition program's capability, you can let Excel grab the data through DDE and display the graph.
Real-World Acquisition
To put these packages to the test, I wanted to use them to reproduce a test system I had developed for Scott Aviation, a division of Figgie International. One of Scott's products is an oxygen regulator used onboard commercial aircraft. The regulator has to control the oxygen flow from a pressurized air supply in response to changes in air pressure. The actual test system presented a few specific challenges that seemed reasonable to present to these data acquisition products.
The oxygen content of an air sample is determined by a dedicated oxygen sensor. The output of this s
ensor is a voltage, proportional to the measured oxygen level. To convert from voltage to the proper reading, you simply multiply the voltage by a constant.
Altitude is a nonlinear function of air pressure: The pressure goes down as the altitude goes up. In the test fixture, a vacuum line lowers the pressure to simulate higher altitudes, and a transducer reads this pressure as a voltage.
Converting the pressure reading into altitude requires the first of two special treatments. There is no linear relationship between air pressure and a given altitude; because of the many different atmospheric layers on the earth's surface and a huge number of variables, the relationship between these two measurements is complex. The best way of performing the conversion is by looking it up in a table; it can also be approximated by a calculation. For this test, I wanted to use a pressure/altitude table from a disk file and have the data acquisition program perform a table lookup.
The other tricky detail i
s to control the simulated test altitude. A motorized valve controls the connection between the vacuum line and a test chamber; the more you open the valve, the lower the pressure in the chamber or the higher the altitude. To open or close the valve, the computer has to generate a pulse of varying width. A wide pulse opens the valve farther; a narrow pulse opens it less. The pulse goes to one of two connections, depending on whether you want to open or close the valve. To determine the pulse width, the actual measurement is compared with what should be happening; larger errors require a larger adjustment to the vacuum valve or a wider (longer) pulse.
For this test, I didn't use the actual laboratory hardware, but a simulation. I installed each package and the required I/O card in a 66-MHz 486DX2 machine with 8 MB of RAM. A second PC was connected to an Interface Systems DataPad unit (an external data acquisition box) that contained both digital and analog I/O cards. Software in the PC controlled output
voltages to simulate varying pressure and oxygen measurements.
The valve-control functions were connected to digital inputs, and software handled the simulation of the valve's position by watching the pulse widths--or at least that was the intent. After spending considerable time with each product, it appeared that none of the products in the review could handle the pulse-width modulation without a substantial amount of work. For those products that support it, linking in an external support routine (written in C or some other language) may be the best approach.
CEC's TestPoint
Programming a TestPoint application is simply a matter of selecting icons from the Stock Objects palette in the upper left corner of the screen. A click, drag, and drop operation moves the object to the Objects list area. When you drop the icon, a Settings menu prompts you for detailed configuration information. The Panel window provides the run-time interface; both input controls and result displays appear within thi
s window.
One feature unique to TestPoint is the Action List (see the screen on page 147), which describes the interconnection and interdependence of the objects. You place items in the Action List by dragging them from the Stock Objects palette and then selecting parameters from a menu. During one of the test runs, I typed a formula into the math object. I ran the test, and error 68 popped up on the screen. It turned out to be a typing error in the formula, but the error message wasn't very helpful.
The test setup in the screen begins by waiting for the manual start button in the Panel window. When you click on the button, TestPoint reads the A/D inputs, applies the math, and graphs the output. Each analog channel is accessed separately in a math object formula; that makes it easy to handle multiple inputs.
TestPoint can use standard Windows DLLs for accessing external code and DDE for sharing data with other Windows applications. Once you've developed a TestPoint application, you can at
tach the run-time environment to it and distribute the result royalty-free as a stand-alone program.
Data Translation's DT VEE
DT VEE's object menu is comprehensive; it seems as if just about any function you could want is represented by an icon. After you've positioned the icons on the screen, it takes only a few clicks of the mouse to interconnect the functions with wires (wire routing is automatic). Clicking the right mouse button on an icon brings up a menu appropriate for that object. Clicking on a shrink button reduces the icon size, making room for a great many objects on-screen at once.
Error handling is excellent. I eliminated one wire from my working application and tried to rerun it. DT VEE gave me an error-message window; I moved that aside so I could see the offending icon (which was outlined in red).
Installing DT VEE was straightforward, except that it wasn't obvious which of the several driver disks contained Windows drivers. It also became obvious that the A/D card I
was using (DT 2835) could not handle automatic sampling at slow data rates. I solved that problem by setting the card for single-sample input and triggering it from a separate timer.
DT VEE is based on Hewlett-Packard's HP VEE for Windows 2.0 (the biggest difference being DT VEE's support for Data Translation boards). Like most of the other packages in this review, DT VEE can share data with other Windows applications through DDE; the documentation discusses only DDE client support. After you've built a DT VEE application, you can run it outside of the development environment through the optional run-time module.
HEM Data's Snap-Master
Snap-Master uses a straightforward approach to building data acquisition and control systems. The elements (icons) are in a column on the left side, with a scroll bar. To use and configure an element, you drag it into the working window and double-click on it to enter any required settings. The screen on page 148 is a sample from my test application; it was tri
vial to get exactly the output I wanted.
HEM provides a single user's manual for Snap-Master. It's quite complete, but I would have appreciated a few more examples. It would also be nice if Snap-Master was a bit more forgiving about input formats. In one case, I typed in an extra space character in a math formula, which caused a run-time error; an extra space shouldn't do that. To perform the table lookup portion of the test setup, HEM suggests using DDE to another application (e.g., Excel) or writing an external module as a DLL.
If you don't need the entire package, you can buy just the modules you want: The data acquisition module (SM-DA), general analysis module (SM-GA), frequency analysis module (SM-FA), and programmer's toolkit (SM-PT) are available separately. Version 3.0 may be out by the time you read this, and it should contain HEM's data gateway module (a user programming aid) as well.
Intelligent Instrumentation's Visual Designer
Visual Designer menus make good use of cascad
ing daughter menus to simplify the menu structure. Selecting a block (icon) from the menu brings up an additional option menu.
With Visual Designer, all the input channels on an acquisition card are lumped together into an array. To use one of several channels from a card, you have to wire the array output into an unpacking block to separate the channels. The screen on page 149 shows a simple application of this procedure. Note that unlike the other packages, Visual Designer cannot display data sets as x, y graphs.
Visual Designer has good error handling and provides a run-time module ($150 per copy, but Intelligent Instrumentation includes the license free if you use its hardware). Version 1.0 supports DDE only as a server, but version 2.0 should be out by the time you read this and should support DDE as both a server and a client.
Labtech's Notebook
When starting up Notebook, you choose either the build-time or the run-time module. The build-time module provides the environment for c
reating or editing an acquisition application; the run-time module executes your applications.
Notebook is unique in that each A/D channel is shown as a separate icon and has separate scaling capabilities. In my example, this approach reduced the number of icons required to set up the test scenario.
You access each icon's specification table simply by double-clicking on the icon and entering the parameters. Connecting icons (for data flow) is a relatively simple click-and-drag operation. Hardware support is excellent, too--Notebook includes Labtech's Universal Driver, which handles hundreds of I/O cards.
I found it odd that you have to enter Notebook's general menu through the LT icon (a stylized version of Labtech's logo) instead of through a pull-down menu. I also thought that I didn't have proper control of the application names when saving files. When using the run-time module, I would have liked to have the name of the application shown on the screen.
To solve complex math fu
nctions, the company suggests using the CAL(X) (or calculated function) icon, writing a function in C and using the C icon, or using other Windows products and DDE transfers. A stand-alone run-time module can be used to run finished applications. A separate product, Realtime Vision, can add graphical sliders, knobs, and displays and link them to your Notebook application through DDE.
The only serious problem I ran into when executing the test procedure was in scaling the x- and y-axes on x, y plots. I wanted the y scale to run from 1.0 to 2.5 with tick increments of 0.25, but Notebook displays axis scales only as integers (Labtech is planning to change this in the next release). The workaround was to scale the input and graph by 100 (see the screen on page 149).
National Instruments' LabView
LabView uses a graphical programming language, G, to create programs in block diagram form called virtual instruments (VIs for short). The program splits your development between two windows. The first is
a user-interface panel with controls and display outputs; the second is a diagram of VIs that combine to build your application.
A typical data acquisition and control problem would involve several instruments. LabView has the unique ability to embed several VIs into a single hierarchical VI. You can then use this VI to build more complex systems. This grouping makes it easier to build sophisticated systems without getting bogged down in an endless mire of icons and wires.
The LabView environment is quite complex, as evidenced by the number of manuals (nine) accompanying the software and the customer training sessions available from National Instruments. To get started faster, I grabbed bits and pieces of applications from the sample solutions and modified them to solve my test problem. The learning curve is steep; I had to call the company's technical support to finish the test. The screens on page 150 illustrate the power and complexity of LabView.
Analog signals (from the A/D channels
) are piped as combined data arrays. I wanted to multiply one channel by a constant, so I sent the signal into Index Array icons for separation, performed the multiplication, and then rebundled the arrays so they could be piped to the display. The panel and diagram are intimately linked; modifying the diagram also modifies the panel.
I wasn't happy with the x, y graph output. The graph doesn't update until the entire acquisition cycle is complete. In my test, I had slow-moving data that took 5 minutes to acquire, and I had to wait the full 5 minutes to see whether the result was what I expected.
When I asked about implementing the table lookup, the company suggested that I look through its analysis reference manual or implement the lookup through DDE. The manual offered a vast array of functions, but none would obviously solve my problem. I would need to spend a lot more time working with LabView before I could claim any real expertise. National Instruments understands this need--the company off
ers a one-week training course for new LabView users.
Strawberry Tree's WorkBench PC
You can rapidly develop WorkBench PC applications by selecting modules from a palette on the left side of the screen and filling in any necessary details in a dialog box. Each module represents a single process and can contain support for multiple I/O channels. The I/O channels are clearly indicated on the module icon. Interconnections between the modules appear as colored wires. You connect modules by clicking on one module's output and clicking on another's input. Taken as a group, these features make using WorkBench fairly intuitive and contribute to the product's short learning curve.
I tested WorkBench with one of Strawberry Tree's ACjr A/D cards, an eight-channel, 12-bit card with 12 digital I/O lines. The card can be set to a selected range of I/O addresses and one of two interrupts. The ACjr refused to work in my 486/66; the software complained about a bad interrupt line. Strawberry Tree's technical s
upport agreed that something strange was happening and sent me a replacement card installed in another machine.
Part of the test requires displaying two data sets against each other on an x, y graph. WorkBench had no trouble displaying other kinds of graphs, but the x, y plot caused WorkBench to crash with a floating-point error.
I was also disappointed with WorkBench's inconsistent use of labels. Some modules allow you to name the display windows; others do not. Strawberry Tree is looking into the problem.
In spite of its failure to complete the testing, WorkBench is worth knowing about. I'm looking forward to seeing if the next release fixes some of the problems.
Icons or Code?
It's refreshing to see that data acquisition software has moved into the Windows environment so effectively. While it can be argued that programmers working with conventional languages and I/O libraries may have more control over the acquisition process, not everyone who needs acquisition knows how to w
rite code or wants to spend the time to do it. All these products do a good job of making data acquisition solutions easier for nonprogrammers to implement; one product may be more suitable than others for some applications.
First off, make sure the product supports the I/O hardware you need to use. Vendors that manufacture both hardware and software may not support anyone else's hardware. Labtech's Notebook is a clear standout in this respect: Its universal device driver supports hundreds of boards from dozens of vendors. HEM's Snap-Master and CEC's TestPoint also have excellent hardware support.
You also want to be sure that the functions provided in the package can perform the analysis you need. A number of the packages reviewed here are scheduled for updates; a call to the company's technical-support or sales number can probably tell you if a new version of the software can fill in a missing function.
If you can make a choice based purely on the software, National Instruments' LabView
appears to do just about anything you might ever want done--once you've invested the time to learn it. If you would rather break open the shrink-wrap and get up and running within hours, DT VEE, Snap-Master, and WorkBench PC are your best bets.
The acquisition and control problems I need to address often have enough wrinkles in them that I'll still be relying on BASIC or C for custom code. I do like the idea of incorporating Windows into my solutions, and I'm looking forward to spending more time with Snap-Master. Windows may not be the ideal environment for every data acquisition solution, but for many of them, it's better than you might think. It's also a lot of fun.
The Facts
DT VEE 1.01 $1995
run-time only $495
Data Translation, Inc.
100 Locke Dr.
Marlborough, MA 01752
(800) 525-8528
(508) 481-3700
fax: 508-481-0627
LabView 3.0 for Windows
(full development package) $1995
National Instruments
6504 Bridge Poin
t Pkwy.
Austin, TX 78730
(800) 433-3488
(512) 794-0100
Notebook for Windows 7.3.0 $995
run-time only $495
Laboratory Technologies
400 Research Dr.
Wilmington, MA 01887
(800) 879-5228
(508) 657-5400
fax: (508) 658-9972
Snap-Master 2.0a
SM-DA $995
SM-GA $495
SM-FA $495
SM-PT $495
HEM Data Corp.
17336 12 Mile Rd.
Southfield, MI 48076
(800) 436-4330
(810) 559-5607
fax: (810) 559-8008
TestPoint 1.1 $995
Capital Equipment Corp.
76 Blanchard Rd.
Burlington, MA 01803
(800) 234-4232
(617) 273-1818
fax: (617) 273-9057
Visual Designer 1.0 $995
version 2.0 $595 until 7/31/94
optional Custom Block Toolkit $795
Intelligent Instrumentation
6550 South Bay Colony Dr., MS130
Tucson, AZ 85706
(800) 685-9911
(602) 573-3504
fax: (602) 573-0522
WorkBench PC 1.5
extended edition
$1245
base edition $995
DLL toolkit $395
run-time only $330
Strawberry Tree
160 South Wolfe Rd.
Sunnyvale, CA 94086
(800) 736-8810
(408) 736-8800
fax: (408) 736-1041
Illustration: Math functions in CEC's TestPoint allow you to enter any function by typing in a formula. The Action List window describes the data flow from the A/D converter to the display graph and then to a disk file.
Illustration: DT VEE's screen objects have detailed descriptions of their functions. In this view, the application icons were reduced to conserve space. Although DT VEE labels the axes on graphs, it doesn't label the ticks along the axes.
Illustration: Snap-Master's displays are clear and easy to read. Data flows from step to step through pipes; arrows indicate the data-flow direction. Of the products included, Snap-Master's graphics are second to none.
Illustration: Visual Designe
r doesn't support x, y plots and was unable to perform the display portion of the test. The AnalogInput icon controls two A/D channels, which must be broken apart using the Unpack module before displaying the data in digital panel meters.
Illustration: Labtech's Notebook uses separate icons for each input channel. This makes it easy to control the flow of data, but it can be confusing if you have lots of active input channels. The x, y plotting function doesn't support labels or noninteger axis numbers. In this graph, the y-axis values are multiplied by 100 to make all the digits visible.
Illustration: LabView's user interface, with the device configuration data (number of channels, scan rate, and number of scans) and a sample x, y output. Although LabView labeled the graph, it didn't indicate which axis was which (the y-axis is oxygen, and the x-axis is altitude).
Illustration: To generate the data for the graph in the previous screen, LabView first
reads from the AI (analog input). If an error occurs, control transfers to the Clear and Error VIs (virtual instruments). The normal data path separates the signal array (channels 0 and 1 of the AI), multiplies channel 0 by 8000, and recombines the array data for the x, y plot.
Illustration: A WorkBench PC worksheet, set up to acquire two channels of data, multiply channel 0 by a constant, generate an x, y plot, and store the data to disk. The graph is empty because running this worksheet caused a run-time error.
Ira Eglowstein has been designing custom data acquisition hardware and software systems since 1973. His company, Interface Systems (Williamsville, NY), integrates data acquisition solutions into a variety of applications (it did the mechanical design and assembly for BYTE's battery-test station, Thumper 2). He can be reached on the Internet at
ah789@freenet.buffalo.edu
or on BIX c/o "editor."
Friendly Acquisition
