Data-acquisition systems are built by all kinds of companies, especially those in the sensor industry. Some of these systems are destined for more or less permanent use, long-term experiments, or as permanent parts of continuing systems. Most, however, are short-lived, very specific, and designed for whatever acquisition boards and/or instruments happen to be on-hand.
This can result in a lot of code being written, largely by people not trained as programmers, since different data is needed each time around. One common solution is to write the code in Basic, because it's often the first (and sometimes only) programming language learned by many engineers. These routines can do the job, but they're sometimes hard to maintain and, more often than not, wordy. Recently, some data-acquisition systems have begun to include C routines, forcing engineers to begin coming to grips with this language. This approach is somewhat better, in that it leads to the development of general, reusable procedures. (We develop data-acquisition systems using a Forth-based language, which has a lot of canned routines for rapid prototyping.)
These approaches to data acquisition might be termed "quick-and-dirty," in that they're often developed using brute-force techniques in very little time. As most engineers know, however, this approach can result in the most time-consuming and error-prone systems imaginable. Further, such systems don't provide easy access to all of your data. Many engineers will write data out to a text file, and then load the text file into a spreadsheet for analysis. This, too, is time consuming, and can result in analyses not being performed--and in opportunities lost by not seeing the data as it is produced.
If you're used to any one of these methods, using LabView for Windows for the first time is a revelation. With LabView, there's no code to write; applications are written by manipulating icons in a window. LabView is based on a graphical programming language National Instruments calls "G." For engineers used to controlling instruments with code, this approach takes some getting used to. After some acclimation, however, both permanent and quick-and-dirty applications are easy to build.
Our goal was to build a prototype data-acquisition system to collect data on infrared sensors. These IR sensors are to be used in an optical fire-detection system that uses infrared and ultraviolet radiation to determine if a fire exists, then sound an alarm if it does--all in less than a second. In our project, four IR sensors were attached to amplifiers and shown fires (produced primarily with gasoline and jet fuel) of various sizes and distances from the sensors.
The data we collected helps determine the suitability of the IR sensor as well as helping us make hardware decisions on the amplifier circuit attached to the sensor. The amplifier is a necessary part of the design because the sensor puts out microvolt signals, which must be increased to be useful to the rest of the system. The data will also be used to help generate the embedded algorithm since the fire detector will be microprocessor controlled.
Our data-acquisition hardware was a National Instruments AT-MIO-16F-5 board. This board has many features, including digital I/O, analog-to-digital converters, counter times, and digital-to-analog converters. In our project, we used only the analog-to-digital converters, since we were inputting analog signals and converting them to digital for display. Our test machine was a 486/33 PC with 8 Mbytes of RAM running Windows 3.1.
The data is displayed on a multiplot graph--one plot for each channel. We have to give the user the ability to change both the number of samples per second as well as the total number of samples recorded. The graphs will have a range from 0 to 5 volts DC, corresponding to the output of the IR sensors, as amplified. In addition, our application includes simple statistical functions (mean, minimum, and maximum signals, for example) as well as the time to the highest signal peak.
LabView for Windows is a graphical programming system for data acquisition and analysis. Working with a graphical programming language is very different from traditional programming languages, in that developing an application is closer to how an engineer thinks about the problem, rather than how the process itself works. Further, design and development turn out to be the same process. Once the icons representing the desired processes have been selected and properly connected, you've completed building the application.
The downside is that programming in this language requires strict adherence to the inputs of the icons. Each icon is required to have exactly the right inputs in exactly the right spot on the icon. Fortunately, these inputs are detailed not only in the manuals, but are available on screen and can be displayed on-the-fly. Even well into the application, we often obtained the "bad connector" indication simply because the output from one process didn't match the input of another. LabView performs limited type coercions, but has several complex structures (we're still not sure what a "cluster" is) that do not lend themselves well to automatic coercion.
LabView applications are split into two screens. The first is the panel screen, which shows the user interface, controls, and displays. The other is the diagram screen, in which each item on the panel is displayed as an icon on the diagram window. Function icons are also added to the diagram window and wired to the control and indicator icons to build the application. These wires are color coded on the screen to indicate what kind of data is being sent from one icon to the other. (By all means, use a color monitor with LabView.) Function icons can be simple routines or full blown applications.
When writing on-the-fly acquisition applications, you usually start with the data-acquisition engine. However, after using LabView for a while we came to the opposite conclusion--it seems best to program in the opposite direction. In other words, LabView invites you to create the user interface first, starting with a blank window that prompts you to determine what data should be displayed and how to display it.
This is an important distinction between LabView and traditional data-acquisition approaches. Engineers normally don't expect to see data as it is being produced, and therefore don't give a lot of thought as to how best to view and analyze the data until the very end. In LabView, the data display and analysis is the most important part of the application, and the details of hardware interface are largely hidden.
Our first step, then, was to concentrate on displaying the data on the screen. In traditional data-acquisition applications, you typically display some little piece of the data in text form on the screen to ensure that the machine has not locked up. All the rest of the data is dumped to a text file on disk to be reviewed later using some commercial software package. The reason for this approach is simple: Why spend the time writing complicated graphing and analysis routines when a spreadsheet or statistical package will work just as well? Granted, with this approach you miss the opportunity to analyze the data in real time, and perhaps adjust the hardware while the data is still flowing, but writing graphics drivers is too much trouble.
Not with a LabView application, however. When you use LabView, you'll probably start with the data display and acquisition controls which consists of a rich assortment of knobs, switches, slides, buttons, text strings, and graphs that can be used as controls or as indicators. Once you've picked how you want to control your system and display your data, you can start working on the engine.
Figure 1 shows our application's user interface. We used knobs and switches to control acquisition through the hardware, and graphs and digital indicators to display data. We confess that, while we started using LabView by playing with graphical user interface objects, we then experimented with the hardware interface before returning to complete the user interface. This was due largely to our inexperience with the product, however. In future development efforts, we'll probably complete the user interface before working on the application internals.
From this point, the rest of the application is anticlimactic. Using the graphic description language, we diagrammed primitive routines to control the instruments, as illustrated in Figure 2. Although LabView supplies rudimentary controls for the data-acquisition board, we found that a higher block included with the software and identified as "AI Waveforms" works just fine for our application.
Figure 3 shows a diagram of the internals of this icon block. Its canned routines have the error handlers built right in as well as initialization and set-up features. Using this block to shield us from the hardware, we merely built our own custom diagrams on top of them. Then it was a simple matter to have the LabView engine call those routines to collect the data, keeping in mind how you would like to handle direct memory access, initialization, errors, and the like.
One of the most valuable benefits of LabView is that it lends itself to on-the-fly reconfiguration. For example, let's say that after observing a process for a while, you want to calculate the moving average of the data and plot it next to the actual read-out. This change can be made in the space of minutes with LabView, and the data-collection process can resume with the new statistic within a short period of time. Using the traditional approach, modifying the code could result in delays of hours or even days, and may require the services of a programmer.
LabView also lets you observe and analyze data over long periods of time, since the data need not be saved after it is viewed. Collecting it in a text file and analyzing it in a spreadsheet, on the other hand, means that you either take widely spaced samples, or view a short time period. There is no such limitation with LabView.
We won't whitewash the process of building our first application. It took over a month of part-time tinkering, experimenting, and redesigning before we completed a working data-acquisition application. However, much of this time can be attributed to the learning curve inherent in a complex application, false starts, and the testing of different approaches. After almost completing the application, we decided to redesign the user interface from scratch. At that point, we knew LabView well enough to accomplish this task in a few hours. With a little experience under our belts, we are confident that we can produce effective and highly visual data-acquisition applications using LabView in a few days.
LabView lets you compile the completed application into a stand-alone executable, enabling you to use it to perform permanent data-acquisition tasks. It is also possible to incorporate your own external C routines into an application. These features suggest many exciting possibilities to us.
For example, we can add some intelligent decision -making capacity as external code, perhaps using the neural-net approach we presented in "Neural Nets for Predicting Behavior" (DDJ, February 1993). This neural-network development tool generates C code from a trained network, making it possible to feed our data into the network and create external code that can recognize patterns and make decisions based on real-time data.
Combining LabView's flexible and highly graphical approach to data acquisition and monitoring with a decision-making neural network could produce a PC-based system to acquire and display data in real time, then make process-control decisions. This, in fact, is our next step in the process. With the proper feedback mechanisms, it is possible to use a LabView application as part of a completely automated process.
Another enhancement is to incorporate the LabView application with a touchscreen, so that it can be controlled from a factory floor, without the use of a keyboard. To this end, we included as a part of our application the Touchmate from Visage, which uses straingauge technology to turn any monitor into a touchscreen. The monitor simply sits on the flat unit and translates the force of a touch into a Windows mouse movement or click. LabView's controls are large and simple enough so that a properly designed application can be controlled entirely by touch.
Data is the lifeblood of scientific computing. When that data must be displayed and analyzed in real time, Lab-View is a superb tool for rapidly prototyping a graphical data-acquisition application, perhaps cutting weeks off of the R&D process. It can also go beyond that use, to help create a complete process-control system that involves real-time data acquisition and analysis. Either way, sophisticated software tools such as LabView make the life of an engineer much easier than it used to be.
Copyright © 1993, Dr. Dobb's Journal