Modbus RTU communication in PLC Programming - Deep Dive

Overview - Modbus RTU communication

What is it?

Modbus RTU communication is a way for devices like sensors and controllers to talk to each other using a simple language over wires. It sends data in small packets called frames, using electrical signals on a serial line. This method is common in industrial machines to share information like temperature or motor speed. It works by one device asking questions and others answering, all in a strict order.

Why it matters

Without Modbus RTU, machines and sensors would struggle to share data reliably and simply, making automation slow and error-prone. It solves the problem of different devices needing a common language to work together, even if they come from different makers. This helps factories run smoothly, saving time and money by automating control and monitoring tasks.

Where it fits

Before learning Modbus RTU, you should understand basic serial communication and how devices connect physically. After mastering it, you can explore more advanced protocols like Modbus TCP/IP or learn how to program PLCs to automate complex processes using this communication.

Mental Model

Core Idea

Modbus RTU is a simple question-and-answer conversation between devices over a shared wire, using timed electrical signals to send data in small, organized packets.

Think of it like...

Imagine a group of people sitting around a campfire, where only one person talks at a time by asking a question, and the others answer in turn, making sure no one talks over each other.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Master      │──────▶│   Slave 1     │
│ (Asks Query)  │       │ (Answers)     │
└───────────────┘       └───────────────┘
         ▲                      ▲
         │                      │
         └──────────────────────┘
           Shared Serial Line

Timing controls who talks when, ensuring clear communication.

Build-Up - 8 Steps

1

Foundation

Basics of Serial Communication

Concept: Learn how devices send data one bit at a time over wires using serial communication.

Serial communication sends data bit by bit over a single wire pair. Each bit is a small electrical pulse representing 0 or 1. Devices agree on speed (baud rate) and format (start bit, data bits, parity, stop bits) to understand each other. This is the foundation for Modbus RTU.

Result

Devices can send and receive data reliably one bit at a time over a wire.

Understanding serial communication basics is essential because Modbus RTU builds on this to organize data into meaningful messages.

2

Foundation

Understanding Modbus RTU Frame Structure

Concept: Modbus RTU sends data in frames with a specific format including address, function, data, and error check.

A Modbus RTU frame starts with the slave address (who should answer), followed by a function code (what to do), data (parameters or values), and ends with a CRC error check to catch mistakes. Frames are separated by silent gaps to mark message boundaries.

Result

Data is packaged in a clear, repeatable format that devices can parse and verify.

Knowing the frame structure helps you decode messages and troubleshoot communication problems.

3

Intermediate

Master-Slave Communication Model

🤔Before reading on: do you think multiple devices can talk at the same time on Modbus RTU? Commit to yes or no.

Concept: Modbus RTU uses a master-slave model where only the master initiates communication and slaves respond.

In Modbus RTU, one device is the master that sends requests. Slaves listen and reply only when addressed. This avoids collisions on the shared wire. The master controls timing and order, ensuring smooth data exchange.

Result

Only one device talks at a time, preventing data clashes and confusion.

Understanding the master-slave model clarifies why timing and addressing are critical for reliable communication.

4

Intermediate

Timing and Silent Intervals Importance

🤔Before reading on: do you think Modbus RTU frames can be sent back-to-back without pauses? Commit to yes or no.

Concept: Modbus RTU requires silent intervals between frames to mark message boundaries and avoid confusion.

A silent gap of at least 3.5 character times signals the end of a frame. Devices use this pause to reset their receivers and prepare for the next message. Without this, frames could merge and cause errors.

Result

Clear separation of messages prevents data corruption and misinterpretation.

Knowing the role of timing gaps helps you understand why communication can fail if devices are too fast or slow.

5

Intermediate

Error Checking with CRC

Concept: Modbus RTU uses a Cyclic Redundancy Check (CRC) to detect errors in transmitted data.

