Interpretive Dynamic Graphic Displays (1980)

This is a follow-on post to "Sewage Works Data Acquisition and Process Control".

Graphics Displays "Tailorable" by End Users?

Yes, that was in the "Requirements". When I arrived on the project, a couple of engineers were looking at how they could design a "paint" program! That seemed like total over-kill for a piece of functionality that would be very rarely used. Sometimes we must be "creative" in interpretation of wording of "requirements".

The Graphics Hardware and Drawing Language

Fortunately, the engineering company had selected and purchased a sophisticated, programmable graphics display terminal (RAMTEK). It had an inbuilt interpreter for a drawing language. The drawing instructions were fed into the terminal as an ASCII data stream.  For example:-

        [COLOR RED][RECT <x-value>,<y-value>,<width value>,<height value>]

All <values> were in pixels. (Forgive me RAMTEK if I haven't remembered your syntax correctly). So in fact it was quite reasonable to draw up the required layout on graph paper and code the required drawing sequence. In today's parlance, we could call it a "mark-up language".

Language Extensions to make it Dynamic

But the graphics we required had to display dynamic data in "real-time". There would be meter readings, red/yellow/green signals, switches/stop-valves that indicated "open/closed", arrows with changeable direction, etc. - think "Dashboard".

My solution was to extend the RAMTEK language with three simple constructs.

• Firstly, values could be replaced by named variables that referred to values in the in-memory data streams. There are two types of variable, booleans (ON/OFF) and integers, represented as "Bnnn" and "Innn".
• Secondly, labels could be assigned to any statement - eg. Lnnn:.
• Thirdly, a simple variable test construct was defined with simple boolean and logical operators, that if tests "true" directs "execution" to a specified label (eg. [IF B123 ON L456].

In today's parlance, this is known as "templating" (eg. PHP). The implementation was our own interpreter program that processed a template file, substituting variables with their real-time values, performing the testing and branching, continuously outputting a stream of drawing commands to the terminal. The end of a template file simply looped back to the start. So the "real-time" screen refresh was determined by how quickly this interpretation loop executed.

Was It "Tailorable" by End Users?

The "template" file (program?) was a simple text file of reasonably readable instructions. Sure, it was tedious to update but essentially clerical, so we argued that it was "tailorable".

The Actual Display Graphics

There were three different displays delivered with the system.

• The hydrolic flows through the works (the first stage of the plant is to filter and separate the liquid from the solid 'sludge').

• The "sludge" system monitoring. (The sludge is pumped through large anaerobic digester tanks, the active bacteria in which are highly sensitive to temperature and acidity, so monitoring of temperatures and pump flows is critical in such a plant).

(apologies for the hand-drawn schematic - that's all I have left from the project)

• The electrical generation system. The above anaerobic digesters produce methane which is drawn off and feeds electricity generators which power the plant as well as sending excess power back into the city power grid. Its graphic display showed generators' status, voltages, currents, circuit-breaker statuses, etc.