Modbus RTU Basic Tutorial: Learning Industrial Communication Protocol from Scratch

Modbus RTU (Remote Terminal Unit) is one of the most widespread and critical communication protocols in industrial automation. Its simplicity, open nature, and reliability have made it a cornerstone for connecting various industrial devices such as PLCs, DCSs, HMIs, sensors, and actuators. This tutorial aims to provide a systematic, from-scratch understanding of Modbus RTU protocol's core concepts, working principles, data interaction, and practical application techniques.

Whether you're a beginner or an engineer looking to solidify your foundation, this article will serve as a comprehensive guide.

1. What is Modbus RTU ?

Modbus RTU is a transmission mode within the Modbus protocol family, focusing on efficient data exchange over serial communication lines using a binary data format. It adheres to a Master-Slave communication model: typically, a Master device (e.g., PC or PLC) initiates requests, and one or more Slave devices (e.g., sensors or controllers) respond to these requests.

Key advantages of Modbus RTU include:

• Simple and Reliable The protocol structure is extremely streamlined, easy to understand, and implement in embedded systems, resulting in a low error rate.
• Open and Free The Modbus protocol is completely open and royalty-free, which has significantly contributed to its widespread adoption in industrial sectors.
• Broad Support The vast majority of industrial automation equipment on the market includes or supports Modbus RTU interfaces, ensuring excellent compatibility.
• Efficient Transmission It uses a compact binary format for data transmission, offering higher efficiency compared to Modbus ASCII mode.

2. Physical Layer: The Carrier of Modbus RTU

The Modbus RTU protocol itself defines only the structure of data messages, while the underlying physical connection relies on serial communication standards. The most common physical layer standards are:

2.1 RS-485

RS-485 is the most common choice for Modbus RTU in industrial applications, offering significant advantages:

• Multi-Point Communication Supports half-duplex multi-point communication, allowing one master to connect up to 32 slaves (extendable with repeaters).
• Long Transmission Distance Standard transmission distance can reach up to 1200 meters.
• Strong Anti-Interference Capability Uses differential signal transmission, providing excellent common-mode noise rejection, suitable for harsh industrial environments.
• Simple Wiring Typically uses two twisted-pair wires (A and B lines) for connection.

2.2 RS-232

RS-232 is an older serial communication standard that can also support Modbus RTU:

• Point-to-Point Communication Only supports full-duplex point-to-point communication, meaning one master can connect to only one slave.
• Short Transmission Distance Transmission distance is usually limited to 15 meters.
• Weak Anti-Interference Capability Uses non-differential signal transmission, making it susceptible to noise.
• Usage Often used for short-distance direct connection or debugging between devices and local computers.

2.3 Modbus RTU over TCP/IP (Network Passthrough)

With the development of the Industrial Internet of Things (IIoT), more and more manufacturers are transmitting the traditional Modbus RTU protocol over TCP/IP networks. This method is known as "Modbus RTU over TCP" or "Modbus RTU Network Passthrough." This implementation is very common in industrial settings, primarily in two application scenarios:

2.3.1 Devices with Direct Network Capabilities

Some modern industrial devices (such as smart sensors, variable frequency drives, PLCs, etc.) directly integrate Ethernet interfaces, allowing them to encapsulate the original Modbus RTU data frames within TCP/IP packets for transmission:

• Advantages Devices connect directly to the enterprise network, eliminating the need for additional conversion equipment.
• Transmission Distance Virtually unlimited, enabling remote communication over the internet.
• Multi-Master Support TCP/IP characteristics allow multiple masters to simultaneously access the same slave device.
• Application Scenarios Remote monitoring, cloud data acquisition, distributed control systems.

2.3.2 Serial-to-Network Devices (Passthrough Modules)

For traditional Modbus RTU devices that lack network capabilities, networking can be achieved through specialized serial-to-network devices (such as serial servers, DTUs, gateways, etc.):

• Working Principle A passthrough device connects to traditional RS-485/RS-232 serial devices on one side and to an Ethernet network on the other, transparently transmitting serial data over the network.
• Device Types
  • Serial Servers Professional industrial-grade devices supporting multiple serial ports, protocol conversion, and other functions.
  • DTU (Data Transfer Unit) Often supports 4G/WiFi and other wireless networks, suitable for remote or mobile scenarios.
  • Industrial Gateways Integrate various protocol conversion functions, supporting Modbus RTU/TCP, OPC UA, etc.