Each frame ends with a 16-bit CRC value calculated from the frame's content. The receiver recalculates CRC and compares it to the sent value. If they differ, the frame is discarded or a retry is requested. This ensures data integrity over noisy wires.

Result

Errors caused by electrical noise or interference are detected and handled.

Understanding CRC error checking explains how Modbus RTU maintains reliable communication in industrial environments.

6

Advanced

Handling Multiple Slaves and Addressing

🤔Before reading on: do you think slave addresses can be any number or must follow rules? Commit to your answer.

Concept: Each slave device has a unique address between 1 and 247 to identify it on the network.

The master sends queries to specific slave addresses. Address 0 is reserved for broadcast messages to all slaves, which do not reply. Proper addressing avoids conflicts and ensures the right device responds. Address conflicts cause communication failures.

Result

Multiple devices can share the same wire without talking over each other.

Knowing addressing rules prevents network conflicts and helps design scalable systems.

7

Advanced

Common Function Codes and Their Uses

Concept: Modbus RTU defines function codes to specify actions like reading or writing data.

Function codes like 03 (read holding registers) or 06 (write single register) tell slaves what to do. Each code has a defined data format. Understanding these codes lets you read sensor values or control actuators through Modbus messages.

Result

You can perform useful operations by sending the right function codes.

Mastering function codes is key to using Modbus RTU for real automation tasks.

8

Expert

Dealing with Noise and Timing Variations

🤔Before reading on: do you think Modbus RTU communication always works perfectly on long cables? Commit to yes or no.

Concept: Real-world Modbus RTU networks face electrical noise and timing challenges that require careful design and troubleshooting.

Long cables and industrial environments cause signal degradation and noise. Devices may misinterpret bits or miss silent intervals. Using shielded cables, proper grounding, and repeaters helps. Also, configuring correct baud rates and timeouts prevents communication errors.

Result

Robust Modbus RTU networks maintain reliable data exchange despite harsh conditions.

Understanding physical and timing challenges prepares you to build and maintain stable industrial communication systems.

Under the Hood

Modbus RTU works by encoding data into electrical pulses sent serially over a shared wire. Each frame contains address, function, data, and CRC fields. The receiver uses timing to detect frame boundaries and CRC to verify data integrity. The master controls the bus, sending requests and waiting for slave responses. The serial interface hardware and firmware handle bit-level timing and error detection.

Why designed this way?

Modbus RTU was designed in the 1970s to be simple, low-cost, and compatible with existing serial hardware. The master-slave model avoids bus conflicts on a shared line. Using CRC ensures reliable communication in noisy industrial environments. Alternatives like parallel or more complex protocols were too expensive or complicated for widespread use.

┌───────────────┐
│   Master      │
│  (Controller) │
└──────┬────────┘
       │ Request Frame
       ▼
┌───────────────┐
│   Serial Bus  │───────────────┐
└──────┬────────┘               │
       │                       │
       ▼                       ▼
┌───────────────┐       ┌───────────────┐
│   Slave 1     │       │   Slave 2     │
│ (Responds if  │       │ (Responds if  │
│  address match)│       │  address match)│
└───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Can multiple slaves respond at the same time on Modbus RTU? Commit to yes or no.

Common Belief: Some think slaves can talk simultaneously to speed up communication.

Reality: Only the master talks first; slaves respond one at a time when addressed to avoid collisions.

Why it matters: If slaves talk simultaneously, data collisions occur, causing communication failure.

Quick: Is the slave address 0 used for normal device communication? Commit to yes or no.

Common Belief: Many believe address 0 is a valid slave address for individual devices.

Reality: Address 0 is reserved for broadcast messages; slaves do not reply to it.

Why it matters: Using address 0 incorrectly can cause slaves to ignore messages or create confusion.

Quick: Does Modbus RTU guarantee error-free communication without retries? Commit to yes or no.

Common Belief: Some assume CRC error checking means no communication errors ever happen.

Reality: CRC detects errors but does not fix them; retries or error handling are needed for reliability.

