Visualizing Data in Real Time

Our authors use Vision, a graphical front end for data display, and Visual Basic to build an application that acquires and displays sensor data from an optical fire detector.


December 01, 1993
URL:http://www.drdobbs.com/embedded-systems/visualizing-data-in-real-time/184409126

Figure 1


Copyright © 1993, Dr. Dobb's Journal

Figure 1


Copyright © 1993, Dr. Dobb's Journal

Figure 2


Copyright © 1993, Dr. Dobb's Journal

Figure 1


Copyright © 1993, Dr. Dobb's Journal

Figure 2


Copyright © 1993, Dr. Dobb's Journal

DEC93: Visualizing Data in Real Time

Visualizing Data in Real Time

A Windows-based front-end tool puts the best face on data acquisition

James F. Farley and Peter D. Varhol

James is a project manager at Armtec/Regan Inc., located in Manchester New Hampshire. Peter is an assistant professor of computer science and mathematics at Rivier College in Nashua, New Hampshire.


One of the last things a data-acquisition engineer wants to worry about is the user interface of the data-acquisition code. This code, frequently written for a single use, is meant to acquire the data, display answers to very specific questions, and save the data for further analysis in a spreadsheet or other analysis package. From the engineer's standpoint, the user interface (UI) is extra work that doesn't relate to answering the real time questions posed by the data flow.

In certain cases, however, someone other than the engineer has to examine the data as it's being produced. For example, the process may be monitored by a technician, or it may be used by a sales or marketing professional to help market a product. In other cases, the engineer may not even be interested in the data itself, but in whether the data stream produces results beyond an acceptable range. The message may be "Alert me only if something unusual happens."

For these uses, it makes sense to put some effort into the UI. This doesn't mean that the engineer has to spend some time with the Windows SDK, however. One solution to such real-time UI problems is Laboratory Technology's Vision, a graphical front end for data display. It includes a collection of graphical plots and instruments for data display, and the ability to create more, if needed.

Vision is deceptively simple to use. Each of the plots and instruments can be manipulated as a whole on the screen. Once they're in the desired positions, double-clicking on them opens up a dialog box in which data parameters can be specified. Since the primary purpose of Vision is to receive and display data, there are few parameters to worry about. Depending upon the type of instrument, you can adjust the range of display values, the reading labels, and in some cases the alarm conditions. Through another mechanism, you also set the DDE links with the server application.

A Graphic Front-end Requirement

The application we built with Vision acquires and displays sensor data from an optical fire detector. The sensors collected data on the ultraviolet and infrared radiation in the surrounding atmosphere, along with the normal background radiation, and determine whether or not a fire exists based on the ratio between the ultraviolet and infrared signals. The determination is pure, rather than fuzzy, because a ratio within a specified region indicates a fire condition, while a ratio outside of that region does not.

The ultraviolet sensor works on the Geiger-Muller principle. A photon of light strikes the high-potential filament of the UV tube, knocking off an electron that is then attracted to the low-potential filament. This causes a momentary conduction within the tube. Whenever a conduction event occurs, it's referred to as a "count," and there is one count per photon release.

The infrared sensor is a thermopile. This solid-state device is made up of two dissimilar materials. When a photon of light strikes the active surface of the IR sensor, a potential is generated between the two materials. This signal, which is proportional to the number of photons striking the thermopile, is then amplified and fed into an analog-to-digital converter. The strength of the signal generated as a result of this process is known as "converter steps."

The sensors are made in such a way (or, put behind filters in the case of the thermopile) that they respond only to specified wavelengths of ultraviolet and infrared radiation. These regions of the electromagnetic spectrum correspond to a hydrocarbon fire signature. The region is centered around 4.3 microns for the IR sensor and 0.22 microns for the UV sensor. This is all necessary to make the fire-detector immune to false-positive signals.

The detector is designed with an embedded microcontroller that gathers data from the sensors and conditions the pulse streams, using the ratio of the pulse streams to determine when a fire exists. The data then can be sent out into the serial port of the computer and either gathered into an ASCII file or displayed in real time on a terminal.

Vision provided the UI for the recorded signals. We selected simple plots for the sensor data, so that we could observe the level of radiation over time, something not always possible to do with a text display. These plots are also alarm enabled; that is, they can be configured to perform an action when the input signal falls within a certain range of values. That was also a part of our goal, so that the user could receive a clear notification that a fire was detected.

