Implementation of RS-485 and TCP/IP Communication

Study Case Implementation of RS-485 and TCP/IP Communication with Modbus RTU and Modbus TCP Protocols in Pick-by-Light Systems Michael Kurniawan (2018123456) University of Cincinnati, 2600 Clifton Ave, Cincinnati, OH 45221, United States kurniaml@mail.uc.edu Abstract Modern industrial processes demand high levels of productivity in every operational activity. One example is the process of picking goods in storage areas. In conventional systems, operators search for and pick items manually based on a list, which can result in long picking times or errors in selecting items. This study aims to design a pick-bylight system based on RS-485 serial communication and TCP/IP using the Modbus protocol to improve production process efficiency. The pick-by-light system consists of light indicators to mark items to be picked, buttons to confirm picking, and data processing units. Test results show that the system works well using RS-485 serial communication with the Modbus RTU protocol and TCP/IP communication with the Modbus TCP protocol. Testing was conducted by comparing the two types of communication. Thus, this system has the potential to be applied in the manufacturing and warehousing sectors in the United States to improve efficiency and productivity in the item retrieval process. Keywords: pick-by-light; RS-485; TCP/IP; Modbus RTU; Modbus TCP. INTRODUCTION The manufacturing and logistics industries require efficient and effective work systems to support high productivity. One important activity is the goods picking system in warehouses. In conventional systems, operators search for the location of goods manually based on a list, which often causes delays and reduced productivity. MICHAEL KURNIAWAN 1 Study Case To overcome this, this study proposes a pick-by-light system that provides visual guidance in the form of indicator lights at the item storage location [1]. This approach can improve accuracy and speed up item retrieval [2]. The main objective of this study is to implement the Modbus RTU and Modbus TCP protocols in a pick-by-light system with RS-485 and TCP/IP communication. The pick-by-light system consists of two main components: software (application) that sends commands, and hardware that provides signals to the operator. The hardware includes a data processor (controller), LED lights as indicators, and a confirmation button for picking items [3]. The number of LEDs and buttons can be adjusted according to the number of storage locations. This research focuses on the design of hardware that includes one data processing unit that functions as a concentrator and four LED units and buttons placed in a control box. This system uses a closed-loop control approach [4]. The communication interface between the software and hardware uses RS-485 and TCP/IP. Data exchange is regulated through the Modbus protocol, where Modbus RTU is used for RS-485 serial communication, while Modbus TCP is used for TCP/IP-based communication. RS-485 (or EIA/TIA-485 Standard for Electrical Characteristics of Generators and Receivers for use in a Balanced Digital Multipoint System) is an industrial serial communication standard established by the Electronics Industries Association (EIA) in 1983 [5]. This protocol operates on the physical layer and is capable of transmitting data up to 1.2 km with a one-to-many configuration, allowing up to 32 devices to be connected in a single line without a common ground reference [6]–[9]. RS-485 uses a balanced transmission method, which converts TTL signals into voltage differences between outputs A and B to minimize noise [10]. This voltage difference remains stable because noise interference affects both lines simultaneously [8]. RS-485 was chosen because of its low cost, ability to connect many devices, resistance to interference, and long transmission range [11]. The network topology used is a daisy chain, where each slave is connected sequentially to the master via a single line. Modbus is an open-source industrial communication protocol and international standard that supports various interface media with simple and efficient characteristics [12]. Modbus was first developed by Modicon in 1979 for use in Programmable Logic Controllers (PLCs) [13]. In a Modbus system, the device that sends commands is called the master, while the receiver is called the slave. The master sends a query containing a function code and data, while the slave responds with a data message (response message) or exception code if an error occurs. MICHAEL KURNIAWAN 2 Study Case Figure 1. Master and Slave Transaction Process in Modbus. Figure 2. Modbus RTU Frame Format. he function code determines the type of operation to be performed by the slave. Each code has a different function depending on the data type (discrete or analog) and the type of operation (read/write). Data is stored in registers and coils with different addresses. The Modbus function code list is shown in Table 1. Table 1. Modbus Function Codes Modbus RTU (Remote Terminal Unit) is a variant of Modbus used for serial communication and operates on the Data Link layer of the OSI model, while the physical layer uses RS-485 or RS-232 [14]. The Modbus RTU frame consists of a start bit, slave ID, function code, data, Cyclic Redundant Check (CRC), and end bit as shown in Figure 2. MICHAEL KURNIAWAN 3 Study Case The advantage of Modbus RTU is its high efficiency in data transfer, as it can send more information at the same baud rate [15]. Each data transmission has a delay time of between 1.5 and 3.5 characters, depending on the baud rate used [16]. Meanwhile, Modbus TCP is a version of Modbus that uses TCP/IP communication over an Ethernet network. This protocol runs on the application layer of the TCP/IP model to represent data [17]. Modbus TCP encapsulates standard Modbus frames into TCP frames without a checksum, using the Modbus Application Protocol (MBAP) and Protocol Data Unit (PDU) structures [18]. In Modbus TCP, the communication model used is client/server, where the master acts as the client and the slave acts as the server. METHODS AND MATERIALS This research began with field observations to analyze system requirements, including functional and non-functional requirements, as well as hardware and software specifications. The next stage was system design, including the creation of architecture, block diagrams, circuit schematics, and device designs. The devices used included an ATmega2560-based Arduino Mega Pro Mini, a Wiznet W5500 Ethernet module for converting serial communication to Ethernet, an RS-485 module for industrial serial communication, and an Illuminated Push Button that functions as both a button and an LED indicator. The software used consists of Arduino IDE for programming, Modbus Poll as a Modbus simulator, and Autodesk Eagle for PCB design. The developed system architecture consists of a desktop application as a master/client that manages item retrieval data, a concentrator device as a slave/server, and a control box containing buttons and LEDs. The focus of this research is the design and manufacture of the concentrator and control box, as shown in Figure 3. Figure 3. System Architecture. MICHAEL KURNIAWAN 4 Study Case In the concentrator, there is a microcontroller that reads commands from the master/client, regulates the LED status, and reads button signals. Other components used include an RS-485 module, an Ethernet module, a voltage regulator, an isolated digital input circuit, and a digital output circuit. The power supply required for the concentrator is 9–12 volts DC, while the LEDs require 12–24 volts DC. The connection between the concentrator and the control box uses UTP cable. The system block diagram can be seen in Figure 4. Figure 4. System Block Diagram. After the block diagram is complete, the next step is to create a schematic to be implemented into a PCB that connects all the electronic components. Figure 5 shows the concentrator circuit schematic. In the Arduino program, the device reads queries from the master/client. If an error occurs, the system will send an exception error message; otherwise, the command is executed according to the function code and data received. Testing was conducted to measure communication performance with single read/write (reading or writing one data) and multiple read/write (reading or writing several data simultaneously) functions. RESULTS AND DISCUSSION System testing was conducted through four main stages, namely: 1. RS-485 serial communication using the Modbus RTU protocol, 2. TCP/IP communication using the Modbus TCP protocol, 3. multiple point (multi-device) testing, and 4. overall system integration testing. MICHAEL KURNIAWAN 5 Study Case RS-485 Serial Communication The first stage of testing was conducted using the Modbus RTU protocol on RS-485 serial communication with a single read function. The master device used the Modbus Poll application, the concentrator acted as the slave, and the Serial Port Monitor application was used to monitor the data sent. In the single read function, the master sent a query to the slave to request a specific piece of data, then the slave returned the requested data. The single read testing process is shown in Figure 6. Figure 5. Concentrator Circuit Schematic Figure 6. Modbus RTU Single Read Testing Process Based on Figure 6, the master sends a query in the form of a command to read one data on coil 0 from the slave with address 01. When the button on the control box is pressed, the concentrator as the slave detects the button press and sends the data to the master. MICHAEL KURNIAWAN 6 Study Case The data sent by the slave consists of six bytes in hexadecimal format, called the Application Data Unit (ADU). The ADU structure consists of a Slave ID, Protocol Data Unit (PDU) (which contains the function code and data), and Cyclic Redundant Check (CRC). The details are: 1. First byte: 01 → Slave ID, 2. Second byte: 02 → Function code (read input status), 3. Third byte: 01 → Coil address, 4. Fourth byte: 01 → Coil status, 5. Fifth–sixth bytes: 60 48 → CRC. TCP/IP Communication The second test was conducted using TCP/IP communication with the Modbus TCP protocol. In this stage, the client device (using the Modbus Poll application) interacted with the concentrator, which acted as the server. The Wireshark application was used to analyze the data transmitted between devices. The function tested was multiple write, where the client sent a command to turn on four LEDs simultaneously. This testing process is shown in Figure 7. Figure 7. Modbus TCP Multiple Write Testing Process Based on Figure 7, the client sends a query containing a command to turn on four LEDs through the multiple write function with data placed on coils 12, 13, 14, and 15. The data is received by the concentrator (server), which then turns on the LEDs according to the command. The data transmission process occurs through encapsulation stages at each layer of the communication protocol, which are represented by different colors in the diagram: 1. Red: Modbus Protocol Data Unit (PDU) (contains function code and data), 2. Green: Modbus TCP Frame (with additional Unit Identifier), MICHAEL KURNIAWAN 7 Study Case 3. Blue: TCP Frame (adding the source and destination port numbers; the default server port is 502), 4. Orange: IP Frame (adding the source and destination IP addresses, for example 192.168.137.8 as the server address), 5. Gray: Ethernet Frame (adding the source and destination Ethernet physical addresses). Multiple Point Communication The third stage is multiple point testing using RS-485 communication involving one master and three slaves. The Modbus Poll application functions as the master, while three Arduino devices are used as slaves. The distance between slaves is set at 10 meters, so that the total distance from the master to the farthest slave reaches 30 meters. The Serial Monitor on the Arduino IDE is used to monitor the data received by each slave. The test results are shown in Figure 8. Figure 8. Multiple Point Communication Testing Based on Figure 8, the master sends a query containing data 1 to coil 3 of the slave device with ID 2. As a result, only the slave with ID 2 receives and displays the data on the Serial Monitor, while the slaves with IDs 1 and 3 do not respond because their addresses are different. This shows that the multiple point communication system works correctly, where each slave only processes commands that match its ID. Integration Testing The final stage is testing the integration of the entire system, where the desktop application functions as the master that manages item data, the concentrator acts as the slave, and the control box is used to display the LED status and input buttons. This test uses RS-485 serial communication with the Modbus RTU protocol. The integration test diagram is shown in Figure 9. MICHAEL KURNIAWAN 8 Study Case Figure 9. Pick-by-Light System Integration Test In this scenario, the master sends a command to turn on LED 1 and LED 2, which mark the location of the item to be picked. The system successfully turns on the LEDs at the appropriate locations and displays the status of items that have not been picked in the desktop application. The operator then goes to the location of the lit LEDs, picks the items, and presses the confirmation button on the control box. After the button is pressed, the slave changes the status of the related coil, then the master reads the status and sends a command to turn off the LEDs, indicating that the items have been picked. The status on the desktop application also changes to “picked.” CONCLUSION Based on a series of tests that have been conducted, it can be concluded that this research has successfully designed and implemented RS-485 serial communication with the Modbus RTU protocol and TCP/IP communication with the Modbus TCP protocol in the pick-by-light system. The developed system is capable of providing visual indications to the operator through LEDs that light up as a sign that the item must be picked, and automatically updates the status after confirmation. For future development, this system can be expanded with the application of wireless communication modes such as LoRa that still use the Modbus protocol, so that the flexibility and range of the system can be increased. MICHAEL KURNIAWAN 9 Study Case REFERENCE MICHAEL KURNIAWAN 10