Modbus RTU communication in PLC Programming - Step-by-Step Execution

Concept Flow - Modbus RTU communication

Start Communication

↓

Send Request Frame

↓

Wait for Response

↓

Receive Response Frame

↓

Validate CRC Check

↓

Process Data

↓

End Communication

Modbus RTU communication sends a request frame, waits for a response, checks data integrity, then processes or handles errors.

Execution Sample

PLC Programming

SendRequest(slave=1, func=3, addr=100, count=2)
WaitResponse(timeout=1000)
if ValidateCRC(response):
  ProcessData(response)
else:
  HandleError()

This code sends a read request to slave 1, waits for a response, checks CRC, then processes or handles error.

Execution Table

Step	Action	Details	Result
1	SendRequest	Send frame to slave 1: function 3, address 100, count 2	Frame sent
2	WaitResponse	Wait up to 1000ms for response	Response received
3	ValidateCRC	Check CRC of received frame	CRC valid
4	ProcessData	Extract register values from response	Data processed: [123, 456]
5	End	Communication cycle complete	Success

💡 Communication ends after successful data processing or error handling

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
request_frame	empty	constructed	sent	sent	sent	sent
response_frame	empty	empty	received	received	validated	processed
crc_check	none	none	none	valid	valid	valid
data	none	none	none	none	[123, 456]	[123, 456]
error_flag	false	false	false	false	false	false

Key Moments - 3 Insights

Why do we need to validate CRC after receiving the response?

CRC validation ensures the data was not corrupted during transmission. See execution_table step 3 where CRC is checked before processing data.

What happens if the response is not received within the timeout?

The communication would fail or retry. In this example, step 2 waits for response; if none arrives, error handling would occur (not shown here).

Why do we specify slave address and function code in the request?

The slave address tells which device to talk to, and function code tells what action to perform. This is shown in step 1 sending the request frame.

Visual Quiz - 3 Questions

Look at the execution_table, what is the result of step 3?

A No response

B CRC valid

C CRC error

D Data processed

💡 Hint

Check the 'Result' column in execution_table row for step 3

At which step is the data extracted from the response?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Action' column in execution_table for data processing

If the CRC check fails, what should happen next?

A Handle error and possibly retry

B Ignore the error and end communication

C Process the data anyway

D Send another request immediately

💡 Hint

Refer to concept_flow where CRC error leads to error handling

Concept Snapshot

Modbus RTU communication:
- Send request frame with slave address, function, address, count
- Wait for response frame within timeout
- Validate CRC to check data integrity
- Process data if CRC valid
- Handle errors if CRC invalid or timeout
- Repeat cycle for continuous communication

Full Transcript

Modbus RTU communication starts by sending a request frame to a specific slave device with a function code and data address. The system waits for a response within a timeout period. When the response arrives, it checks the CRC to ensure data integrity. If the CRC is valid, the data is extracted and processed. If the CRC check fails or no response is received, error handling occurs. This cycle repeats for ongoing communication with Modbus devices.

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