A system state is a mode of operation. Consider a bank machine that will go through very carefully selected states. The general sequence of states might be idle, scan card, get secret number, select transaction type, ask for amount of cash, count cash, deliver cash/return card, then idle.
A State based system can be described with system states, and the transitions between those states. A state diagram is shown in Figure 31.1 A State Diagram. The diagram has two states, State 1 and State 2. If the system is in state 1 and A happens the system will then go into state 2, otherwise it will remain in State 1. Likewise if the system is in state 2, and B happens the system will return to state 1. As shown in the figure this state diagram could be used for an automatic light controller. When the power is turned on the system will go into the lights off state. If motion is detected or an on push button is pushed the system will go to the lights on state. If the system is in the lights on state and 1 hour has passed, or an off pushbutton is pushed then the system will go to the lights off state. The else statements are omitted on the second diagram, but they are implied.
Figure 31.1 A State Diagram
The most essential part of creating state diagrams is identifying states. Some key questions to ask are,
1. Consider the system,
What does the system do normally?
Does the system behavior change?
Can something change how the system behaves?
Is there a sequence to actions?
2. List modes of operation where the system is doing one identifiable activity that will start and stop. Keep in mind that some activities may just be to wait.
Consider the design of a coffee vending machine. The first step requires the identification of vending machine states as shown in Figure 31.2 Definition of Vending Machine States. The main state is the idle state. There is an inserting coins state where the total can be displayed. When enough coins have been inserted the user may select their drink of choice. After this the make coffee state will be active while coffee is being brewed. If an error is detected the service needed state will be activated.
Figure 31.2 Definition of Vending Machine States
The states are then drawn in a state diagram as shown in Figure 31.3 State Diagram for a Coffee Machine. Transitions are added as needed between the states. Here we can see that when powered up the machine will start in an idle state. The transitions here are based on the inputs and sensors in the vending machine. The state diagram is quite subjective, and complex diagrams will differ from design to design. These diagrams also expose the controller behavior. Consider that if the machine needs maintenance, and it is unplugged and plugged back in, the service needed statement would not be reentered until the next customer paid for but did not receive their coffee. In a commercial design we would want to fix this oversight.
Figure 31.3 State Diagram for a Coffee Machine
Consider the traffic lights in Figure 31.4 Traffic Lights. The normal sequences for traffic lights are a green light in one direction for a long period of time, typically 10 or more seconds. This is followed by a brief yellow light, typically 4 seconds. This is then followed by a similar light pattern in the other direction. It is understood that a green or yellow light in one direction implies a red light in the other direction. Pedestrian buttons are provided so that when pedestrians are present a cross walk light can be turned on and the duration of the green light increased.
Figure 31.4 Traffic Lights
The first step for developing a controller is to define the inputs and outputs of the system as shown in Figure 31.5 Inputs and Outputs for Traffic Light Controller. First we will describe the system variables. These will vary as the system moves from state to state. Please note that some of these together can define a state (alone they are not the states). The inputs are used when defining the transitions. The outputs can be used to define the system state.
Figure 31.5 Inputs and Outputs for Traffic Light Controller
Previously state diagrams were used to define the system, it is possible to use a state table as shown in Figure 31.6 System State Table for Traffic Lights. Here the light sequences are listed in order. Each state is given a name to ease interpretation, but the corresponding output pattern is also given. The system state is defined as the bit pattern of the 6 lights. Note that there are only 4 patterns, but 6 binary bits could give as many as 64.
Figure 31.6 System State Table for Traffic Lights
Transitions can be added to the state table to clarify the operation, as shown in Figure 31.7 State Table with Transitions. Here the transition from Green E/W to Yellow E/W is S1. What this means is that a cross walk button must be pushed to end the green light. This is not normal, normally the lights would use a delay. The transition from Yellow E/W to Green N/S is caused by a 4 second delay (this is normal.) The next transition is also abnormal, requiring that the cross walk button be pushed to end the Green N/S state. The last state has a 4 second delay before returning to the first state in the table. In this state table the sequence will always be the same, but the times will vary for the green lights.
Figure 31.7 State Table with Transitions
A state diagram for the system is shown in Figure 31.8 A Traffic Light State Diagram. This diagram is equivalent to the state table in Figure 31.7 State Table with Transitions, but it can be valuable for doing visual inspection.
Figure 31.8 A Traffic Light State Diagram
State diagrams can be converted directly to C code using block logic. This technique will produce larger programs, but it is a simple method to understand, and easy to debug. The previous traffic light example is to be implemented in ladder logic. The inputs and outputs are defined in Figure 31.9 Inputs and Outputs for Traffic Light Controller, assuming it will be implemented on an Allen Bradley Micrologix. first scan is the address of the first scan in the PLC. The locations B3/1 to B3/4 are internal memory locations that will be used to track which states are on. The behave like outputs, but are not available for connection outside the PLC. The input and output values are determined by the PLC layout.
Figure 31.9 Inputs and Outputs for Traffic Light Controller
Figure 31.10 Setup Functions
Figure 31.11 Setup Functions
The previous example only had one path through the state tables, so there was never a choice between states. The state diagram in Figure 31.12 A State Diagram with Priority Problems could potentially have problems if two transitions occur simultaneously. For example if state STB is active and A and C occur simultaneously, the system could go to either STA or STC (or both in a poorly written program.) To resolve this problem we should choose one of the two transitions as having a higher priority, meaning that it should be chosen over the other transition. This decision will normally be clear, but if not an arbitrary decision is still needed.
Figure 31.12 A State Diagram with Priority Problems
The state diagram in Figure 31.12 A State Diagram with Priority Problems is implemented with ladder logic in Figure 31.13 Subroutine for Prioritization Problem. The implementation is the same as described before, but for state STB additional logic is added to disable transition A if transition C is active, therefore giving priority to C.
Figure 31.13 Subroutine for Prioritization Problem
·
1.