Why it matters: Ignoring error handling leads to lost or corrupted data in noisy environments.

Quick: Can Modbus RTU frames be sent continuously without pauses? Commit to yes or no.

Common Belief: People often think frames can be sent back-to-back without gaps to increase speed.

Reality: Silent intervals between frames are required to mark message boundaries and avoid errors.

Why it matters: Skipping silent intervals causes frame merging and communication breakdown.

Expert Zone

1

Some devices implement extended timeouts or custom retries that deviate from the standard, affecting interoperability.

2

Electrical characteristics like cable length and termination resistors greatly influence signal quality and error rates.

3

Broadcast messages (address 0) do not get acknowledgments, so masters must handle lack of response carefully.

When NOT to use

Modbus RTU is not suitable for high-speed or complex network topologies; alternatives like Modbus TCP/IP or Ethernet-based protocols should be used for faster or more scalable communication.

Production Patterns

In real factories, Modbus RTU is often combined with PLC ladder logic to automate machines, with gateways translating Modbus RTU to Ethernet for remote monitoring, and diagnostic tools monitor CRC errors and timing to maintain network health.

Connections

OSI Model - Data Link Layer

Modbus RTU operates at the data link layer, managing framing and error detection over serial lines.

Understanding OSI layers helps place Modbus RTU in the network stack and clarifies its role in communication.

Human Conversation Turn-Taking

Modbus RTU's master-slave communication mimics turn-taking in conversations to avoid talking over each other.

Recognizing this pattern helps design protocols that prevent data collisions and confusion.

Postal Mail System

Modbus RTU frames are like letters with addresses and checksums, ensuring messages reach the right recipient intact.

This analogy highlights the importance of addressing and error checking in reliable communication.

Common Pitfalls

#1 Ignoring required silent intervals between frames.

Wrong approach:

Master sends frames continuously without pauses:
01 03 00 00 00 02 C4 0B01 03 00 02 00 01 85 DB

Correct approach:

Master inserts silent interval (3.5 character times) between frames:
01 03 00 00 00 02 C4 0B
[Pause]
01 03 00 02 00 01 85 DB

Root cause:

Misunderstanding that timing gaps signal frame boundaries, causing frame merging and errors.

#2 Using duplicate slave addresses on the same network.

Wrong approach:

Two devices configured with address 5 both connected to the bus.

Correct approach:

Assign unique addresses, e.g., device A = 5, device B = 6.

Root cause:

Not realizing each slave must have a unique address to avoid response conflicts.

#3 Not handling CRC errors in software.

Wrong approach:

Ignoring CRC check results and processing corrupted data.

Correct approach:

Verify CRC and discard or request retransmission if error detected.

Root cause:

Assuming hardware or wiring alone guarantees error-free communication.

Key Takeaways

Modbus RTU is a simple, master-driven protocol that uses serial communication to exchange data between devices.

Frames have a strict structure with addressing, function codes, data, and CRC for error checking.

Silent intervals between frames and unique slave addresses are critical for reliable communication.

Error detection with CRC helps maintain data integrity but requires proper handling of errors.

Real-world use demands attention to physical wiring, timing, and network design to avoid common pitfalls.

Practice

1. What is the main purpose of Modbus RTU communication in PLC programming?

easy

A. To exchange data between devices over serial communication

B. To create graphical user interfaces

C. To compile PLC programs

D. To store data in cloud servers

Solution

1. Step 1: Understand Modbus RTU basics

   Modbus RTU is a protocol used for serial communication between devices like PLCs and sensors.

2. Step 2: Identify the main function

   Its main function is to exchange data by sending requests and responses over serial lines.

3. Final Answer:

   To exchange data between devices over serial communication -> Option A

4. Quick Check:

   Modbus RTU = Data exchange over serial [OK]

Hint: Modbus RTU is about device data exchange via serial lines [OK]

Common Mistakes:

