By David Stonier-Gibson, SPLat Controls
Acter-based programming is a programming paradigm that is particularly suited to real-time machine controls, where "machine" is broadly defined as any piece of elctro-mechanical equipment that needs and electronic control.
A complete control program will consist of one or more Acters. Acters are defined by a top-down analysis of the control requirement, whereby the required behaviour is factored into functional black boxes in a block diagram. For example, the block diagram for an automatic grind and brew coffee machine might contain the following black boxes:
- Grinder control
- Water temperature control
- Pump control
- Water metering
- Reservoir management
- Bean hopper management
- Master sequencer
- User interface
The Acter concept is based to some degree on Object Oriented Programming, but differs in several ways. The most significant shared concept is that of encapsulation. Encapsulation means that the only way in which anything outside the Acter can instigate an exchange of data or commands is by making calls to the Acter's Methods. Methods are subroutines or functions that give access to the Acter's internal data and operations.
At no time may anything outside the Acter directly access its internal data or any hardware resource that belongs exclusively to the Acter.
An Acter consists of the following elements:
- 0, 1 or more free-running "tasks" (aka processes). A task is a bunch of normally non-terminating (endlessly looping) code that runs in its own multitasking thread. Typically a task will implement a Finite State Machine.
- Local data (variables).
- Methods (code). A method may do something as simple as setting or retrieving a variable. It may also be the equivalent of a C function that computes a result from internal data or caller-supplied arguments.
A closer look at Tasks
The tasks should be viewed as semi-autonomous entities. They run in their own processing threads and have a life of their own. A task exists, and acts, even if the host Acter is not being called through its methods (i.e. is otherwise dormant). This differentiates Acters from conventional objects or functions, which can only do something when called.
A task can make calls to the methods of other Acters. A task can also directly read or write the local variables within its host Acter. What is quite impossible, however, is to somehow make calls to a task from outside the task itself. All transfers of information in and out of the task must be initiated by the task itself.
The local variables
Local variables are the only medium available for transferring information into and out of tasks. The variables act as dead letter drops ... To send the task some data, drop it in the variable and wait for the task to come and read it out. To get data from the task wait for the task to drop the data into a variable, and fetch it from there.
The only way to affect a variable inside an Acter is via one of the Acter's methods. It follows that the only way anything inside an Acter can communicate with a task inside another Acter (say to send it some data or a command) is via method calls affecting internal variables.