Modbus RTU Guide: Frames, CRC and Register Values

Modbus RTU carries Modbus requests and responses as binary data over a serial link. A typical exchange contains a device address, a function code, data and a CRC-16 checksum.

This guide explains those fields, register addressing and byte order, then shows how to inspect captured frames. Use the device register map alongside the examples: supported functions, scaling and serial settings depend on the device.

0. Read and decode two registers first

You can start without hardware in the Modbus RTU tool. Select FC03, slave address 1, starting address 0 and quantity 2 to generate this request for two holding registers:

01 03 00 00 00 02 C4 0B

Address 0 is the offset carried in the frame. If a device manual uses holding-register reference numbers starting at 40001, reference 40001 maps to offset 0. Check the manual's numbering convention before subtracting anything; not every device table uses that notation.

If these two registers hold FLOAT32 value 1, with the high word first, an example response is:

01 03 04 3F 80 00 00 F7 CF

01 is the slave address, 03 the function, 04 the data-byte count, 3F 80 00 00 the register data, and F7 CF the CRC. Paste the complete frame into the RTU parser to check its structure and checksum. Then open those four bytes as FLOAT32 and confirm the value 1. This is a reproducible teaching response; your device's values and layout depend on its register map.

To read your own device, open the serial debugger:

1. In a desktop browser supporting Web Serial, select the serial port and authorize your adapter.
2. Match baud rate, data bits, parity and stop bits to the manual. Verify the slave address and that the requested registers exist.
3. Begin with one read. When sending the complete example manually, turn off Modbus Mode first, then enable HEX Mode without a text line ending. Regenerate the frame and CRC after changing its address or quantity.
4. Check the response address, function, byte count and CRC before interpreting type, word order, scaling and units. For a timeout, inspect serial settings, addressing, port ownership and wiring; a write command is not a connectivity test.

Port won't open, no response or unexpected values? Follow the RTU troubleshooting steps.

See Modbus Application Protocol, section 6.3 for FC03 addressing and response fields. RTU transmits the CRC's low byte first, as specified in the Serial Line Guide, section 2.5.1. Continue with the float and hex conversion guide for word swapping and floating-point precision.

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 Many industrial products provide a Modbus RTU interface. Verify the register map, supported functions and serial settings for each device.
• 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 a shared half-duplex bus. The node limit depends on transceiver unit loading, cabling and repeaters; 32 unit loads does not mean a universal limit of 32 slave devices.
• 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 Standard RTU uses 11 bits per character: T3.5 = 3.5 * 11 / baud rate seconds, or about 4.01 ms at 9600 baud. Above 19200 baud, the serial specification recommends fixed timers of 750 μs for T1.5 and 1.75 ms for T3.5. Check any device-specific serial format.

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 (Byte Swap Within Each 16-bit Word)

   • 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 (16-bit Word Swap)

   • 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

Use the ModbusKit tools to generate example frames and compare them with a capture and the device register map:

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

   • Use the CRC section on the RTU page to calculate a frame checksum. A matching CRC detects many transmission errors but does not authenticate a device or validate the meaning of register data.

4. Modbus Online Debugging Tool

   • Send requests and inspect serial responses in a compatible desktop browser with Web Serial. Select the port, grant permission and match the device settings first.

9. Common Problems and Solutions

Start with one read of registers documented for your device, with cyclic sending off. Keep the request, response and serial settings together. No received bytes, an invalid frame and a device exception need different checks.

9.1 Serial port unavailable or cannot open

1. Open the serial debugger over HTTPS in a desktop browser that supports Web Serial, such as Chrome. Loading the page alone does not establish browser support; see MDN's Web Serial requirements.
2. Click Select Serial Port, select your adapter and grant access. Cancelling the chooser does not grant access. The selection must follow a user action, as explained in the Chrome Web Serial guide.
3. If the adapter is absent, check that the operating system detects its serial port and that its driver is installed. If it is present but cannot open, close other serial terminals or browser tabs using that port, check the connection and select it again.
4. Match the device's serial settings and connect. A port-opening failure occurs before a Modbus exchange; MDN documents opening errors separately.

9.2 Request sent but no response

1. Confirm the port opened and the send log contains the intended bytes. For a complete RTU frame sent manually, turn off Modbus Mode, enable HEX Mode and add no text line ending. Use the generator after any request change.
2. Match baud rate, eight RTU data bits, parity and stop bits to the device. Check the configured slave address, its power and operating state. Use its individual address (1–247); address 0 is reserved for broadcasts, which do not return responses.
3. Check the adapter type, wiring, signal common and termination against the device and adapter manuals. RS-485 A/B labels can differ between vendors; compare terminal definitions. Ensure only one master initiates requests on the bus. See the Serial Line Guide, sections 2.1–2.2 and 3.
4. Read one documented register range and capture the exchange. If bytes arrive but the parser rejects them, use the frame checks below. Adjust a response wait only when the documented device timing or a capture shows a late response; a longer wait cannot fix a wrong address or CRC.

A timeout after a write does not prove the write failed. Stop and confirm the device state before considering another write; do not enable automatic write retries to test connectivity.

9.3 CRC or frame-format error

1. Copy one complete received frame, excluding timestamps and RX: labels. Keep requests and responses separate. A browser read chunk is not necessarily a whole RTU frame; inspect the capture for missing or joined bytes.
2. Paste the complete frame, including its final two CRC bytes, into the RTU parser. A length or structure error must be resolved before treating the data as a response. A matching CRC alone does not make its fields valid.
3. For an independent calculation, enter only the bytes before the CRC into the CRC calculator, then compare the result with the final two bytes in low-byte-first order. Follow the existing CRC guide; do not append a second checksum to an already complete frame.
4. If intact captures repeatedly fail, recheck serial settings, wiring, interference and bus timing. Change only one setting at a time, keeping both ends consistent. Never use values from a damaged frame.

9.4 Exception response: 83 02

A device at address 1 that rejects an FC03 register range can return this complete example frame:

01 83 02 C0 F1

Paste the five bytes into the RTU parser, or calculate the CRC of 01 83 02 in the CRC calculator. The CRC number is F1C0; the appended bytes are C0 F1. Here 02 is an exception code, not a register-byte count. The exception format and code are defined in the Modbus Application Protocol, sections 6.3 and 7.

First match the address and original function to the request you recorded. Then check FC03 versus FC04, the manual's reference-number or offset convention, and the entire requested range, including its last register. Use the address guide to correct the request and regenerate its CRC. A valid exception means the device reported a request problem; increasing the timeout will not correct that range. This is a reproducible example, not a capture from your device.

9.5 Normal response but wrong value

1. Verify frame structure, CRC, slave address, function and expected byte count. Match the response to the recorded request: a normal FC03 response does not repeat its starting register address.
2. Check the register area, address convention and register count against the manual. A FLOAT32 normally occupies two 16-bit registers; reading one gives only half the value.
3. Send only the register-data bytes to the data converter. Confirm signed or unsigned integer versus FLOAT32, then the documented byte and word order. A plausible-looking value from a guessed order is not verification.
4. Apply the documented multiplier, offset and unit. Compare against a known device value. Use the existing float and byte-order guide and its nine examples to check conversions without changing device settings.

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.