• Configuration Requirements Requires configuring the device's IP address, port number, serial parameters (baud rate, data bits, etc.).
• Application Advantages
  • Cost-Effective No need to replace existing equipment, only add conversion devices.
  • Flexible Deployment Field devices can be connected to enterprise networks or cloud platforms.
  • Centralized Management Enables centralized monitoring and management of devices over the network.

2.3.3 Technical Characteristics and Considerations

Data Frame Format

• Modbus RTU over TCP retains the original Modbus RTU data frame format (including CRC checksum).
• The data frame is fully encapsulated within a TCP packet without any modification.
• Unlike the standard Modbus TCP protocol, Modbus TCP uses an MBAP header instead of a CRC checksum.

Timing Requirements

• The concept of the traditional serial T3.5 inter-frame silent interval does not apply to network transmission.
• Passthrough devices typically handle frame segmentation and reassembly.
• It is important to consider the impact of network latency on communication timing.

Practical Application Advice

• Choose Appropriate Passthrough Device Select wired or wireless, single-serial or multi-serial devices based on the field environment.
• Network Planning Plan IP addresses and ports reasonably to avoid conflicts.
• Security Considerations When transmitting over the internet, it is recommended to use VPNs or other encryption methods to protect data security.
• Compatibility Testing Thoroughly test the compatibility between the master software and the passthrough device before formal deployment.

3. Modbus Data Model: Understanding Data Storage Structure

Before diving into the protocol structure, it's crucial to understand how Modbus organizes and stores device data. The Modbus protocol abstracts the device's internal data into four logically independent data tables with non-overlapping address spaces. Each table stores different types of data and has specific access permissions.

Important Notes:

• PLC addresses are commonly used in industrial automation (1-based addressing), while Modbus protocol addresses are the actual addresses used in communication (0-based addressing). The conversion relationship is Modbus protocol address = PLC address - base address (e.g., 40001, 30001). For example, reference address 40003 corresponds to protocol offset address 0x0002 (40003-40001).
• Coils and Discrete Inputs are bit-level operations, while Holding Registers and Input Registers are word-level (16-bit) operations.
• Each table has its own independent address space; for example, Coil 0x0001 is distinct from Holding Register 0x0001.

4. Protocol Fundamentals: Modbus RTU Data Frame

A standard Modbus RTU data frame (or message) is the basic unit of communication between a master and a slave. It consists of the following key parts:

4.1 Data Frame Format Overview

[Slave Address] [Function Code] [Data Field] [CRC Checksum]
    1 byte         1 byte         N bytes      2 bytes

4.1.1 Slave Address - 1 byte

• Purpose Uniquely identifies the target slave device on the network.
• Range Typically 1-247.
  • 0 is the broadcast address, sent to all slaves, but slaves do not respond.
  • 248-255 are reserved addresses.
• Requirement Each slave device in a Modbus network must be configured with a unique address.

4.1.2 Function Code - 1 byte

• Purpose Defines the type of operation the master wants the slave to perform (e.g., read data, write data).
• List of Most Common Function Codes

4.1.3 Data Field - Variable Length

• Purpose Contains specific information required to perform a particular function, such as the starting address, quantity to read or write, values to write, etc.
• Length Varies depending on the function code.
  • Read requests typically include a starting address and quantity.
  • Write requests typically include a starting address and the value(s) to write.

4.1.4 CRC Checksum - 2 bytes

• Purpose Provides data integrity verification, used to detect if errors occurred during transmission.

• Algorithm Modbus RTU uses the CRC-16 algorithm.

  • The sender calculates the CRC value for all bytes from the slave address to the end of the data field and appends it to the end of the frame (low byte first, high byte second).
  • Upon receiving the data frame, the receiver performs a CRC calculation on the received data (excluding the received CRC) in the same manner.
  • If the calculated result does not match the received CRC value, the data transmission is considered erroneous, and the slave typically discards the frame without processing or returns an error.

• Example Code

