Teachers’ Scenario Guide
Introduction
The PLCtrainingKIT has been used with technical process operators, school children, MBOers and HBOers. Some courses lasted 28 weeks, while technology promotion days had young people celebrating success in 40 minutes. The aims range from analysing systems, through structured programming to simply discovering engineering as fun.
The purpose of this document is to facilitate lesson design by describing the possibilities encapsulated in the scenarios. A number of progressive assignments are suggested. Lessons based on these assignments will require the teacher’s insight into the students’ ability and experience as well of course the desired outcomes.
The PLCtrainingKIT offers the student four familiar scenarios; “Train Crossing”, “Car Park”, “Elevator” and “Chocolate Drink Factory”. These scenarios are quickly understood from general knowledge but nevertheless require careful analysis to describe the final automation. For the progressing student, in each Scenario, normal (happy) flow is augmented with the possibility to introduce, detect and handle fault situations. These include unreactive sensors, motors, valves and indeed users. The student will need to consider how the PLC should react and how to route any report.
The PLC is connected to a “cabling cabinet” with indicators on all of the I/O. At the push of the scenario select button all of the I/O is connected to the indicated scenario. Work on that scenario can then begin with no delay.
Notes:
The design parameters built into the scenarios have been set to optimise learning, rather than exactly match reality. Examples:
1. The Car Park is full with 6 cars.
2. The Chocolate tank heats and cools very quickly.
While all of the tasks are possible, a few might be more easily performed with a more powerful CPU. These have been included with view to:
1. The Student is challenged to the extent that is found in plant commissioning.
2. The Student experiences hardware limitations
Sometimes multiple screens are used to simulate multiple use locations. (A screen button will be needed to switch between them).
Train Crossing
The “Train Crossing” consists of 2 railway tracks crossing a one-way road and a pedestrian path. The railway tracks have, for each direction, a traffic light, a track request button and track clear button.
The road and path are guarded by barriers and double flashing red lights.
The road is also equipped with car detectors under the barriers and between the barriers.
General Use Case
The majority of the time (and initial conditions), the barriers are high with the path and road traffic lights off. The railway track traffic lights are red.
When the request is made by a train the flashing lights will stop the pedestrians and road traffic. The barriers will lower in a safe order (to avoid trapping vehicles). If no vehicles are detected between the barriers, the track traffic light is extinguished in the requested direction.
When the train reports that it is clear the train traffic light is set to red, the barriers are raised and finally the path and road traffic lights are extinguished.
Design Intent of Train Crossing Scenario
This scenario provides a simple platform for familiarisation with the PLC / HMI environment and the PLCtrainingKIT. To that end lesson/task design can be tightly structured. Still there remains considerable scope for the faster students to explore!
Train Task 1 Barrier Control
Program one barrier to move up and down. Use the request buttons to initiate the movements and the light slots to stop them.
Train Task 2 Path Crossing with Northbound trains
Program the crossing for foot passengers on the path only. Both of the path barriers may move together. The path traffic lights should also switch together. Give walkers time to clear the area!
Notes
The path traffic lights should only be extinguished when the barriers are fully raised.
The road lights will be permanently flashing and the Southbound track light is permanently red.
Train Task 3 Trains in both directions
Allow Northbound or Southbound requests to initiate the sequence. Also allow a request in the other direction to be added at any time.
Notes
Both trains need to clear before preparing the path
Train Task 4 Pedestrians and Cars
When a train requests the crossing also prepare the road. First stop cars entering the crossing using the first lights and then after a suitable delay lower the first barrier. When the cars have had time to be clear repeat with the second lights and barrier.
Train Task 5 Road Sensors
Do not lower a barrier when there is a car detected underneath it. Do not lower the second road barrier when traffic is detected between the barriers.
Train Task 6 HMI Mimic (Siemens)
Using the HMI build a mimic showing the status of the lights, barriers and car detectors.
Train Task 7 HMI Car Counter
Add a car counter to the HMI
Train Task 8 HMI Remote control (Siemens)
Program “remote” track request and clear signals from the HMI. (Control centre)
Train Task 9 HMI Preventative maintenance (Siemens)
Add an HMI screen showing for each barrier the latest raise and lower times and the longest measured raise and lower times. Allow switching between this and the normal screens.
Car Park
The Car Park has two entry barriers and two exit barriers. There are traffic lights at each barrier. There are also lights indicating spaces available or car park full. There are sensors in the entry and exit lanes to detect car positions.
General Use Case
This is one of several car parks at an airport. This is the only entrance /exit to this car park. The capacity of the car park is six places. The initial condition is an empty car park with all barriers down and all red traffic lights. The car park will show a green spaces lamp. If a car approaches it will be detected and the barrier raised. When the barrier is fully raised the traffic lights will become green. When the car is by the ticket machine a lamp will invite the driver to take a ticket. Pressing the ticket taken button will allow the sequence on the second barrier to commence and count one space used. Note that the two barriers may not be open together (to prevent a quick drive through). Further a barrier will only raise when the space behind it is clear.
The exit operates in a similar manner.
Design Intent of Car Park Scenario
The car Park appears, in the first instance, rather simple. We can observe, however, that the four barriers are identical and use similar operating logic. This provides an opportunity to introduce structure into the programming using function blocks.
The scenario provides a wide range of fault conditions which need to detected, handled and appropriately reported. This provides significant material for discussion on what the design priorities are.
The HMI may have screens representing the guards’ office, the airport parking central information desk, and indeed the breakdown/maintenance service.
Further the student is able to consider non trivial start up conditions. (Are there really no cars?)
Car Park Task 1 Count the cars
Put all the barriers up by hand. When a car is detected between the two entrance barriers light the “Please Take Ticket lamp”. When the “Ticket taken” button is pressed extinguish the lamp and advance the counter. When the car detector is no longer energised the cycle may be repeated.
Repeat this for the for the exit, counting cars down again.
If the counter reaches six cars or more show the “full” lamp.
Car Park Task 2 Display the car count on the HMI or screen
Show the car count on the HMI.
Car Park Task 3 Count adjust
Make a method to adjust the count to the correct number.
Car Park Task 4 First Barrier
Programme the first barrier.
1. Raise barrier when; Spaces available AND Car waiting at entrance AND Room after the barrier (for the car to move into) AND other entrance barrier closed.
2. Stop motor and Green traffic light when; Barrier high
3. Lower barrier and traffic light red when; Car detected between barriers AND no car under barrier
4. Stop motor when; Barrier fully down.
Car Park Task 4 First Barrier into a function block.
Make the first barrier into a function block. Test it again with the i/o
Car Park Task 5 Second Entrance Barrier using your function block.
1. Raise barrier when; “Ticket taken” AND “Car waiting between barriers” AND Room after the barrier (for the car to move into) AND other entrance barrier closed.
2. Stop motor and Green traffic light when; Barrier high
3. Lower barrier and traffic light red when; Car detected after second barrier AND no car under barrier
4. Stop motor when; Barrier fully down.
Car Park Task 6 Exit barriers
Complete the Car Park using the same blocks for the exit barriers.
Car Park Task 6 Mimic (Siemens)
Make a representation of the Car park on the guards’ office HMI screen.
Show car positions.
Barrier positions and movements
Traffic lights
Spaces
Car Park Task 7 Stuck Cars
Report on the guards’ office HMI screen the position of cars that fail to move in reasonable time. Think of a sick driver, car break down, trouble paying, telephone calls or a failed traffic light.
Car Park Task 7 Stuck Barriers
Using your current sequence hold the barrier back (with your finger) so that doesn’t fully raise within a reasonable time. This simulates a bad motor or a bad detector. Send a message the breakdown/maintenance service HMI screen. If you let the barrier go, it will continue to the fully up position.
What actions should be taken? Implement the correct ones and explain why they are correct.
1. Cancel the breakdown/maintenance service message
2. Close down the car park
Car Park Task 8 Airport parking central information desk (Siemens)
On the airport parking central information desk HMI report
1. the number of spaces.
2. if the car park operations are delayed (barriers or cars)
Car Park Task 9 VIP reservation (Siemens)
Allow the airport parking central information desk HMI (screen) to reserve up to 3 VIP places and note their registration plates.
Make the registration plates visible on the guards’ office HMI screen.
When the car par is full (except for reserved places) treat the car park as full.
Allow the guards office to recognise an approaching car and remove the reserved registration plate, (thus, creating the space and allowing the car entry). Hint for this exercise assume use an integer rather than an alphanumeric registration. Advanced students can achieve alphanumeric solutions using separate characters.
The Elevator
The Cabin is moved with a motor using simple one speed up and down signals. (Stopping is instant)
An analogue signal gives the cabin position. There are also proximity sensors at each floor.
The elevator serves 4 floors. Each has a manual door with a handle (press button). This toggles the “door open” signals which are wired to PLC inputs. The PLC enables these actions with a “door unlock” solenoid.
When the door is open and the cabin is present, load can be added or removed with the load buttons. This can be read in the display and is provided to the PLC as an analogue signal. (When the cabin accelerates upwards the load temporarily increases by 10%)
At each floor call request buttons and acknowledge lamps are provided. Go to buttons are provided in the cabin.
Lamps are provided to show the lift position and (intended) direction.
General Use Case
The elevator will indicate its position and intended direction of movement. It will continue in the up or down direction unless no requests are pending in that direction. If no direction is indicated priority is given to the go to buttons rather than calls. (Passengers entering the lift should have a chance to choose their destination before a call takes them in the other direction)
The elevator is in an office building. It should be prepositioned on the ground floor between 07:00 and 10:00.
Elevator Scenario Design Intent
The Elevator Scenario introduces analogue signals and redundant back up systems. The proximity sensors can be set to fail open or closed forcing consideration of how to handle such failures in safety critical situations.
Carefully timed sequences need to be written for safety. (Can doors bounce and be locked open?)
The call buttons introduce the need to retain the request and decide when it has been satisfied. (Stopped in the right direction and waited for how long?)
The change of direction requires careful analysis, as does restart after maintenance or emergency stop.
Maximum load limits can be introduced, along with relaxation during acceleration phase.
Autonomous prepositioning is introduced.
This scenario lends itself to scalable design. (Identical function blocks for each floor).
Calibration is introduced to match the redundant systems. This may also be automated.
Elevator Scenario Task 1 Calibration
The elevator is to be controlled by the analogue signal. The proximity sensors are a check that the cabin is indeed in the designated place before opening a door. As people enter or leave the cabin the cable stretch will vary moving the cabin a small amount. We should always position the cabin in the middle of the proximity range so that no ambiguity will occur. To this end, temporarily, use the HMI to control the system and note all the switching points of the proximity sensors. Calculate the analogue values where stops should be made.
Elevator Scenario Task 2 Automated Calibration
Design an automated calibration storing 3 values per floor in the tags. (Min, Max and Calculated centre). There is no need to account for hysterysis.
Elevator Scenario Task 3 Redundant system cross check.
Using the values from Task 1 or 2, design a circuit to indicate disagreement between the analogue system and the proximity sensors. This will always happen when approaching or leaving a floor. Why? For how long is this acceptable? Add a timer to appropriately delay the signalling of an alarm. Test with the red fault buttons.
Elevator Scenario Task 4 Scalability
Next year we might need a 5 floor or a 6 floor version of your software. It would be great not to start again, but rather add extra instances of an existing logic blocks. Re-design Task 3, splitting all the logic into 4 (1 per floor) identical blocks and perhaps only the timer and test controller in a separate (master) block. Test this.
Remove three floors. Put one floor into a function block. Recreate the system with 4 identical function blocks and test again. After this do all further tasks wherever possible by extending this function block. This will save you hours!
Elevator Scenario Task 5 Ready to Move
Using a temporary button on the HMI. Initiate door locking (when closed) and report back that all doors are closed and locked for 1 second. Combined with Safe from the cross check in Task 3/4 we have “safe to move”.
Elevator Scenario Task 6 Where are we?
Show on the position indicator a lamp on the floor that the cabin is at. When the cabin is between floors light the lamp above and below the cabin. This can also have the logic added to the scalable function block.
Elevator Scenario Task 6 Let me out
If the cabin is stopped at a floor for 1 second, unlock the door at that floor.
Elevator Scenario Task 7 Where is the cabin wanted?
Make a memory bit for each call button on the floors. Acknowledge” up calls” with short flashes. Acknowledge” down calls” with long flashes. Long and short flashes show that both buttons have been pressed. The in cabin go to buttons do not have an acknowledge. Again, all this can be in an (identical) function block per floor.
Elevator Scenario Task 8 Where to stop?
If the cabin is at floor N and there is a goto N then Stop here
If the cabin is at floor N and there is a up request from N and the cabin direction is up then Stop here
If the cabin is at floor N and there is a down request from N and the cabin direction is down then Stop here
Make a signal for “stop here”.
Elevator Scenario Task 9 Clear the requests
If the door opens or the cabin waits for 3 seconds cancel;
the goto request for this floor AND
the up call for this floor when going up OR
the down call for this floor when going down
Note that cancelling these will cancel the stop here signal allowing the cabin to move.
Elevator Scenario Task 10 Check the Weight limit
If there is too much weight in the cabin, flash the up and down lamps. Do not allow the cabin to move. Remember to suppress this feature when accelerating upwards.
Elevator Scenario Task 11 Access the needs
Using the cabin position and the call/goto memories, each floor can generate signals “cabin needs to go up” and “cabin needs to go down” to service my floor. These can be combined into total “cabin needs to go up” and “cabin needs to go down” signals.
Elevator Scenario Task 12 Add the driver
Implement the strategy:
A. If there is a need to go up (Task 10)
a) set “up direction lamp”
b) wait 2 seconds and initiate lock doors (from task 5)
c) when safe to move and not overloaded, motor up
d) stop when needed here signal (Task 7 is received)
e) wait until needed here signal is cancelled (Task 7)
f) if there is still a need to go up (Task 10), continue with b. If not extinguish up direction lamp
B. If there is a need to go down (Task 10)
a) set “down direction lamp”
b) wait 2 seconds and initiate lock doors (from task 5)
c) when safe to move and not overloaded, motor down
d) stop when needed here signal (Task 7 is received)
e) wait until needed here signal is cancelled (Task 7)
f) if there is still a need to go down (Task 10), continue with b. If not extinguish down direction lamp
Elevator Scenario Task 13 Pre position
Between 07:00 and 10:00, preposition the cabin on the ground floor if it has not moved for 10 seconds. (Simulate a test time with the HMI) (Hint GOTO 0)
Elevator Scenario Task 14 After Service
Prepare a routine for safe restart after an emergency stop or elevator service. Can that be safely done from the control cabinet?
Elevator Scenario Task 15 Add an HMI
Add an HMI for the supervisor’s office.
Elevator Scenario Task 16 Data
Gather data on lift occupancy and wait times throughout the day. Design this to help decide if an extra lift is needed
Chocolate Drink Factory
The Chocolate (Drink) Factory is a tank for mixing and heating liquids. There are inlet and outlet valves with flow sensors, float switches, a depth gauge, a heater, a stirrer and temperature gauge.
Further there is an operator panel to set the number of batches, the cleaning cycle and the recipe variations. These are to be displayed on the HMI.
General Use Case
The number of batches is chosen and any recipe variations are made.
The two hands start system initiates a fully automated process.
a) Water is added and the heating and stirring begins
b) Milk is added and the heating and stirring continues
c) Sugar and Cocoa are added and the heating and stirring continues
d) A time temperature profile is completed.
e) A batch is dispensed
f) The cycle is repeated for the required number of batches.
g) Cleaning is started unless not required is selected.
a. 10% water, b. Drain, c. 10% water, d. Time temperature profile, e. Drain
Chocolate Drink Factory Design Intent
This is aimed at process control. The student will be required to build an automated process. This must be automatically supervised by the software with appropriate safety and quality actions.
Temperature control using PID and PWM is required. The gain of the system varies with the volume in the tank so the parameters may be to be adjusted accordingly. Overshoot due to poor regulation or lack of stirring must be detected and handled. (Reject batch?) Temperature data logging for batch quality tracing will also be introduced.
Recipes will be stored and retrieved
Chocolate Drink Factory Scenario Task 1 Recipe Display
Build a display on the HMI to show the following:
Water 0% or 35% Step 35% Initial Value 35%
Milk 35% or 70% Step 35% Initial Value 35%
Cocao 2% to 12% Step 2% Initial Value 4%
Sugar 2% to 12% Step 2% Initial Value 4%
Batches 1 to 5 Step 1 Initial Value 1
Clean or No Clean Initial Value Clean
Chocolate Drink Factory Scenario Task 2 Recipe Modification
Change the values in the displays in Task 1 using the operator buttons. Use the minima, maxima and step sizes given. Use lamps on the operators panel to indicate non-standard values.
Chocolate Drink Factory Scenario Task 3 Floats
Calibrate the float switch positions. Design a system to monitor the functioning of the analogue depth measurement system. Test this using the red fault buttons.
Chocolate Drink Factory Scenario Task 4 Depth Display
Light the operators depth display lamps at 2%, 33%, 66% and 95%.
Chocolate Drink Factory Scenario Task 5 Valves
Design a system to check the functioning of the valves before starting a batch. The system should also be able to monitor the valve functioning during normal operation. Test this using the red fault buttons.
Chocolate Drink Factory Scenario Task 6 Temperature Measurement
Using the HMI, make temporary heating, stirring, water valve and waste valve switches.
Make a display of the analogue temperature sensor.
Using the above calibrate the senor value against the temperature display on the operator panel.
Chocolate Drink Factory Scenario Task 7 Temperature Control
Using the HMI, temporary heating, stirring, water valve and waste valve switches.
Set up a PID PWM control. Check that the loop performs well (fast with no overshoot) at 10%, 66% and 90% fluid depth.
Chocolate Drink Factory Scenario Task 8 Production
The two hands start system initiates a fully automated process. (Stop recipe and batch number changes).
a) Water is added and the heating and stirring begins 70deg C when contents > 10%
b) Milk is added and the heating and stirring continues 70deg C
c) Sugar and Cocoa are added and the heating and stirring continues 70deg C
d) A time temperature profile is completed. 75deg C and hold for 2 minutes
e) A batch is dispensed
f) The cycle is repeated for the required number of batches.
g) Cleaning is started unless not required is selected.
a. 10% water
b. Drain
c. 10% water
d. Time temperature profile 95deg C and hold for 2 minutes
e. Drain
Chocolate Drink Factory Scenario Task 9 Show Progress
Show on the HMI
Progress through the sequence.
Current batches completed and batches to go
Chocolate Drink Factory Scenario Task 10 Checks
If the temperature over shoots by 2 ◦C Stop the process….and record the maximum temperature reached.
If a valve fails stop the process…. ensure there is no overflow and raise the alarm
If a float signal disagrees with the analogue depth signal … ensure there is no overflow and raise the alarm
If emergency stop button OR flooding (100% full) is detected; mitigate overflow and raise the alarm.
Show these details on the HMI
Chocolate Drink Factory Scenario Task 11 Save the Work
Make 6 Recipe Save Buttons and 6 Recipe Recall Buttons on the HMI.
Implement the saving and recalling of the 6 recipes.
Advanced students can combine a recipe to a single code or use arrays rather than individual tags to store multiple recipes.
Chocolate Drink Factory Scenario Task 12 Temperature Logging
Log and display a continuous graph of temperature for each batch.
Identify each batch with the time and date when dispensing was finished.
Allow scrolling thought the batch times to recall the graphs.
Notes
The cooling occurs naturally or by-passing water through the system
Always use the stirrer when heating to avoid local boiling.
