VISUAL's main program, runnig on a local computer,
acquires measurement and
state information from the controlling PLC
and/or other measuring devices via serial connections or ethernet.
This data is fed into certain locations
of a spreadsheet. The spreadsheet stores the most recent data and performs calculations
which are mostly scaling and limit comparision operations. To display this data and allow
interaction with the machine, a second program runs on the same or a second computer,
communicating with the first. It displays the data in graphical pages containing display
elements and control widgets.
I shall call the second program HMI(human machine interface) viewer. I think it's operation
is best shown by the HMI demo screen.
The first mentioned program consists of the main application and two sets of loadable modules.
The first kind of modules are used to interface to a specific PLC type (PLC drivers). The
second kind of modules I will call data recorders or "recorders" for short. A recorder
stores data to a nonvolatile storage whenever the data changes or at regular times. The rest
of the main program consists of the spreadsheet management and an editor/viewer component
to create and modify the spreadsheets.
Why a spreadsheet? The spreadsheet itself is a well known concept for office calculation
programs. It provides an easy aproach to creating, editing testing and debugging
of formulas. The advantage over other concepts for similar applications, which may use a
database, instruction lists and compiler like development tools is that you see the
effect of modifications on the fly.
Other than office application spreadsheets, VISUAL recalculates all values regularly. This
is in analogy to a PLC's execution cycle:
Sample process inputs
Get data from PLC drivers
Execute program once
Update process outputs
Provide new values to HMI viewer(s) and recorder(s)
Data loggers will record data in different forms for documentation or later
One type of recorder writes the actual value from one spreadsheet coordinate (cell)
to a corresponding binary file in consecutive order.
This is usefull to store large amounts of data in order to display them in trendgraphs,
like paper based data recorders do.
A second recorder will store data from different sources in a text file, the values embedded in some text. This will
serve for alarm message history or protocol printing. A third recorder module may
take data from diffferent cells and store them into a database.
The main application is written in C++. It evaluates a config file in the directory it
The config file defines where the spreadsheet contents files are found, where the PLC
drivers and recorders are located and which of them are used in the current application.
Currently, it provides a viewer/editor for the spreadsheets. This is a text screen
application based on TURBOVISION and curses.
It is intended to split the spreadsheet editor from the main application, which will
then become a linux daemon. This will
avoid the use of a controlling terminal/console, will restrict access to entitled
users and finally provide remote editing via telnet or the web.
PLC drivers and recorders are implemented as loadable modules using shared libraries.
A PLC driver will create its own thread on start which does the actual communication. This will
guarantee that waiting for responses from an external device will not delay the whole
application. The driver thread executes a list "Transfer instruction list" of commands
which define blocks of data to read from or write to the connected device. At the end
of the list, the execution begins from start. Conditional execution is possible on a per
instruction line level. The condition consists in a spreadsheet cell having numerical
contents beeing nonzero.
Recorders will provide a callback routine called by the main application when data
changes. On startup, the driver registers itself with the application and marks the
data sources (cells) it is interested in.
The main application can load a server module providing spreadsheet values via and
accepting values from a TCP/IP connection to a viewer or another instance of VISUAL
running on a remote computer. This interface can also be used to transfer values from
a database to visual, e.g. for recipe management. As a special case of "PLC driver"
it can load a client driver module which connects to a remote instance of VISUAL.
A HMI page consists of a fixed background image and dynamic elements such as displays
or potentiometer symbols, switches etc. The fixed background is itended to be a
schematic drawing of a machine, plant, factory location or of process flow.
The Web Viewer
Currently there is a viewer implemented as a JAVA applet. It connects to the server
module of the main application, fetches the required data and displys it.
The changes in values resulting from user interaction are forwarded over the same
connection. The viewer applet takes the definitions of dynamic elements from its
parameters. HTML pages which embed this applet can be generated using PHP or other CGI
programs which provide parameters according to the machine name or limits given in
recipes in a database. Page changes can either be effected by links in the embedding
HTML or by dynamic elements in the applet itself. Thus you might access a detailed
page by clicking on a symbol in an overview page.
The JAVA viewer is easily extensible by providing new classes. At the beginning of each
value tag, a class name is given. This is evaluated using JAVA's class for name.
Write your own classes if you need special indicator elements.
More HMI Viewers
A viewer based on SVGALIB is under development. This viewer will display exactly the
same as the applet viewer, but on a full screen. No HTML style links will be available.
The SVGA viewer will understand the same parameter lines the applet viewer will. It is
written in C++, resembling the structure of the JAVA implementation as closely as
A mechanism for inluding extensions like JAVA's class.forName will be provided.
Unfortunately, it will be necessary to write a JAVA and a C++ source to use an
extension on both viewers. But if you look on the existing source files,
a new element is relized in 20 to 80 lines of code and not so much changes.
Better than to implement a fat JVM with awt emulation on SVGA, IMHO.
Once the SVGA viewer is useable, it will be ported to LINUX framebuffers. This should
result in a minimum code size for embedded systems.
What about X11?
My current opinion (May change with good arguments):
To operate a machine you need a full screen viewer and not a windowed one. If you are
forced to react fast, you shall not be forced to search for a switch or potentiometer
in a window stack. Further, you should be able to see a red display in the same upper
right corner for example, so you can tell from a distance that something needs
interaction. No other window shall cover that.
The JAVA/WebInterface is intended for supervision, when you sit in your office and
want to know something about your machine.
The full screen SVGA viewer is intended to run on a computer near to the machine and
to operate it. You do not need concurrent application windows on the same screen.
You may use a standard office PC as the local computer. Then you will have enough
resources for SVGAlib or X11. But to get the full screen for the operators display,
a viewer would need to run on X11 without a window manager. If you want windows and
have the resources, use X11 and a web browser.
If your local computer has limited resources, the framebuffer base viewer will
be more usefull.
Other Web Viewers
A viewer for trendgraphs will be realized as a JAVA applet showing one or more trend
line(s). It will be embedded in a HTML page created by a PHP script. PHP might extract
the necessary values from binary data files and pass them to the applet in parameter
A Viewer for protocol printing or alarm history may be implemented as PHP scripts
retrieving pure text lines from the respective files and embed them in HTML.
Other Local Viewers
The functionality for trendgraphs will be realized as a standalone C++ program
which extracts the necessary values from binary data and displays them on SVGA
or framebuffer screens.
A text viewer for protocol printing or alarm history might be based on SVGAlib/framebuffer ,
another on text/curses.