WORD CRC16 (const BYTE *data, WORD length)
        {
        static const WORD table[] = {
        0X0000, 0XC0C1, 0XC181, 0X0140, 0XC301, 0X03C0, 0X0280, 0XC241,
        0XC601, 0X06C0, 0X0780, 0XC741, 0X0500, 0XC5C1, 0XC481, 0X0440,
        0XCC01, 0X0CC0, 0X0D80, 0XCD41, 0X0F00, 0XCFC1, 0XCE81, 0X0E40,
        0X0A00, 0XCAC1, 0XCB81, 0X0B40, 0XC901, 0X09C0, 0X0880, 0XC841,
        0XD801, 0X18C0, 0X1980, 0XD941, 0X1B00, 0XDBC1, 0XDA81, 0X1A40,
        0X1E00, 0XDEC1, 0XDF81, 0X1F40, 0XDD01, 0X1DC0, 0X1C80, 0XDC41,
        0X1400, 0XD4C1, 0XD581, 0X1540, 0XD701, 0X17C0, 0X1680, 0XD641,
        0XD201, 0X12C0, 0X1380, 0XD341, 0X1100, 0XD1C1, 0XD081, 0X1040,
        0XF001, 0X30C0, 0X3180, 0XF141, 0X3300, 0XF3C1, 0XF281, 0X3240,
        0X3600, 0XF6C1, 0XF781, 0X3740, 0XF501, 0X35C0, 0X3480, 0XF441,
        0X3C00, 0XFCC1, 0XFD81, 0X3D40, 0XFF01, 0X3FC0, 0X3E80, 0XFE41,
        0XFA01, 0X3AC0, 0X3B80, 0XFB41, 0X3900, 0XF9C1, 0XF881, 0X3840,
        0X2800, 0XE8C1, 0XE981, 0X2940, 0XEB01, 0X2BC0, 0X2A80, 0XEA41,
        0XEE01, 0X2EC0, 0X2F80, 0XEF41, 0X2D00, 0XEDC1, 0XEC81, 0X2C40,
        0XE401, 0X24C0, 0X2580, 0XE541, 0X2700, 0XE7C1, 0XE681, 0X2640,
        0X2200, 0XE2C1, 0XE381, 0X2340, 0XE101, 0X21C0, 0X2080, 0XE041,
        0XA001, 0X60C0, 0X6180, 0XA141, 0X6300, 0XA3C1, 0XA281, 0X6240,
        0X6600, 0XA6C1, 0XA781, 0X6740, 0XA501, 0X65C0, 0X6480, 0XA441,
        0X6C00, 0XACC1, 0XAD81, 0X6D40, 0XAF01, 0X6FC0, 0X6E80, 0XAE41,
        0XAA01, 0X6AC0, 0X6B80, 0XAB41, 0X6900, 0XA9C1, 0XA881, 0X6840,
        0X7800, 0XB8C1, 0XB981, 0X7940, 0XBB01, 0X7BC0, 0X7A80, 0XBA41,
        0XBE01, 0X7EC0, 0X7F80, 0XBF41, 0X7D00, 0XBDC1, 0XBC81, 0X7C40,
        0XB401, 0X74C0, 0X7580, 0XB541, 0X7700, 0XB7C1, 0XB681, 0X7640,
        0X7200, 0XB2C1, 0XB381, 0X7340, 0XB101, 0X71C0, 0X7080, 0XB041,
        0X5000, 0X90C1, 0X9181, 0X5140, 0X9301, 0X53C0, 0X5280, 0X9241,
        0X9601, 0X56C0, 0X5780, 0X9741, 0X5500, 0X95C1, 0X9481, 0X5440,
        0X9C01, 0X5CC0, 0X5D80, 0X9D41, 0X5F00, 0X9FC1, 0X9E81, 0X5E40,
        0X5A00, 0X9AC1, 0X9B81, 0X5B40, 0X9901, 0X59C0, 0X5880, 0X9841,
        0X8801, 0X48C0, 0X4980, 0X8941, 0X4B00, 0X8BC1, 0X8A81, 0X4A40,
        0X4E00, 0X8EC1, 0X8F81, 0X4F40, 0X8D01, 0X4DC0, 0X4C80, 0X8C41,
        0X4400, 0X84C1, 0X8581, 0X4540, 0X8701, 0X47C0, 0X4680, 0X8641,
        0X8201, 0X42C0, 0X4380, 0X8341, 0X4100, 0X81C1, 0X8081, 0X4040 };

    BYTE temp;
    WORD word = 0xFFFF;
    while (length--)
    {
        temp = *data++ ^ word;
        word >>= 8;
        word  ^= table[temp];
    }
    return word;
}

4.1.5 Inter-frame Silent Interval (T3.5)

