SourceForge Logo

Principle of operation:

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.

Components:

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.

Spreadsheet

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:
PLCVISUAL
Sample process inputsGet data from PLC drivers
Execute program onceRecalculate formulas
Update process outputsProvide new values to HMI viewer(s) and recorder(s)
Repeat cycleRepeat cycle

Data loggers

Data loggers will record data in different forms for documentation or later evaluation. 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.

Realization:

Main application

The main application is written in C++. It evaluates a config file in the directory it starts from. 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.

HMI viewers

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 possible. 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 tags. 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.