Modbus RTU communication in PLC Programming - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of this Modbus RTU frame parsing?

Given the following Modbus RTU frame bytes received:
01 03 02 00 0A C4 0B
What is the value of the register read?

PLC Programming

frame = bytes([0x01, 0x03, 0x02, 0x00, 0x0A, 0xC4, 0x0B])
# Extract data bytes
register_value = frame[3] << 8 | frame[4]
print(register_value)

A 10

B 2

C 258

D 0

💡 Hint

Look at the data bytes in the frame and combine them as a 16-bit number.

The data bytes are 0x00 and 0x0A. Combining them as (0x00 << 8) + 0x0A equals 10 decimal.

📝 Syntax

intermediate

Which Modbus RTU request frame is correctly formed to read 3 registers starting at address 0x006B?

Select the correct Modbus RTU request frame bytes for reading 3 registers starting at 0x006B from slave address 0x11.

A 11 04 00 6B 00 03 76 87

B 11 03 00 6B 03 00 76 87

C 11 03 6B 00 03 00 76 87

D 11 03 00 6B 00 03 76 87

💡 Hint

Function code 03 is for reading holding registers. Address and quantity are 2 bytes each in big-endian.

Option D correctly uses function code 03, address 0x006B (00 6B), quantity 3 (00 03), followed by CRC bytes.

🔧 Debug

advanced

Why does this Modbus RTU communication script fail to read registers?

This Python snippet tries to read holding registers but returns no data:

import serial
ser = serial.Serial('/dev/ttyUSB0', 9600, parity=serial.PARITY_NONE, stopbits=1)
request = bytes([0x01, 0x03, 0x00, 0x00, 0x00, 0x02, 0xC5, 0xC8])
ser.write(request)
response = ser.read(7)
print(response)

What is the most likely cause?

A The CRC bytes in the request are incorrect, causing the slave to ignore it.

B The serial port parameters are wrong; parity should be EVEN for Modbus RTU.

C The read length is too short; response should be 8 bytes, not 7.

D The slave address 0x01 is invalid and causes no response.

💡 Hint

Check if the CRC matches the rest of the frame bytes.

If CRC is wrong, the slave device ignores the request and no response is sent.

🚀 Application

advanced

How to automate periodic Modbus RTU register reads in a script?

You want to read holding registers every 5 seconds from a Modbus RTU slave device using a script. Which approach is best?

A Use a timer interrupt in the PLC to trigger the script externally every 5 seconds.

B Use a loop with a 5-second sleep between each Modbus request and handle exceptions to retry on failure.

C Read registers once and cache the values indefinitely to avoid communication overhead.

D Send all requests at once without delay to speed up data collection.

💡 Hint

Think about how to space out requests and handle communication errors.

A loop with sleep and error handling ensures regular polling and robustness.

🧠 Conceptual

expert

What is the main reason Modbus RTU uses CRC instead of checksum?

Why does Modbus RTU protocol use a 16-bit CRC for error checking instead of a simpler checksum?

A Checksum requires more bytes than CRC, increasing frame size unnecessarily.

B CRC is faster to compute than checksum, improving communication speed.

C CRC detects more types of errors including burst errors, providing higher reliability in noisy serial lines.

D CRC allows encryption of data, enhancing security over checksum.

💡 Hint

Think about error detection capabilities on noisy communication lines.

CRC can detect multiple bit errors and burst errors better than simple checksums, which is critical for serial communication reliability.

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