• Importance This is a crucial feature in the Modbus RTU protocol used to determine the start and end of a data frame.
• Definition In Modbus RTU mode, the transmission of a data frame must end with a silent interval of at least 3.5 character transmission times. When the receiver detects a continuous silence of 3.5 characters, it considers the previous frame to be completely received. Similarly, the beginning of a new frame must be preceded by a silent interval of 3.5 characters.
• Purpose
  • Frame Synchronization Ensures the receiver can accurately identify frame boundaries, avoiding issues like "sticky packets" or truncated frames.
  • Error Detection If the silent interval between two characters exceeds 1.5 characters but is less than 3.5 characters, it is considered a transmission error (possibly indicating a truncated frame).
• Calculation T3.5 = (3.5 * 10 bits / baud rate) seconds (each character typically includes 1 start bit + 8 data bits + 1 stop bit = 10 bits). For example, at 9600 bps, T3.5 is approximately 3.64 milliseconds.

5. Exception Responses: Error Handling Mechanism

When a master sends a valid request to a slave that the slave cannot process (e.g., requesting to read a non-existent register address, or a data value is out of range), the slave will not return a normal response. Instead, it will return an exception response frame.

5.1 Exception Response Frame Format

[Slave Address] [Function Code + 0x80] [Exception Code] [CRC Checksum]
    1 byte              1 byte               1 byte          2 bytes

• Function Code + 0x80 The flag for an exception response. The slave sets the most significant bit of the original request's function code to 1 (i.e., the original function code is bitwise ORed with 0x80), indicating to the master that this is an exception response. For example, if the requested function code was 0x03, the exception response function code will be 0x83.
• Exception Code A single byte indicating the specific type of error.

5.2 Common Exception Codes and Their Meanings

6. Practical Application Examples: In-depth Understanding of Communication Flow

Through specific command and response examples, we can better understand how Modbus RTU works.

6.1 Example 1: Reading Temperature Sensor Data (Function Code 0x03 - Read Holding Registers)

Assume we have a temperature sensor with address 1, and its current temperature value is stored in Holding Register address 40001 (Modbus RTU protocol offset address 0x0000). We want to read the value of this one register.

Send Command (Master -> Slave)

01 03 00 00 00 01 84 0A

Command Analysis:

• 01 Slave address is 1.
• 03 Function code is 3 (0x03), indicating reading holding registers.
• 00 00 Starting register address is 0x0000 (corresponding to Modbus reference address 40001).
• 00 01 Request to read 1 register.
• 84 0A CRC-16 checksum.

Device Response (Slave -> Master)

01 03 02 00 64 B9 30

Response Analysis:

• 01 Slave address is 1.
• 03 Function code is 3 (0x03), normal response.
• 02 Number of data bytes, indicating the following data contains 2 bytes (because 1 16-bit register was read, which is 2 bytes).
• 00 64 Actual data read. 0x0064 converts to decimal 100.
• B9 30 CRC-16 checksum.

Result The master successfully read the temperature value as 100 (could be Celsius, Fahrenheit, or an integer with decimals, depending on device conventions).

6.2 Example 2: Setting Output Coil Status (Function Code 0x05 - Write Single Coil)

To set the output coil (Coil) address 00001 (Modbus RTU protocol offset address 0x0000) of a device with address 2 to ON.

Send Command (Master -> Slave)

02 05 00 00 FF 00 8C 3A

Command Analysis:

• 02 Slave address is 2.
• 05 Function code is 5 (0x05), indicating writing a single coil.
• 00 00 Coil address is 0x0000 (corresponding to Modbus reference address 00001).
• FF 00 Value to write. 0xFF00 means setting the coil to ON, 0x0000 means setting it to OFF.
• 8C 3A CRC-16 checksum.

Device Response (Slave -> Master)

02 05 00 00 FF 00 8C 3A

Response Analysis:

• For function code 0x05, the slave's normal response is to echo the received request frame back to the master, confirming the operation was successful.
• 02 Slave address is 2.
• 05 Function code is 5.
• 00 00 Coil address is 0x0000.
• FF 00 Confirms the coil was set to ON.
• 8C 3A CRC-16 checksum.

Result The slave's coil 00001 was successfully set to the ON state.

7. Data Types and Byte Order: Handling Complex Data

Modbus RTU uses 16-bit (2-byte) registers as its basic data storage unit. However, real-world industrial applications often require transmitting more complex data types, such as 32-bit integers or floating-point numbers. This introduces the issues of data type conversion and byte order.

7.1 Common Data Types in Modbus Representation

