[ Home ] [ Products ] [ Data Sheets ] [ Support ] [ FAQ ] [ Sales Offices ] [ Request Catalog ] [ Contact duTec ]
data display and unit conversions are extremely easy to implement,
simple control is possible, but requires macro programming,
data logging and trending use some easily learned techniques.
Because there are real questions in the literature about the
responsiveness of the operating systems involved, the control technique described
here should be confined to diagnostic, prototyping, and non-time-critical
applications. Critical process control is still the domain of dedicated
application programs using a true real-time "kernel," or a separate I/O
processor.
DDE-compliant processes communicate with one another through
the operating system. Clients identify values to be exchanged with a three-level
hierarchy of names, separated by specific punctuation marks:
application | topic !
item
(The first symbol, called a "pipe," often appears above the
backslash on a keyboard. The second is an exclamation point.) All three elements
of the name are required to uniquely identify the value being passed. At
any moment there can be multiple applications at work, supplying and requesting
data from one another, using these names. The operating system works like
a switchboard, routing requests to the correct server, and returning the
requested values to the client that needs them.
In the worked example studied here, the "application"
is duTecDDE, a DDE driver (server) program that is in constant communication
with a remote duTec I/O PLEXER™ and modules through a serial communication
port.
*Figure 1: Photo of duTec test fixture.
Engineers at duTec configured an I/O PLEXER test fixture, attached
to real sensors and actuators-a potentiometer, a thermocouple, a pair of
toggle switches, some LED indicators, and a voltmeter [figure 1]. They ran
the duTecDDE configuration program to describe the location and type of each
signal for later use by the DDE driver. The output of the configuration program
appears in a table [see figure 2.]
*Figure 2: Output from duTecDDE configuration program.
At this point, the three-part names are completely defined:
the "application," duTecDDE, is the name of the driver that
will send and receive values from the remote I/O device. The "topic"
is the name assigned to the particular configuration we set up, in this case
"FIXTURE." Finally, the "items" are defined by the names appearing
in the FIXTURE configuration table (i.e., 'Ana(1)' for the analog input,
a pot, located in position 1 of the I/O PLEXER.) The fully qualified DDE
name of the first analog input point is thus:
To see the current values of the measurements in a spreadsheet,
it is only necessary to type the correct DDE names into the cells in which
the corresponding values should appear. The correct format is shown in the
data-entry just completed for the last signal on the fixture, cell C8, in
figure 3.
When the spreadsheet is first loaded, Excel notes the existence
of any DDE references in its cells. It asks if it should connect to the DDE
server(s) referenced in the cells [figure 4.] If the required DDE server
is already running, the data will begin appearing after the next scan cycle
by the driver. If it is NOT running, Excel will ask if the duTecDDE driver
should be started [figure 5.] Excel will look for the driver program only
in its current data-path. At the next scan cycle, raw values read from the
I/O PLEXER become visible.
An obvious use for the spreadsheet is to convert raw values to engineering units. The duTecDDE server uses values ranging from 0 to 100 (representing percentage of full scale) for each analog module, and "0" or "1" for discrete values. Given the equivalent zero- and full-scale values, an all-purpose formula, such as that in cell G10 (named "thermocouple") in figure 6, converts analog values to engineering units.
At this point, the spreadsheet is a simple monitor for a running
process, used only to capture data and convert it to engineering units. The
spreadsheet will function in this mode even if the process is actually under
the control of an MMI package, or of the I/O PLEXER itself (which is capable
of remote control functions.)
The next obvious step is to compute output values within the
spreadsheet and send them, via duTecDDE, to the process under control. The
technical staff decided to compute a simple function of elapsed time as the
desired output:
This is a low-frequency sine-wave with the amplitude, P, controlled
by the potentiometer reading. At each scan cycle, the value f(t) will be
sent to an analog output module attached to the voltmeter.
To send data to a DDE process, the operating system requires
the client to acquire a "channel" number along which the data will be sent.
The Excel built-in function "DDEinitiate" returns such a channel number for
a selected application and topic. The spreadsheet itself is used to store
this channel number for future use.
The macros in figure 7 control the output process. The macro
"ControlDDE", initiated with a keystroke, acquires a channel number and sets
up the second macro, "WriteDDE" to execute at the next scan cycle. Aside
from housekeeping, the central operation in WriteDDE is the "DDEpoke." The
balance of the code is used to turn the output process on and off, by changing
values in the spreadsheet.
' |
This WriteDDE macro also illustrates an important point-the
programmer must guard against "interrupts." Conventionally, this is done
by momentarily disabling the DDE connection early in the macro, then turning
it back on at the very end. Without this precaution, a second DDE event could
arrive before the first is completely processed.
Our staff also found it necessary to control for multiple
initiations of the macro at each scan cycle. (Each arriving input data point
apparently triggered a macro cycle.) The duTecDDE driver supplies a useful
time-of-day value as one of its "system" DDE variables
which can be read like any other. It provides the computer's
clock value as of the latest duTecDDE scan. Code was included in Write DDE
to ensure that output operations occur only if the LastScanTime value has
changed since the last time through the macro code.
Since the spreadsheet MONITOR . XLS combines data from a process
(the pot setting) with a computed value (the wave-form above, as a function
of "real" time) and outputs it to a control actuator (in this case a voltmeter),
"process control with a spreadsheet" has now in fact been demonstrated.
The next step is to collect a series of time-stamped values-
of the control output in this case-in the form of a simple data log. This
took some thought, but is easy to reproduce.
Logging data, for this spreadsheet, meant
Fore simplicity of presentation, we created a second "worksheet"
within the same Excel spreadsheet to hold this data. Range names and the
areas to which they refer are shown in figure 8, and the macro code itself
is given in figure 9. A user can redefine [using the Excel "define name"
feature] the ranges referenced in figure 8 to suit other requirements- adding
data values, or changing the number of points to be logged. The macro itself
need not be modified if these ranges are moved or re-dimensioned.
|
Once the macro, called "Update( )", was created (and tied to the keystroke
control+u for testing purposes) code was added as noted in figure 9 to make
it run repetitively. Such code is actually a snippet of Visual Basic™
programming language, and can be edited in once the macro is created. The
frequency of updating was taken from cell B5 in the spreadsheet so it could
be changed manually. Setting a value of zero or less stops the updating process.
The "OnTime" function causes the macro to execute after the specified interval.
Our staff found it most convenient to set the Frequency value to "SCAN,"
which initiates an update every time the WriteDDE macro executes.
Trending recorded values is straightforward once a data log
is established. It is only necessary to select the values to be plotted (in
this case, the last 40 values sent out to the voltmeter) and click on the
"Chart Wizard" button in Excel's menu. The cursor changes to a little
"crosshair," asking the user to find a suitable rectangular area on the
spreadsheet to receive the chart, then answer a series of questions about
the form the chart should take. A simple line chart with horizontal scale
indicators [figure 10] was placed near the end of the log.
Microsoft cautions that the Windows operating system, even the
NT version, is not a "hard" real-time operating system. Others echo the
sentiment, and explain why,, while disagreeing about how to overcome
it. The biggest problem is dubbed "priority inversion", where low-level,
non-critical tasks can interrupt and impede higher-priority tasks.
Once the macros were debugged, the process did not "crash,"
even while unrelated processes, like editing this article, were carried out
on the same PC. (In fact, it continued to plot points while running in the
background.)
On the other hand, our experience verifies that the scan times
are visibly "non-deterministic." The whole process can be upset by unrelated
events (e.g. someone on the network wants to use a file on the PC running
the spreadsheet.) Problems of lost data were observed even with the simple
process modeled here. Delays of three to four seconds appear as unit conversions
are carried out. The plot occasionally missed a scan cycle for updating.
Sometimes, the process ground to a halt after 10 or 12 hours of operation,
for no discernible reason. For these reasons, the control features
of a spreadsheet probably should be limited to
"Soft Real-Time Systems whose requirements allow for deadlines
to be missed from time to time."
Prototyping, diagnosing, or monitoring a process under the steadier
control of a true real-time processor (such as the duTec I/O PLEXER itself),
would be examples of such "soft" systems.
Top of Page
[ Home ] [ Products ] [ Data Sheets ] [ Support ] [ FAQ ] [ Sales Offices ] [ Request Catalog ] [ Contact duTec ]
© Copyright 1996-2001 duTec. All rights reserved.
For feedback on this site, please send email to:
webmaster@dutec.net