Imperative programming is an intuitive, simple way of talking to actuators: move here, then move there.
MachineLogic instructions are very imperative in nature - in fact, they always belong to a “sequence”. It’s no surprise, since sequential composition is so fundamental to an agent effecting changes in the physical (and temporal) world. You can’t be in two places at the same time.
However, it’s rarely the case that an industrial process will consist of a simple finite sequence of actions. Usually, a recipe or mission definition (described by some data structures) will drive repetitions in a process; and events will determine when certain actions may be taken. For example, it’s only once we know that a conveyor will bring a new product to a station that we should effect motions to go there, and pick that product. Note that Vention machines such as conveyors and robots can easily be modelled as autonomous agents, each with its own state machine, exchanging messages with one another.
These observations lead to a few basic structural patterns in MachineLogic, and a pleasant declarative envelope.
1. Parallel event handlers
Sequences launched in parallel, starting by a ‘Wait’ instruction, and wrapped within a forever loop, constitute a basic idiom of MachineLogic. Each such sequence acts like a mini agent, waiting on a condition to perform an action. For those accustomed to rule engines, these sequences act like rules. From a ladder logic perspective, they act like “rungs”.
A MachineLogic program may have as many of these sequences as it pleases. If you imagine the whole program as one event loop, then each such sequence can be seen as the handler of one event type. Note that these sequences run in parallel but within a single thread. Here’s how it looks:
| program tree | handler |
|---|---|
 |
 |
2. Data-processing loops
Usually, the data model to express a mission will be some sort of list. It may or may not be dynamic. This is very easily expressed in MachineLogic, and lambdas further facilitate things:
| mission data |
|---|
 |
| program tree | main loop |
|---|---|
 |
 |
3. Finite state machines
An even more synthetic formulation of the event loop of a program can take the form of one or more parallel state machines. The state machine:
- brings together events, evaluated conditions and action sequences
- allows to easily centralize & enforce arbitration of how the actuator is controlled
- reduces the amount of “boilerplate” (e.g. no need for explicit while loops on each event handler)
When executed, the state machine instruction simply activates its FSM (instantaneously).
