Machine Interface Example
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
| Acronym | Description |
|---|---|
| STX | Start of Text Charachter |
| STH | Start of Header Charachter |
| ETX | End of Text Charachter |
| PRG | Progressive number |
| MSG ID | Message ID |
| CCH | Comunication Channel |
| ACK | Acknowledgement |
| PLC | Programmable Logic Controller |
| LED | Light Emitting Diod |
| TCP | Transmission Control Protocol |
| IP | Internet Protocol |
| SPI | Serial Peripheral Interface |
| I2C | Inter-Integrated Circuit |
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.
| Channel | MSG ID | MESSAGE TYPE | MESSAGE DIRECTION |
|---|---|---|---|
| CCH | 101 | KEEPALIVE | From PLC to LED Controller |
| CCH | 102 | PIXEL_DATA | From PLC to LED Controller |
| CCH | 102 | ACK | From LED controller to PLC |
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.
| OFFSET | SIZE [BYTE] | TYPE | NAME | VALUE |
|---|---|---|---|---|
| 0 | 1 | ASCII CHAR | STX | 0x02 |
| 1 | 1 | ASCII CHAR | SOH | 0x01 |
| 2 | 2 | UNIT 16 | PRG | Packet Number |
| 4 | 2 | UNIT 16 | MSG_ID | Message ID |
| 6 | 2 | UNIT 16 | PIXEL_LEN | Pixel Length [N] |
| 8 | 2 | UNIT 16 | Plant Status code | 0 |
| 10 | 2 | UNIT 16 | Plant Status Code | 0 |
| 11 | 1 | ASCII CHAR | ETX | 0x03 |
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
| OFFSET | SIZE [BYTE] | TYPE | NAME | VALUE |
|---|---|---|---|---|
| 0 | 1 | ASCII CHAR | STX | 0x02 |
| 1 | 1 | ASCII CHAR | SOH | 0x01 |
| 2 | 2 | UNIT 16 | PRG | Packet Number |
| 4 | 2 | UNIT 16 | MSG_ID | Message ID |
| 6 | 2 | UNIT 16 | PIXEL_LEN | Pixel Length [N] |
| 8 | 2 | UNIT 16 | Plant Status code | 0 |
| 10 | 2 | UNIT 16 | Plant Status Code | 0 |
| 11 | 1 | ASCII CHAR | ETX | 0x03 |
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:
| Intensity [byte] | Red Scale [byte] | Green Scale [byte] | Blue Scale [byte] |
|---|---|---|---|
| [224 – 255] | [0] | (10-255] | [0] | (10-255] | [0] | (10-255] |
Pixel Data Telegram
| OFFSET | SIZE [BYTE] | TYPE | NAME | VALUE |
|---|---|---|---|---|
| 0 | 1 | ASCII CHAR | STX | 0x02 |
| 1 | 1 | ASCII CHAR | SOH | 0x01 |
| 2 | 2 | UNIT 16 | PRG | Packet Number |
| 4 | 2 | UNIT 16 | MSG_ID | Message ID |
| 6 | 2 | UNIT 16 | PIXEL_LEN | Pixel Length [N] |
| 8 | 4 | UNIT 32 | Pixel_1 | I_R_G_B |
| 12 | 4 | UNIT 32 | Pixel_2 | I_R_G_B |
| 16 | 4 | UNIT 32 | Pixel_3 | I_R_G_B |
| 22 | 4 | UNIT 32 | Pixel_4 | I_R_G_B |
| 4(N-1) +8 | 4 | UNIT 32 | Pixel_N | I_R_G_B |
| 4(N-1) +12 | 2 | UNIT 16 | Plant Status | 0 |
| 4(N-1) +14 | 2 | UNIT 16 | Plant Status | 0 |
| 4(N-1) +16 | 1 | ASCII CHAR | ETX | 0x03 |
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.