Control Design for a Sorting System
Purpose
The objective of this case study is to showcase my expertise with an example. It shows the life span of a simple project from solution definition to execution phase. Throughout the study, I will walk you through all phases, from problem definition to implementation.
During my last few years of experience, I had the chance to lead each phase on different occasions. In this study, I will start with a proposed solution with a simple description. Then I will act as the lead technical engineer defining/requiring info from the client. I will assume some values to be able to proceed with the solution implementation.
Problem Description (from a client)
Consider a plant consisting of several conveyor belts, a Barcode Tunnel Scanner, sorting devices with four destinations, and a turning loop, see the sketch See the diagram to the right
This type of plant exists in E-commerce storage areas, where the operator, on the left, picks orders from nearby shelves and places parcels on a conveyor belt, usually it is referred to as the infeed conveyor. The conveyor system transfers parcels through a dynamic barcode scanner where the control system sends destination requests to a sorting computer. This sorting computer responds with a designated destination for each parcel. The conveyor system will then transfer the parcel to one of the four destinations on the right. Parcels with no destinations will return and the process is repeated.
*Please note that this example shows only the basic functionality of the system and does not consider any contingencies to keep the
case study relevant
Solution Approach (My team or myself depending on the size of the project)
When dealing with such a problem definition, it is important to start requiring some data about the system and check if the system can handle those requirements. It is my responsibility to make sure that the system reaches required performances and guide the client throughout the design phase to prevent poor performance.
The first thing I would require is the target performance and in such plants is measured by parcel per hour. Let us assume that the performance required matches the system layout demonstrated in the problem definition section. One thing to note is that you have one operator feeding the system and 4 people are handling those items. This will automatically trigger the need for a buffer system. As one operator cannot keep 4 operators at the destination busy. One suggestion would be to install a long infeed conveyor where the operator can lay parcels back-to-back without a gap in between.
Then a gapper system, as the barcode tunnel scanner has constraints regarding the minimum gap to keep between items.
The barcode tunnel constraints trigger the following question, is there any local regulation that limits the maximum conveyor velocity? This is an important concern as the performance is a function of the velocity of conveyors and the front-to-front gap between items. If the gap is too high, the velocity needs to be high as well. Assuming that performance is respected within speed limits, let us consider the next steps.
One last clarification to be made is the scope of supply of the sorting computer. If the sorting computer is in the scope of work of the client, we need to define an interface document to the control system. We need to define the medium of communication, message structure, and messaging protocol (keepalive, message route, error handling, etc.).
Once the above requirements are defined, we can move on to the electrical and control requirements.
*To keep the case study short, I will not consider types of material, paint, heights of conveyor, mechanical clashes, or desired OEM brands, I will assume that we comply with all those requirements
Electrical / Control Requirement
The proposed system requires motors driven by VFDs (Variable
Frequency Drive), photoelectric cells, or PEC for short, power panels, and some electrical accessories. To give input to the design of the electrical
schematics, I go through the following checklist :
Check Required applicable norms (CE, UL, UKCE, …)
Check Safety Integrated Level (SIL)
Total number of Motorized conveyor belts
Total number of 24-volt Input-output devices (sensors,
buttons and light indicators,)
Calculate power usage
determine the electrical interface with third-party systems
(Scanners, Sort Computer)
Study the position of each device to determine cable lengths
Check network topology for field devices (Ring, Bus, …)
Determine CPU type based on memory and performance requirement
(Depends on the data stored for the control system)
• Define local/remote monitoring system
In such systems, I will usually go with a decentralized control system design. Where input/output signals are connected to distributed VFDs. The VFDs are connected to the main control system through Profinet. If we need to connect more IOs, we will install disturbed IO modules and connect them to the control system through Profinet as well. There exist different field buses, and based on the requirement and the allocated budget, variations could be adapted.
However, it is important to guide the client to adapt to technology by showing the benefits of one technology over the other. For instance, using Profinet allows for fast remote diagnostics which means lower downtime. My job is to provide the client with a long-term sustainable solution rather than focusing mainly on cost reduction. Limiting oneself to a tight budget might not produce a system with long-term benefits. I help my clients to go through
cost/benefit analysis to try to provide the best solution for the problem.
Control Design
At this stage, the system performance and the electrical requirements are defined. The focus of this section is the actual design and implementation of the control logic.
To start the design effectively, let us list the devices to control:
Conveyor Belts
Variable Frequency Drives (VFD)
Photo Electric Cells
Light Indicators
Destination chutes
Switching Devices
Barcode tunnel scanner
From the above list, we conclude that we need 7 main function blocks. These function blocks are going to be called for each component. So, we write one routine for each of these devices then we allow passing parameters to each function block. Parameters include device hardware address, length, speed set-point, current limit, and so on.
Each function block requires input/output and variables to store data that is used either by other devices or for visualization purposes. For each function block, I define the following data types:
IO parameters data
IO logic Interface data
• Alarm/Status data
IO parameters data contains the parameters that differentiate each item from others. For instance, length is a parameter that changes from one conveyor to another. The hardware device address is another parameter specific to a VFD.
IO logic interface data, this data type is utilized to send and receive data from other devices. For instance, two conveyors placed in a series configuration need to exchange data to control the flow of parcels, see below.
From the above figure, we see a parcel on conveyor 1 is ready to be transferred to conveyor 2. In this case, conveyor 2 needs to send a ready to receive signal to allow for parcel transfer. Ready to receive means that conveyor 2 is running and can receive items. This type of signal is stored in the IO logic interface data.
Each system component has states and alarms to be stored and shared with different HMIs. Some alarms prevent for instance VFDs form running due to overheating. Each control device has states and alarms that needs to be monitored to control the system in a safe and correct manner.
Once each function block is defied, function calls for each
component are invoked. The following simple architecture shows the overall system. As you can see following a modular approach as I have shown above makes the overall architecture simple and easy to maintain. Any change in one functionality requires a change testing one function block and the rollout is
easy. This approach allows us also to automate the generation of most of the callbacks from a simple input file with system parameters. This means that we
do not need a specialist to generate the overall system software.
One important thing to note is that we did not consider the function of the VFD as part of the conveyor belt. This is intentional as conveyor belts could be driven by different VFD brands, soft starters, or any other relay logic. This keeps the system design invariant to the type of the utilized
drive. For instance, assume that we have 3 conveyors driven by VFDs and 2 driven by 24-volt drives. The conveyor callback will be the same. The only change will be in the VFD callback, and we need to add another function block to control the new 24-volt drive. As you can see, this design approach makes the overall architecture easy to maintain.
State machine example of a Vertical Sort Unit (VSU)
I prepared this example to showcase my capabilities in designing using the State machine approach.
A Vertical Sort Unit functionality is to divert the flow of parcels into different paths. The vertical-sort-unit consists of two conveyor belts that have two different configurations: closed or open. When they have closed the parcels flow to one path and when opened the parcels will flow to a different path, See the diagram to the right
This VSU is equipped with 4 proximity sensors, two to trigger slowing command and the other two to indicate the close or open position. The figure below shows the sensor layout and the function of each sensor.
This VSU is equipped with 4 proximity sensors, two to trigger slowing command and the other two to indicate the close or open position. The figure below shows the sensor layout and the function of each sensor.
The VSU has two different operation modes: Automatic Mode and Manual Mode.In automatic mode, the VSU changes state based on parcels entering the system. The main control unit will send either the open or close command to divert parcel flow. The VSU in this mode will monitor if there is any jam that might block the opening/closing of the unit. If a jam is detected the VSU will automatically handle the issue. In the manual mode, the operator will issue a jog command and the operator will make sure that there is no obstacle to opening or closing the VSU. This mode is used for maintenance purposes or contingencies only.
Automatic Mode
To design a state machine, we need a list of states and events. Here is the list of states and events followed by a state machine diagram.
States:
| ID | STATE |
|---|---|
| 0 | IDLE |
| 1 | OPEN |
| 2 | CLOSE |
| 3 | OPENINING LOW SPEED |
| 4 | OPENING HIGH SPEED |
| 5 | CLOSING LOW SPEED |
| 6 | CLOSING HIGH SPEED |
| 7 | INTRUSION |
| 8 | REVERSE LOW SPEED |
| 9 | OPEN IN FAULT |
| 10 | UNDEFINED POSITION |
Events :
| ID | EVENT |
|---|---|
| S1 | SENSOR CLOSE POSITION |
| S2 | SENSOR CLOSING |
| S3 | SENSOR OPEN POSITION |
| S4 | SENSOR OPENING |
| FTC | UNTRUSION PHOTOCELL |
| CMD_OPEN | COMMAND OPEN |
| CMD_CLOSE | COMMAND CLOSE |
| ACK | ACKNOWLEDGMENT |
| TIMEOUT | MOVING TIMEOUT |
State Machine:
Man Mode
To design a state machine, we need a list of states and events. Here is the list of states and events followed by a state machine diagram.
| ID | STATE |
|---|---|
| 0 | IDLE |
| 1 | OPEN |
| 2 | CLOSE |
| 3 | OPENINING |
| 5 | CLOSING |
Events :
| ID | EVENT |
|---|---|
| S1 | SENSOR CLOSE POSITION |
| S3 | SENSOR OPEN POSITION |
| CMD_OPEN | COMMAND OPEN |
| CMD_CLOSE | COMMAND CLOSE |
State Machine:
Summary
The case study presented a method of work to solve a control problem for a simple sorting system. It presented the system description with a limited set of requirements. The study showed a methodology to solve such problems by demanding specific questions about performance and suggested improvements to the original problem. This is standard practice when starting a new project.
The study also showed a list of requirements to identify before electrical design activities. The study assumed that all mechanical requirements are met. The case showed an approach to designing a maintainable software architecture. It showed the types of data to be stored for each software component (function block).
Finally, the last example showed how to design a software component (function block) using a state machine approach. The example demonstrates how easy to document and communicate such functionality with different teams.
I hope with this case study, I managed to explain in more detail the methodology and mindset I use when presented with technical problems.
For further details, please do not hesitate to contact me through my contact. Looking forward to collaborating with you!