Taking the RENESAS Modbus RTU solution as an example, this article explains the complete communication process of Modbus RTU.
(Image courtesy of RENESAS)
Overall Bus Topology
1 master device (PLC / Raspberry Pi) + multiple slave devices (temperature and humidity transmitters and other field devices). The system adopts an RS485 half-duplex differential bus. Only the master device can actively send commands, while slave devices can only respond passively, following the standard request-response communication mechanism.
Basic Modbus UART Serial Port Parameters
(Image courtesy of RENESAS)
1. Baud Rate: 19200 bps
2. Data Length
- Modbus ASCII: 7 bits
- Modbus RTU: 8 bits (Core difference! RTU transmits complete binary bytes)
3. Parity: Even parity (most commonly used for industrial temperature and humidity transmitters; no parity is also widely adopted in practical applications)
4. Stop Bit: 1 bit
5. Flow Control: No hardware flow control
Tech Tips: The serial port parameters of the master and all slave devices must be completely consistent; otherwise, normal communication cannot be established.
Modbus RTU identifies frame boundaries based on serial port timing, and the baud rate directly determines the critical time thresholds for frame recognition.
Overall Communication Process (Slave RTU Mode)
1. Idle State: The RS485 interface defaults to the receiving state (P31 low level). The master triggers transmission via a 1-second timer, and slaves continuously monitor the bus status.
2. Transmission Phase: The master or slave pulls the P31 pin high, and the UART outputs RTU binary frames with CRC checksum.
3. Reception Phase: Pull the P31 pin low to switch to the receiving state. The UART caches data byte by byte, and the TAU0 module monitors character intervals in real time.
4. Frame End Judgment: When the bus idle duration reaches no less than 3.5 character intervals, the system terminates data reception and transfers the data to the main loop for parsing.
5. Verification & Business Processing: Perform CRC check, address verification and function code verification, read and write local registers, and generate corresponding response frames.
6. Log Output: All transceiver frames, error records and callback events are printed as debug logs through the independent UARTA0 interface.
(Excerpted from RENESAS Modbus RTU Application Note)
Related Products
More Resources
Extended Technical Topics
- Why does a simple industrial control project require Modbus, CAN, and EtherCAT?
- Why CAN alone is insufficient, and a complete CANopen architecture is mandatory for motion control?
- Fundamentals of CANopen Motion Control Safety Procedures
- How Does EtherCAT Achieve Low Latency?
- EtherCAT Low-Latency Communication: Physical Layer Reference Circuit
- Modbus RTU Working Principle: Master-Slave Architecture and Polling Mechanism
- Modbus RTU Communication Process