Machine Interface Example
Purpose
On an industry floor, several intelligent systems perform specific functions. On many occasions, these systems need to exchange data in one form or another. Multiple industry protocols are designed by solution providers to make this task easy. For example, when considering PLCs (Programmable logic controllers), they exchange data with SCADA (Supervisory Control and Data Acquisition) systems through OPC UA.
This is one of many standard protocols that exist in today’s market. Consider that you are looking to develop your custom application to exchange data between a PLC and an LED controller to visualize data to operators. Suppose that you do not have the budget to acquire the license of an industrial protocol or you might not have the time to wait for the certification process that many of standard protocols require. In this case, you might want to develop your custom-made communication protocol.
Assuming that both the PLC and the LED controller have an ethernet adapter, one easy way to develop a protocol is by designing a set of messages and communication flow through TCP/IP. Through such a protocol, both devices can run on different operating systems and still can communicate concisely.
One important thing to keep in mind is to prepare a clear interface document that explains; the communication medium, message structure, message exchange flow, and error handling. In this study, I will show you how to prepare an interface document that can be utilized by any third-party provider when interested in interfacing with your system.
Introduction
The LED controller drives a five-meter LED strip. Such LED strips are powered by a 5-volt power supply and controlled by an SPI or I2C protocol. The PLC does not usually implement such protocols, and finding a module that performs such protocols are rare and relatively expensive. To display indications through an LED strip, we need to utilize a computer chip with an SPI protocol and interface it with PLC. Raspberry pi is an example of a widely spread computer board that can accomplish such a task. On Rasberry pi, we need to write a program that reives messages from the PLC and dive the LED strip to display the desired color.
The following sections present the communication interface between an LED controller and a PLC device. First, the communication description and parameters are defined. Second,
Glossary
Socket Communication
For communication purposes, one channel over TCP/TP is established. The PLC sends a set of data to the LED controller to display.
Pre-requisites
Both the PLC and the LED controller are connected via Ethernet.
Both the controller and the PLC must be equipped with a stream-socket interface.
Comunication Roles
TCP/IP permits client/server-based communication. Via the established channel, the PLC acts as a client, and the controller acts as a server. The server will listen to incoming requests and react according to the protocol described in this post.
Communication Management
Both communication nodes need to implement the following diagram for connection management.
Socket Paramters
Address family specification: AF_INET
Socket type specification: SOCK_STREAM
Full Duplex Communication
After a connection is established, each peer can send/receive telegrams asynchronously.
Telegram Counter
Both peers must set the telegram counter to zero when a connection is established.
The sender’s node increments the counter at each transmission. The receiver node compares the counter value with the previous number. If the counter is different, then the message is processed. Otherwise, the receiver starts an Rx timeout timer.
Keep-Alive
Each peer must receive at least a telegram within a predefined RX timeout. A keep-alive telegram must be sent at the polling time to keep the connection healthy.
Error Management and Communication Timeout
Each peer closes the established socket and attempts to establish a new one when a communication timeout or error occurs.
Byte Order
LSB-MSB (Little Endian) shall be used.
Message Structure
Message Types
The communication channel transmits one/more messages. The following table summarizes the message structures.
Three main messages are transmitted. Pixel data, acknowledgment, and keep alive messages. Each message has a header, a body, and a tail. The Header contains the message progress number, Message identification, and pixel length.
The pixel data message contains the RGB color intensity of each pixel. Each pixel data is an unsigned double word. A delimiter separates the double word values. The last pixel ends with an ETX character instead.
The ETX character signals the host of the receipt of pixel data. The host sends an acknowledgment message containing the same header value. The body, in this case, will be empty. The keepalive and the acknowledgment messages include the header and the tail without the body.
For acknowledgment, the host detects the message type and sends it back to the client.
Note:
– Keep alive, and acknowledgment messages have a fixed data length
– Pixel data message type has a fixed length depending on the length of the pixel data. – The host should continue polling data until it encounters the ETX character
KeepAlive Message Type
KEEPALIVE message keeps the connection up and running when no data is exchanged. The message structure of KEEPALIVE is equal for all channels.
Message Example:
An acknowledgment message will be as follows:
– Header <0x02><0x01><12514><101><0>
– Tail <0><0><0x03>
Acknowledgement Message Type
The ACK message is the header’s mirror and the received message’s tail. This means that upon reception of the telegram for each peer, the first action is to send the message back.
Note: the header message values are equal to the source message
Message Example:
An acknowledgment message will be as follows:
– Header <0x02><0x01><12514><101><5>
– Tail <0><0><0x03>
Pixel Data Message Type
This packet’s size varies depending on the number of pixels to be driven. The pixel length field indicates the number of pixels to control.
The pixel data is structured as the following:
Pixel Data Telegram
Message Example:
A four-pixel data message will be as follows:
– Header <0x02><0x01><196531><102><5>
– Pixel Data <0x7FEECCAA><0x7FEECCAA><0x7F44CDAF><0x7FBBA08A> – Tail <0><0><0x03>
Message Exchange Sequence
The client software needs to account for message losses due to connection loss. The host, however, will keep the latest status of the LEDs when correct data is received. In case of errors in the Pixel data, the host changes its state.
The client needs to keep messages in a buffer to re-send the data in case of network loss. The host sends an ACK message to inform the client that the data is received correctly. At this stage, the client sends the new data string.
In the LED application, the client might not necessarily keep buffering data. It might want to send the new data instead.
Particular attention should be made when controlling a led string. Sending strings faster than 30 frames per second would make no sense since the human eye cannot tell the difference at a higher rate. Therefore, in the case of sending messages, the string messages should be sent at a fixed rate, not faster than 30 frames per second.
Summary
This case presented an exciting and fun project. We explained the need for such solutions and showed an easy interface to implement. This example can be generalized to any project. The interface can be utilized to communicate with barcode tunnel scanners; please navigate to the Control Design for a sorting system case study to explore barcode tunnel scanners.
Control Design for a Sorting System
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
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 below.
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 below.
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:
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.
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!