• Confusing Modbus RTU with programming languages
• Thinking it creates user interfaces
• Assuming it stores data remotely

2. Which of the following is the correct format for a Modbus RTU request frame?

easy

A. CRC + Device Address + Function Code + Data

B. Device Address + Function Code + Data + CRC

C. Data + Device Address + Function Code + CRC

D. Function Code + Device Address + Data + CRC

Solution

1. Step 1: Recall Modbus RTU frame structure

   The request frame starts with the device address, followed by the function code, then data, and ends with CRC for error checking.

2. Step 2: Match the correct sequence

   Device Address + Function Code + Data + CRC matches this exact order: Device Address + Function Code + Data + CRC.

3. Final Answer:

   Device Address + Function Code + Data + CRC -> Option B

4. Quick Check:

   Frame order = Address, Function, Data, CRC [OK]

Hint: Remember: Address first, then function, data, and CRC last [OK]

Common Mistakes:

• Mixing up the order of function code and device address
• Placing CRC at the start instead of the end
• Confusing data position in the frame

3. Given this Modbus RTU request frame in hex: 01 03 00 0A 00 02 C5 CD, what does the function code 03 represent?

medium

A. Write Multiple Registers

B. Write Single Coil

C. Read Input Status

D. Read Holding Registers

Solution

1. Step 1: Identify the function code in the frame

   The second byte in the frame is 03, which is the function code.

2. Step 2: Recall Modbus function codes

   Function code 03 is used to read holding registers in Modbus RTU communication.

3. Final Answer:

   Read Holding Registers -> Option D

4. Quick Check:

   Function code 03 = Read Holding Registers [OK]

Hint: Function code 03 always reads holding registers [OK]

Common Mistakes:

• Confusing function code 03 with write operations
• Mixing read input status (code 02) with 03
• Ignoring the function code position in the frame

4. You wrote a Modbus RTU request but the PLC does not respond. Which of these is the most likely error in your request frame?

medium

A. Using ASCII instead of RTU mode

B. Sending data without device address

C. Incorrect CRC value

D. Using function code 99

Solution

1. Step 1: Check common communication errors

   Incorrect CRC causes the PLC to reject the frame because it detects data corruption.

2. Step 2: Evaluate other options

   Using ASCII mode or missing device address would cause errors, but CRC error is the most common cause of no response. Function code 99 is invalid but usually triggers an error response, not silence.

3. Final Answer:

   Incorrect CRC value -> Option C

4. Quick Check:

   Bad CRC = No response from PLC [OK]

Hint: Always verify CRC to avoid silent communication failures [OK]

Common Mistakes:

• Ignoring CRC errors
• Assuming wrong function code causes no response
• Confusing ASCII and RTU modes

5. You want to read 4 consecutive holding registers starting at address 100 from a device with address 5 using Modbus RTU. Which request frame (in hex) correctly represents this?

hard

A. 05 03 00 64 00 04 45 C9

B. 05 04 00 64 00 04 45 C9

C. 01 03 00 64 00 04 45 C9

D. 05 03 00 65 00 04 45 C9

Solution

1. Step 1: Understand the frame components

   Device address is 05, function code for reading holding registers is 03, starting address 100 in hex is 00 64, number of registers to read is 00 04, followed by CRC.

2. Step 2: Check each option

   05 03 00 64 00 04 45 C9 matches all these correctly. 05 04 00 64 00 04 45 C9 uses function code 04 (read input registers), 01 03 00 64 00 04 45 C9 uses device address 01, and 05 03 00 65 00 04 45 C9 starts at address 101 (00 65).

3. Final Answer:

   05 03 00 64 00 04 45 C9 -> Option A

4. Quick Check:

   Address 5 + Func 03 + Start 100 + Count 4 = 05 03 00 64 00 04 45 C9 [OK]

Hint: Match device address, function code, start address, and count exactly [OK]

Common Mistakes:

• Using wrong function code for holding registers
• Incorrect device address
• Off-by-one error in start address