7.2 Byte Order and Word Order Issues

When a data type requires two or more registers (e.g., 32-bit integers, floating-point numbers), the arrangement order of these registers in the Modbus protocol, as well as the byte order within each register, becomes crucial. Different device manufacturers may use different byte and word orders, which is often the primary cause of communication data parsing errors.

Suppose we have a 32-bit value 0x12345678, which occupies two 16-bit registers:

• Register A stores 0x1234
• Register B stores 0x5678

Here are some common byte and word order combinations:

1. ABCD (Big-Endian)

   • Word Order High-order word first (Register A, Register B) -> 0x1234 0x5678
   • Byte Order High-order byte first within each word -> 12 34 56 78
   • Common in Modicon, Siemens, older Rockwell, etc.
   • Storage Order Most significant byte -> Least significant byte (left to right)

2. DCBA (Little-Endian)

   • Word Order Low-order word first (Register B, Register A) -> 0x5678 0x1234
   • Byte Order Low-order byte first within each word -> 78 56 34 12
   • Common in Intel/PC architectures, some Japanese PLCs
   • Storage Order Least significant byte -> Most significant byte (left to right)

3. BADC (Swapped Big-Endian)

   • Word Order High-order word first (Register A, Register B) -> 0x1234 0x5678
   • Byte Order Low-order byte first within each word -> 34 12 78 56
   • Storage Order Least significant byte (word 1) -> Most significant byte (word 1) -> Least significant byte (word 2) -> Most significant byte (word 2)

4. CDAB (Swapped Little-Endian)

   • Word Order Low-order word first (Register B, Register A) -> 0x5678 0x1234
   • Byte Order High-order byte first within each word -> 56 78 12 34
   • Storage Order Most significant byte (word 2) -> Least significant byte (word 2) -> Most significant byte (word 1) -> Least significant byte (word 1)

Solutions

• Consult Device Manual Always prioritize consulting the slave device's communication manual, which will explicitly state the data types and byte order used.
• Test with Online Tools When manual information is unclear, use a Modbus debugging tool to try different byte order combinations until data parsing is correct.
• Program Logic Handling In your host or master program, perform corresponding byte or word swap operations according to the slave's byte order requirements.

8. Practical Practice with Online Tool Modbus RTU

While theoretical learning is important, hands-on practice is the best way to master Modbus RTU. We highly recommend using the Modbus online tool for learning and debugging:

1. Modbus RTU Command Generator

   • Automatically generates Modbus RTU standard request command frames (including CRC checksum) based on parameters such as slave address, function code, starting address, and quantity.
   • Ideal for verifying the correctness of your manually constructed commands.

2. Modbus RTU Data Parser

   • Enter a hexadecimal Modbus RTU response data frame, and the tool will automatically parse the slave address, function code, data content, and CRC checksum result.
   • Supports parsing various data types (e.g., UINT16, INT16, UINT32, FLOAT32) and byte orders (ABCD, DCBA, BADC, CDAB), helping you verify the correctness of data read from the device.

3. CRC Calculator

   • Specifically used to calculate the CRC-16 checksum for Modbus RTU messages, ensuring data packet integrity.

4. Modbus Online Debugging Tool

   • Simulates master functionality, communicating in real-time with actual Modbus devices, sending requests and receiving responses—an invaluable tool for on-site debugging.

9. Common Problems and Solutions

In practical Modbus RTU applications, you may encounter some common issues. Understanding their causes and solutions can significantly improve debugging efficiency.

9.1 Communication Timeout

Symptom The master sends a request but does not receive a response from the slave within the set time.

Common Causes

• Baud rate, data bits, stop bits, parity and other serial port parameters are mismatched.
• Incorrect slave address, the address requested by the master does not match the actual slave address.
• Slave device is not powered on, not started, or faulty.
• Wiring errors (RS-485 A/B lines reversed, incorrect RS-232 wiring).
• Missing or incorrect termination resistors in the RS-485 network, leading to signal reflection.
• T3.5 inter-frame silent interval control is imprecise, causing the slave to misinterpret frame end.

Solutions

• Verify all serial communication parameters of both master and slave, ensuring they are identical.
• Verify slave address configuration is correct and avoids conflicts.
• Check slave status Confirm the slave is powered on and operating normally.
• Check physical wiring Use a multimeter to check if A/B lines are correct and contact is good.
• RS-485 termination resistors Connect a 120-ohm termination resistor at each end of the bus (the two furthest devices).
• Increase timeout period During debugging, appropriately increase the master's timeout waiting period to rule out issues caused by slow responses.

9.2 CRC Checksum Failure

Symptom The received data frame fails CRC validation.

Common Causes

• Errors during data transmission Line interference, electromagnetic noise, excessive transmission distance, excessively high baud rate.
• Incorrect CRC algorithm implementation on the master or slave side. Although Modbus RTU CRC-16 is a standard algorithm, implementation details can still cause calculation mismatches.
• Data frame truncated or extra bytes inserted Hardware or software issues leading to incomplete frames.

Solutions

• Check cable connections Ensure good cable quality, effective grounding of the shield, and avoid parallel routing with power cables.
• Reduce communication speed Try reducing the baud rate to see if it resolves CRC errors.
• Use standard CRC-16 algorithm Confirm that the CRC-16 algorithm used in master and slave programs is the Modbus standard (polynomial 0xA001 or reversed 0x8005).
• Isolate interference sources Eliminate devices that might cause interference.

9.3 Data Parsing Errors (Incorrect Values)

Symptom

A slave response is successfully received, but the parsed data does not match expectations (for example, temperature values appear as gibberish or incorrect large numbers).

Common Causes

• Byte Order or Word Order Configuration Errors This is the most common issue, especially when dealing with 32-bit data (UINT32, INT32, FLOAT32).
• Incorrect Data Type Selection For example, parsing a floating-point number as an integer, or a signed number as an unsigned number.
• Incorrect Register Address Mapping The requested register address does not match the actual data address defined in the device manual.
• Unprocessed Data Scaling or Offset The device might output raw ADC values that require calculations to obtain actual physical quantities.

Solutions

• Consult the Device Manual Strictly follow the device manual to confirm data types, the number of registers occupied, byte order, and word order.
• Experiment with Different Byte Order Combinations Use an online Modbus tool or debugging software to test all possible byte order combinations like ABCD, DCBA, BADC, CDAB until the data displays correctly.
• Confirm Data Type Ensure the master uses a data type consistent with the slave for parsing.
• Verify Register Addresses Ensure the requested register addresses are correct and correspond to the device's specific data points.
• Process Scaling/Offset If the device outputs raw values, incorporate the appropriate conversion formulas into the master program.

10. Advanced Learning Recommendations

Mastering Modbus RTU is merely the starting point for industrial communication. To become a more comprehensive automation engineer, it is advisable to delve deeper into the following topics:

1. Thorough Understanding of All Modbus Function Codes Familiarize yourself with their precise applications and data structures in various scenarios.
2. Mastering Exception Response Handling Logic Develop robust exception handling mechanisms in your programs to enhance system stability.
3. Exploring the Modbus TCP Protocol Understand its distinctions from Modbus RTU, its frame structure, and its applications within an Ethernet environment.
4. Learning about Modbus ASCII Mode While less commonly used than Modbus RTU, understanding the characteristics of its text-based format is beneficial.
5. Studying Industrial Communication Network Topologies Grasp advanced concepts such as RS-485 bus wiring specifications, termination resistors, and bias resistors.
6. Practicing Multi-Device Communication Management Learn how to communicate with multiple slave devices simultaneously within a Modbus network and how to optimize polling cycles.
7. Programming Modbus Master/Slave Implementations Attempt to write your own Modbus communication programs using Python, C++, Java, or PLC programming languages (e.g., Ladder Logic, Structured Text).

11. Conclusion

Modbus RTU, as the "common language" in industrial automation, continues to hold a crucial position due to its simplicity, efficiency, and open nature. Through the systematic study of this tutorial, you should have:

• A clear understanding of the fundamental concepts of Modbus RTU, the master-slave communication model, and the basics of its physical layer.
• Mastered the core Modbus data model (coils, discrete inputs, holding registers, input registers).
• Analyzed in depth the composition of a Modbus RTU data frame, including slave address, function code, data field, and CRC checksum.
• Learned how to identify and handle Modbus exception responses.
• Understood how to send requests and parse responses through concrete examples.
• Recognized the importance of data types and byte order, and learned how to resolve related issues.
• Gained knowledge of practical and debugging techniques using online tools.

Continue to maintain your curiosity, consistently practice, and keep learning. This will enable you to proficiently apply the Modbus RTU protocol in various industrial automation projects, constructing stable and reliable communication systems.