Logic Controllers are the workhorses of automation and have enabled practitioners to deliver automa tion situations reliably and quickly.
However, the ease of change and flex ibility does extract a price. Automation software could become unstructured and result in an implementation that is hard to understand and maintain.
If any breakdown occurs it might take longer to restore the system if the functionality is not well understood. Worse still, convoluted logic can have unintended consequences when for example, a rare combination of events exposes a flaw in the software.
This article encourages the use of state-transitions approach to plc programming.
The concept of a state is simple. An indicating lamp can be in one of the two states – On or Off. The transition from Off to On state occurs when an On command is received. Similarly the event Off switches the lamp from On state to Off.
Consider the example of a section of a conveying system (figure 1). Conveyor A transports pallets from North to South and transfers them via the turntable to Conveyor B that takes the pallets east wards.
The states in which the turntable will be placed are:
Idle – waiting to receive a pallet from Conveyor A
Receiving – a pallet from A
Turning – towards Conveyor B
Waiting – to deliver a pallet to B
Delivering – a pallet to B
Returning – to the receiving position
The turntable, if in the idle state, will stay in that state until an event occurs. This event could be a proximity sensor signalling the availability of a pallet from conveyor A.
That signal would put the turntable in the Receiving state. Simultaneously, actions associated with the new state would be performed. The action being that the conveyor integral to the turntable switches on.
The table shows the events that cause a transition from one state to another.
The state transitions in the table are sequential and do not reveal the full advantages of the state transition approach. To delve deeper, let us look at a variation of the example detailed in the table. The turntable (figure 2) now serves two conveyors A and C and trans fers their contents to conveyor B.
The states in which the turntable will be placed are:
Idle – waiting for a callout
Receiving A – a pallet from A
Receiving C – a pallet from C
Turning – towards Conveyor B
Waiting – to deliver a pallet to B
Delivering – a pallet to B
Callout A – turning to serve A
Callout C – turning to serve A
Figure 3 shows how the state transi tions will take place. The main differ ence is that now the turntable will rotate form idle position to face conveyor A or C depending on which of the two has a pallet to deliver.
How does this make plc programming any easier? It does that simply by requiring that only relevant inputs need be considered while deciding on a transi tion from one state to another.
For example, the transition from Idle to Callout A or Callout C depends only on whether or not there is a pallet waiting at A or C and all other inputs can be ignored. See the control system flowchart (figure 4).
The transition to Turning can take place from either of the two states – Receiving A and Receiving C. The control logic for this is also straightfor ward as shown in figure 5.
Why is the design shown in figure 5 more robust? It is more robust because it ignores the noise generated by machine sensors.
If there is a spurious “Table Loaded” signal encountered while the turntable is in the Idle state then this spurious signal will cause no problems because it is irrel evant to the decision to change state to Callout A or Callout C.
If the signal “Pallet @ A” is a noisy signal then it can be dampened to increase its reliability but even if it continues to be somewhat noisy it can be tolerated because once the state of the system has been altered the input signals become irrelevant.
Why is maintainability easier? Because at any point in time the system is in a unique state and will remain in that state until some specific real time events occur.
Therefore, by watching the state tran sitions one can quickly narrow down the cause of any unexpected system behaviour.
So, for example if it is observed that the turntable is turning to face Conveyor C for no apparent reason then the cause must really be that the optical sensor that detects the presence of a pallet is defective – it is reporting a phantom pallet. The problem can be quickly fixed by adjusting or replacing that sensor.
Depending upon the state of the system, specific outputs are activated. The conveyor which forms a part of the turntable, as an example needs to be activated when the system is in any of these states: Receiving A, Receiving C, Delivering.
If this conveyor is observed to be not operating when the system is in any of these states then further investigations into the electro-mechanical system of the turntable will be called for.
A comparison of observed behaviour against the expected behaviour being easily possible, it is easy to shortlist the root causes. And this saves precious time!
The latter event is one of the many states of Conveyor B but the only event that affects the Turn Table.
The state-transition approach provides a conceptually easy way of coordinating the operation of discrete subsystems within a large system.
In complex environments it may be desirable to organise subsystems in groups and state changes also defined at the group level.
Thus, for example not only can state- transitions be defined for subsystems that make up say a palletiser but also the palletiser can have defined state-changes that can make it easier to coordinate its operation with a related material handling system.
For sake of clarity, there was no mention made of some other important states. A common one is an Unknown state, which occurs when the plc system is booted up.
The subsystem must be able to discover what its state is. The turntable can check if it has got a pallet and if it is directed towards Conveyor B, this infor mation being readily available from field sensors.
If this is the case, the inference would be that it should be in the Waiting state. Similarly, if the table is empty and in an undeterminable position but there is pallet waiting at Conveyor A, then its state must have been Callout A when the system failed and it should therefore transition from Unknown to Callout A.
Another state to consider is the Faulty state. A subsystem can be tagged as faulty if specific machine sensors report that state and have shut the subsystem down or if an output has been set but the expected effect (change of position) has not taken place within a given time. Transitions from Faulty state would go on the lines of the Unknown state.
Summarising, the state-transition approach is an intuitive way of dealing with automatons and provides immense benefits not only during the design and programming phases of the projects but also continues to deliver immense bene fits during the whole life of the auto mated system through reduced down time and short time to repair.
So, if your plc programs have been giving you headaches then do transition to the state-transition approach.