Vision cannot access the data stream directly. It is only a graphical front end for another application--a spreadsheet, database, or a data-acquisition program. The package includes an interface for XBase-compatible databases, but the primary method of getting data for display is to communicate with the actual acquisition application via a DDE link. At first glance, this seems unnecessarily complex, but this approach can save an investment in code. If the engineer already has C routines for data acquisition, these routines can be enhanced with the canned DDE routines provided with Borland or Microsoft C, and immediately adapted to work with Vision. The effort needn't begin from scratch, as is often the case with Windows applications.

A sample DDE link is shown if Figure 1. The link is specified by the application name, function name, and variable name. This means, incidentally, that a link can be established between the Vision UI and more than one server application. The Vision front end also uses the OLE Paste Link function, which can display objects that update automatically when the host file is updated. A Net Link function allows you to establish the DDE link from any drive on the network, so that the DDE interface need not be local to a single machine.

Vision is capable of exerting some control over its displays, primarily through the DDE link. It includes glyphs for switches, knobs, and sliders that can be manipulated by the user while the application is running. Signals from these tools can be sent to data-display tools in the Vision application or through a DDE link back to the server program. This is primarily useful for simulating processes rather than displaying actual data.

To round out the UI building facilities, Vision provides basic drawing tools to create lines, text, circles, and polygons, which can be used to improve the overall appearance of the user interface; see Figure 1. They can also be converted into display "hot spots," such as our fire-alarm button, which can then serve as a DDE connection.

The DDE Server

We prototyped the data-acquisition application using Visual Basic. This may seem unusual but it afforded several advantages. First, it enabled us to visually examine our data as we read it into the program. This was not required from the data-display standpoint, but it helped in the debugging process. We also imagined a situation in which an engineer would prefer to view the raw data as it was acquired, as well as examine the graphical plots in Vision. We also did some data manipulation in Visual Basic, mostly in checking the validity of data and computing the ratio between IR and UV signals.

Second, rather than having to manually launch two different applications in order to create the DDE link, Visual Basic lets you start another application from within a running program. We did just that using the RUNAPP call. This meant that the application could be started by a novice user, without starting two separate applications and establishing the appropriate DDE links between them.

We confess that for the prototype, we read the data from a file, rather than from an active data stream. However, this was merely so that the application wouldn't have to be written and tested. After ensuring that this performed as expected, we set to work writing a separate program to read our data from the serial port.

The end result is shown in Figure 2. We plotted the IR and UV signals along with the ratio between them, so that an observer could examine the history of signals leading up to the fire determination. Each of these plots was connected via a DDE link to the Visual Basic program reading the data. As mentioned, the calculations occur in Visual Basic, so that just the resulting ratio is passed into the instrument. This UI also includes a simple "idiot light" icon, whose default color is green. When the ratio signal passes its threshold, the light turns to red. This provides an easy visual verification when a fire is detected.

As we indicated, Visual Basic is an unlikely back end, especially for reading data coming into the computer in real time. After demonstrating to our satisfaction that the DDE interface worked properly, we began work on a C interface to read data directly from the serial port and pump it into Vision, without the intermediate step of displaying it first. This is likely the more common use for this type of front end.

Why Use a Graphical Front-end Package?

There is no facility for real-time process control from a Vision application. However, much of this type of work can be done from the calling application. If, for example, the IR and UV signal ratio were to determine that a fire existed, it would be possible to send a "Fire" signal back to the Visual Basic server application, which could then be used in conjunction with a hardware interface to activate the fire-suppression system.

With the potential for so much to be accomplished in our Visual Basic data-acquisition application, why bother with Vision at all? The answer is that Vision has most of the display tools required to quickly prototype the graphical data display, while in our case we would have to design and write these for Visual Basic separately. Although possible, this reduces the effectiveness of a rapidly prototyped user interface.

If you're using existing C code and adding Vision as the UI, this approach makes more sense than porting the data-acquisition program into a graphical language first. There isn't a good correspondence between a purely procedural language like C and a forms-based language like Visual Basic or even Visual C++.

Further, Vision makes it possible to display separate data signals simultaneously on the same application desktop. Our application establishes three separate DDE links to Visual Basic, and updates all plots at virtually the same time. This isn't possible with most other data-display packages, which either limit you to a single X-axis on a graph, or don't update the graph in real time.

Limitations and Promises

Just about the only problem we had with Vision is a tendency to lose the DDE links between application runs. This wouldn't matter if the data-acquisition process were running continuously, but it could cause a problem when stopping and restarting the application. The example applications provided with Vision didn't exhibit this, and we couldn't find a pattern behind the problem.

Another problem--or perhaps a "feature"--is that Vision doesn't update signals that don't change. The DDE transfer occurs only when the current value differs from the previous one. This certainly saves processor cycles, but in our case, prevented us from viewing a data history within Vision. Anyone using a plot to view data over time should be aware that the plot won't be updated unless the acquired data values change.

The network link means that one computer can be used for real-time data acquisition, and the UI can be displayed on another. This allows for a conceptual and physical separation between the acquisition and display of data. This feature could be even more useful if the Vision front end could alert the user to an alarm condition, even if the front end were iconized on the desktop and the user were actively working in another application. The user could then monitor a process while doing other work.

With the popularity of tools such as PowerBuilder, the concept of software-development packages for building graphical front ends to existing code is becoming more accepted in general. Vision brings such a capability to the real-time data-acquisition world, using client/server technology. By itself, it does little to improve the data-acquisition process. However, working with existing code, or with a DDE-enabled commercial application, it can make creating and using graphical, instrument-based user interfaces a snap.

For More Information

Laboratory Technologies Inc.

400 Research Drive

Wilmington, MA 01887

508-657-5400

Figure 1: A graphical front end with DDE links displayed.

Figure 2: Our fire-detector graphical front end, recording signals over time and warning of a fire.



[LISTING ONE]

Sub FileCommand_Click ()
    FireData.Hide
    FileForm.Caption = "Files"
    FileForm.FIL_Files.Refresh
    FileForm.Show 1
    FireData.Show 0
    ReadData (DataFile)
End Sub

Sub ReadData (FileSpec As String)
    Open FileSpec For Input Access Read As #1
    FileForm.Hide


    While Not EOF(1)
    dummy% = DoEvents()
    Input #1, FileData$
    SpcPos1& = InStr(1, FileData$, " ")    ' Find space.
    RawUV.Text = Format$(Val("&H"+ Left$(FileData$, SpcPos1& - 1)), " ##0")
    SpcPos1& = SpcPos1& + 1
    SpcPos2& = InStr(SpcPos1&, FileData$, " ")    ' Find space.
    RawIR.Text = Format$(Val("&H" + Mid$(FileData$, SpcPos1&,
                                                SpcPos2& - SpcPos1&)), " ##0")
    SpcPos2& = SpcPos2& + 1
    SpcPos1& = SpcPos2&
    SpcPos2& = InStr(SpcPos2&, FileData$, " ")    ' Find space.
    Background.Text = Format$(Val("&H" + Mid$(FileData$, SpcPos1&,
                                                 SpcPos2& - SpcPos1&)), " ##0")
    SpcPos2& = SpcPos2& + 1
    SpcPos1& = SpcPos2&
    SpcPos2& = InStr(SpcPos2&, FileData$, " ")    ' Find space.
    UVLimited.Text = Format$(Val("&H" + Mid$(FileData$, SpcPos1&,
                                                 SpcPos2& - SpcPos1&)), " ##0")
    SpcPos2& = SpcPos2& + 1
    SpcPos1& = SpcPos2&
    SpcPos2& = InStr(SpcPos2&, FileData$, " ")    ' Find space.
    IRLimited.Text = Format$(Val("&H" + Mid$(FileData$, SpcPos1&,
                                      SpcPos2& - SpcPos1&)) / 256, " ##0.0000")
    SpcPos2& = SpcPos2& + 1
    SpcPos1& = SpcPos2&
    SpcPos2& = InStr(SpcPos2&, FileData$, " ")    ' Find space.
    Ratio.Text = Format$(Val("&H" + Mid$(FileData$, SpcPos1&,
                                     SpcPos2& - SpcPos1&)) / 256, " ##0.0000")
    SpcPos2& = SpcPos2& + 1
    SpcPos1& = SpcPos2&
    SpcPos2& = InStr(SpcPos2&, FileData$, " ")    ' Find space.
    FireRegister.Text = Format$(Val("&H" + Mid$(FileData$, SpcPos1&))," ##0")
    Wend
    Close #1
End Sub
Sub Quit_Click ()
    End
End Sub





Copyright © 1993, Dr. Dobb's Journal

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.