PLC Communication Made Easy: A Shortcut to Mastering the Modbus Protocol

Hello everyone, I am Lao Liu. With over twenty years of PLC programming experience, I can tell you that many beginners are most afraid of the communication part. Today, let’s talk about something practical—the Modbus protocol. It may seem complex, but it is essentially a tool for “data transfer”; mastering it can save you a lot of unnecessary trouble.

What is Modbus?

In simple terms, Modbus is the rule for devices to “talk” to each other. Just like when I chat with you, we need to use the same language and follow the rules of “you ask, I answer”.

The two most common modes of Modbus are:

• RTU: Uses RS485 for transmission, suitable for factory environments with interference resistance.
• TCP: Uses Ethernet for transmission, suitable for long distances and multiple devices.

When I first started in the industry, an old electrician taught me: “Xiao Liu, remember, Modbus is just ‘one question, one answer’; the master station asks, and the slave station answers, it’s that simple!”

Modbus Data “Drawers”

Modbus categorizes data into four types of “drawers”:

1. Coil Status (0x): Digital output, readable and writable (equivalent to PLC’s Y points).
2. Discrete Input (1x): Digital input, read-only (equivalent to PLC’s X points).
3. Holding Register (4x): 16-bit data, readable and writable (equivalent to PLC’s D area).
4. Input Register (3x): 16-bit data, read-only.

For example, if I want to read the holding register 40001 from slave 1, I use function code 03, and the data looks like this:

Sending: 01 03 00 00 00 01 84 0A
      └┘ └┘ └───┘ └───┘ └───┘
      Station Number Function Code Register Address Data Length Checksum

Receiving: 01 03 02 00 FF F9 C4
      └┘ └┘ └┘ └───┘ └───┘
      Station Number Function Code Byte Count Data Checksum

Looks intimidating? Don’t worry, in actual projects, these messages are automatically organized by the PLC; you just need to know how to configure it.

Practical Example: Reading Temperature Controller Data with Siemens S7-200 SMART

// Network 1: Initialize communication parameters
|--|MBUSPREP|-- FirstInit=M0.0, Port=0, BR=9600, Parity=0, 
            DataBits=8, StopBits=1, RespTO=1000, 
            MB_ADDR=VB10, ActTCP=0, Spare=0 --|

// Network 2: Read temperature value from slave address 1 (40001)
|--[Communication Trigger Condition M0.1]--|
   |
   |--|MBUSRDR|-- FirstScan=M0.2, Station=1, CMD=3, 
                RegAddr=VW20, Count=1, DataPtr=VW100 --|

After configuring these, the temperature value from the temperature controller will be stored in VW100. It’s that simple!

Common “Pitfalls” and Solutions

1. Address Offset Issues

The biggest pitfall is the address offset! Some devices have an actual address of 0 for 40001, some have 1, and others have 0000H.

Solution: Check the device manual before configuring; if that doesn’t work, try the three cases of “0, 1, 0000H”.

// Address offset is 0
RegAddr = 0     // Access 40001

// Address offset is 1
RegAddr = 1     // Access 40001

1. Inconsistent Parity

Solution: Set all devices to the same parity method; usually, “no parity” is the easiest.

1. Communication Timeout

Solution:

// Increase timeout duration
RespTO = 2000   // Set to 2 seconds

1. Line Interference

Solution: Add 120-ohm termination resistors at both ends of the RS485 bus, and route wiring away from variable frequency drives and large motors.

Useful Tips

1. Block Reading

Do not read too much data at once, as it can easily lead to timeouts or errors. My experience is:

// Read a maximum of 10 registers at a time
Count = 10

1. Add Delay to Control Communication Rhythm

// Query at least once every 100ms
|--[Communication Trigger M0.1]--|--[TON T37,K10]--|---(Execute Communication M0.2)---|
|--[M0.2]--|--[RST M0.1]--|  // Reset trigger signal after communication

1. Monitor Communication Status

// Monitor communication status
|--[Communication Complete]--|--[Communication Normal]--[MOV 0, D100]--|  // Status normal
|--[Communication Error]--|--[Increment Error Count]--[INC D101]--|  // Accumulate error count

Summary: Three Steps to Learning Modbus

1. Understand the Principles: Master station asks, slave station answers; four types of data.
2. Master Configuration: Port parameters, address mapping, function code selection.
3. Debugging Techniques: Start simple, first achieve single data communication.

My mantra on the debugging site is: “First confirm the wiring is correct, then consider if the program is correct, and only then suspect the device has issues.” This saying is particularly applicable to communication problems.

Alright, that’s it for today’s introduction to Modbus communication. I believe you are no longer afraid of this “roadblock” in communication. If you have any questions, feel free to leave a message for discussion!