Saturday, 16 February 2008

Control modules

And how great control modules are pure S88.
Control modules know nothing about the stuff you are making. They do not even know how stuff might be made. Part 1 is clear about that, as the recipe has no interface with control modules.
That does not mean that they cannot do a lot, in fact they are the bedrock of any application. The better they are, the easier the rest is.
'Primitive' Control Modules handle the Inputs and Outputs, from the plant and the operator and from higher levels in the system. They then make sense of it, setting and monitoring the state of the physical equipment that is connected the to IO and driving things like Faceplates.
Primitive Control Modules can be quite intricate, and supposedly simple things like motors can have a surprising number of states and parameters. They are little models in theselves.
Higher level Control Modules such as a PID loop or a one that handles a valve cluster also have states and parameters etc. They may even have sequences to move from one state to another or to perform a cyclic function. Some S88 practitioners choose to all these sequences 'Phases'.
I don't like to, but that is another story that I will return to.
I also use Control Modules for things like resource management - take a look at this Cyclic Request Handler . This is a small simple module to share a common resource among a number of users. These request the resource via a boolean flag, like holding your hand up in class.
They remove that flag when their demand no longer exists. The Module just looks at each in turn, and supplies if the 'hand is up'
The method guarantees First come at most Nth Served where N is the number of users. It is easy state control and avoids needing any form of queue and could easily be implemented in a PLC. Is it a Control Module? If not what is it? I hope Part 5 will find a space for it, and not a procedural one, as it does not need to know anything about making stuff!

No comments: