In the field of industrial automation, communication is the “nervous system” connecting various control systems. The configuration of Siemens PLC communication modules may seem simple, but it hides many “traps”.
This article will explain the basic configuration methods of Siemens PLC communication modules in a straightforward manner, focusing on the applications of three commonly used protocols: PROFINET, PROFIBUS, and Modbus, as well as common issues and solutions encountered in practical engineering.
Whether you are a beginner or an experienced engineer, this guide will help you avoid unnecessary detours.
Basic Knowledge of Communication Modules
When it comes to communication modules, I like to compare them to the “mouth and ears” of the PLC—they allow different devices to “talk” and “listen” to each other.
Siemens PLC communication modules are mainly divided into two types: integrated and expandable. The integrated type is directly built into the CPU (such as the PROFINET port of S7-1200/1500), while the expandable type needs to be purchased and installed separately (like the CM 1241 RS485 communication module).
The choice of different communication modules is crucial, just as you wouldn’t use a vacuum cleaner to wash clothes; each communication module has its specific purpose:
- PROFINET/Ethernet module: Suitable for high data volume and high-speed communication scenarios, such as connecting HMI, upper computers, or other smart devices.
- PROFIBUS-DP module: Suitable for connecting distributed I/O and smart devices, commonly used at the factory workshop level.
- RS485/RS232 module: Suitable for connecting traditional devices like inverters and instruments to achieve Modbus communication.
I once encountered an interesting case: a customer insisted on using an RS232 module to connect a touchscreen, resulting in extremely unstable communication.
After switching to PROFINET, the problem was immediately resolved, and the communication speed increased by more than ten times. It was like replacing a country road with a highway.
Hardware Installation and Wiring Tips
Hardware installation may seem simple, but details determine success or failure. First,be sure to install the communication module while the power is off; I cannot emphasize this enough.
There was a customer who plugged and unplugged the module while it was powered on, resulting in the entire communication interface being burned out, causing a loss of nearly ten thousand yuan.
The wiring methods vary for different types of communication modules:
-
PROFINET wiring: Use standard network cables (shielded cables of category 5 or above are recommended).
┌─────────┐ ┌─────────┐ │ │ │ │ │ PLC CPU ├──网线────┤ 设备 │ │ │ │ │ └─────────┘ └─────────┘ -
PROFIBUS-DP wiring: Requires a dedicated PROFIBUS cable, and be sure to connect terminal resistors at both ends.
┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │ │ │ PLC CPU ├────┤ 从站1 ├────┤ 从站2 ├───┐ │ │ │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ └───────────────────────────────────────┘ PROFIBUS电缆+终端电阻
- RS485 wiring (Modbus RTU): Be careful not to reverse the polarity.
┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │ │ │ PLC CPU ├────┤ 设备1 ├────┤ 设备2 │ │ │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ A+ B- A+ B- A+ B-
Notes:
- Both PROFIBUS and RS485 buses require terminal resistors (usually 120Ω), otherwise it will cause communication interference.
- Try to keep communication cables away from high-voltage cables to reduce electromagnetic interference.
- For long-distance communication, consider using repeaters to enhance the signal.
- The shielding layer should only be grounded at one end to avoid forming loops.
These seemingly minor details are the key points that are most easily overlooked in engineering practice.
There was a customer who complained about unstable PROFIBUS communication, and upon inspection, it was found that he had made multiple branches on the cable, forming a “tree” structure. PROFIBUS must strictly follow a “bus” topology, and after correcting it, communication immediately returned to normal.
Detailed Software Configuration
The communication configuration of Siemens PLC is mainly completed through TIA Portal. Let’s take the most common S7-1200 communicating with an inverter via Modbus as an example:
-
First, add the CM 1241 RS485 module in the hardware configuration.
-
Configure communication parameters (taking Modbus RTU as an example):
- Baud rate: 9600bps (consistent with the inverter).
- Parity: Even parity.
- Data bits: 8 bits.
- Stop bits: 1 bit.
Program to implement Modbus communication using the instructions MB_COMM_LOAD and MB_MASTER:
// Communication parameter initialization - only needs to be executed once
"MB_COMM_LOAD_DB"(
REQ ：= "FirstScan", // Execute on first scan
PORT ：= #PORT, // Hardware identifier
BAUD ：= #BAUD, // Baud rate, e.g., 9600
PARITY ：= #PARITY, // Parity
MB_DB ：= "MB_MASTER_DB" // Modbus master instance DB
)；
// Read inverter parameters (e.g., read operating frequency)
"MB_MASTER_DB"(
REQ ：= "Read_Trigger", // Trigger read
MB_ADDR ：= #SlaveAddress, // Slave address, e.g., 1
MODE ：= #Mode, // Function code, e.g., 3 for reading holding registers
DATA_ADDR ：= #DataAddr, // Register address, e.g., 2000
DATA_LEN ：= #DataLen, // Data length, e.g., 1
DATA_PTR ：= #DataBuffer // Data buffer
)；
Key Points:
- MB_COMM_LOAD only needs to be executed once, usually placed under the first scan condition.
- MB_MASTER requires a pulse trigger to avoid continuous requests leading to communication blockage.
- Inverter manufacturers usually have dedicated communication manuals; the key is to find the correct register addresses.
- DATA_PTR must be a 16-bit integer array, otherwise, the read data will be misaligned.
Practical Application Case: Communication Between Production Line and Multiple Inverters
In a beverage filling production line, we need to control six motors with different functions. Using the S7-1200 PLC and six Siemens G120 inverters communicating via Modbus RTU, we achieve speed control and status monitoring.
System Architecture:
┌──────────────┐
│ │
│ S7-1200 │
│ │
└──────┬───────┘
│ RS485
┌──────┼───────┬────────┬────────┬────────┬────────┐
│ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼
G120#1 G120#2 G120#3 G120#4 G120#5 G120#6
Key Code:
// Loop to read the status of all inverters
CASE #CurrentDevice OF
1： // Read status of device 1
#SlaveAddr ：= 1；
#ReadTrigger ：= TRUE；
2： // Read status of device 2
#SlaveAddr ：= 2；
#ReadTrigger ：= TRUE；
// ...other devices
END_CASE；
// After completing each communication, switch to the next device
IF #ReadComplete THEN
#ReadTrigger ：= FALSE；
#CurrentDevice ：= #CurrentDevice + 1；
IF #CurrentDevice > 6 THEN
#CurrentDevice ：= 1；
END_IF；
END_IF；
Implementation Points:
- The polling interval cannot be too short, at least reserve 50ms for each device to respond.
- Use status words to determine inverter faults for timely alarms.
- Use a program loop to avoid sending requests to multiple devices simultaneously.
During implementation, we encountered occasional communication interruptions with the inverters. After investigation, it was found that there was interference caused by a high-power motor starting next to the inverters.The solution was to increase the shielding and filtering measures for the communication cables, and also add a communication timeout retry mechanism in the program.
Common Problems and Solutions
-
Unstable communication or connection failure
- Check the wiring, especially the polarity and grounding of the shielding layer.
- Confirm that communication parameters match (baud rate, parity, etc.).
- Use an oscilloscope to check signal quality.
- Consider lowering the communication speed to improve stability.
Data reading errors
- Carefully verify register addresses and function codes.
- Check byte order (big-endian/little-endian).
- For floating-point numbers, format conversion may be required.
Communication timeout
- Increase timeout settings.
- Increase retry counts.
- Check if the slave device is responding too slowly.
Device conflicts
- Ensure that slave addresses are unique, with no duplicates.
- Design polling intervals reasonably.
- Consider allocating communication resources based on priority.
There was an engineer who complained to me about the communication being inconsistent; it was eventually discovered that he had forgotten to clear the REQ trigger signal in the program, causing the system to continuously send requests. It was like knocking on someone else’s door non-stop, and they could only “play dead”.
Communication Debugging Techniques
When debugging communication issues, I often use the following methods:
- Use a communication analyzer: such as a PROFIBUS analyzer or network packet capture tool to visually inspect the contents of data packets.
- LED status indicators: The LED lights on the communication module are the most direct diagnostic tools.
- SF (red) on: Module fault.
- TX/RX flashing: Data transmission normal.
- Device diagnostic functions in TIA Portal.
- Observe the STATUS output values of communication instructions.
Debugging suggestion: Create a simple status display panel to visually show each communication step and status code for quick problem localization. My approach is to use a dedicated DB block to record various status information, making it clear when issues arise.
Practical Recommendations
Configuring communication modules is an important part of PLC applications, and mastering it will greatly enhance your ability to implement automation projects. Here are my practical recommendations:
- First, set up a test environment to verify communication feasibility before deploying it on-site.
- Save verified usable communication programs as templates to save development time in the future.
- Document records well, especially the addresses of each device and register mapping tables.
- Leave room for expansion, considering the possible increase in the number of devices in the future.
- Implement redundancy design, critical systems may consider dual-channel communication.
- Regularly conduct communication tests to prevent issues before they arise.
Practice task: Try configuring the S7-1200 PLC to communicate with an inverter via Modbus RTU to achieve start-stop control and frequency read/write. Record the problems and solutions encountered during the process; this will be the best way to test your mastery.
Remember, safety first: Communication failures can lead to equipment loss of control, so be sure to include safety protection logic in your program, such as putting devices into a safe state during communication interruptions. I have seen cases during factory internships where communication interruptions caused conveyor belts to keep running, almost leading to serious accidents.
By mastering these knowledge points, you will be able to confidently handle various PLC communication issues and contribute to the construction of smart factories!