Recently, a young electrician came to ask about PLC configuration. Looking at his program, I was truly speechless. Today’s young people seem to just throw everything into the code without considering the basic scanning cycle. Back in the day when I started in this field, we didn’t even have decent programming software; we used old-fashioned programmers and input instructions manually.
Back to the topic of PLC system configuration. Many people think that PLCs can just be bought, plugged in, and programmed casually to run, which is simply nonsense. The stability of a real industrial control system relies heavily on proper basic configuration. Last year, I went to a paper mill in Zhejiang to help out, and their control system kept stopping intermittently. The engineers struggled for over a month without a solution. When I took a look, it was all basic configuration issues.
PLC
Pitfalls of Siemens PLCs
Let’s start with Siemens. I have been using old Siemens PLCs for many years, from S7-300 to the current 1500. There is no best PLC, only the most suitable solution. Many people set the scanning cycle too short right from the start, thinking that a fast response is good, but what happens? The system load becomes too high, and with too many I/O points, it can crash! I’ve seen many sites fail because of this issue.
For example, in the summer of 2021, I went to a car parts factory in Suzhou to debug a production line. A young man set the scanning cycle of the S7-1500 to 1 millisecond, and still thought it wasn’t fast enough. During equipment debugging, it stopped inexplicably. After checking the hardware, I found no issues, but upon inspecting the program, I discovered the CPU load was constantly at 99%. A slight increase in data processing would cause it to crash. I asked him why he set the scanning cycle so short, and he said, “Teacher, it’s for a fast response!” I was just… never mind, I won’t scold him.
Below is a basic PLC scanning cycle configuration. It’s simple, but many people overlook it:
// Basic scanning cycle configuration for S7-1500
// Key points for DB block design
DATA_BLOCK "ProcessData"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
NON_RETAIN
VAR
Process_Value : REAL; // Process value, avoid frequent read/write
Control_Mode : INT; // 0=manual 1=automatic
END_VAR
BEGIN
Process_Value := 0.0;
Control_Mode := 0;
END_DATA_BLOCK
Remember: Don’t set the OB1 scanning cycle too short; generally, 10-20ms is sufficient! If a fast response is truly needed, use interrupts to handle it, and don’t just change the global scanning cycle.
1
Communication Configuration Issues
By the way, speaking of communication configuration, it really is a complicated topic. Especially with bus protocols like Profinet and Ethernet/IP, many people think the communication parameters can just be left as defaults, resulting in a complete mess when they go online. To be honest, if the communication protocol is not adjusted according to the application scenario, just wait for problems to arise.
A few years ago, I was at a steel mill in Anhui where the entire production line had over 100 stations relying on Profinet communication, and the data updates were always unstable. The factory staff thought one of the stations was faulty and replaced hardware several times without success. When I looked at the communication parameters, I found that the update time was set to the default of 1 millisecond, and the topology was a complete mess. Wasn’t that just asking for trouble?
Let me put it this way: communication configuration must first clarify your needs. How high are the real-time requirements? How much data needs to be transmitted? What is the physical distance between devices? These are all practical factors to consider. Not all devices need to use the highest speed; some low-priority monitoring data can be updated every 100ms, so why insist on 1ms?
2
Program Structure is a Major Pitfall
Another issue is the program structure. Many people write PLC programs like elementary school essays, with a jumbled mess of network diagrams, making it hard to find logical relationships. TMD… I’m not saying this, but if you can’t even understand the program you wrote during on-site debugging, isn’t that asking for trouble??
I prefer to organize my code like this:
/*
Main program structure - my consistent approach
FC10 - Input processing (debouncing/filtering)
FC20 - Main logic (core functionality)
FC30 - Output processing
FC40 - Alarm handling
FC50 - Communication handling (not in OB1, separate interrupt)
*/
With a clear program structure, it’s much faster to locate issues when they arise. Maintenance is also much easier. Once, I went to a water plant where their system kept failing. Upon checking the program, I was stunned; everything was written in OB1, with thousands of lines of code piled together, and there were no comments. I asked who wrote it, and they said, “Foreign expert.” I couldn’t help but laugh, writing such garbage code and calling it expertise? I think it’s professional deception..
One more thing: variable naming must follow a rule. Don’t switch between “Valve1”, “V_001”, and “阀门1”; it’s headache-inducing. I generally use this format: “DeviceType_Location_Function”, for example, “PMP_INLET_SPEED” indicates the speed of the inlet pump. This way, it’s easy to find and modify without fear of making mistakes.
3
Don’t Forget Safety Mechanisms
Lastly, let’s talk about safety mechanisms, which many people overlook at the start, only to regret it when accidents happen! I remember back in 2017, a factory’s robotic system almost caused a major accident due to inadequate safety circuits. The thing I fear most in my life is injuring someone due to programming issues.
Any control system, regardless of its complexity, must have safety functions implemented separately, with hardware redundancy and the highest priority. This is not optional; it is mandatory! Don’t tell me about cost issues; can you afford the consequences of an accident??
After all this, what I want to express is: when configuring a PLC system, you must first clarify your needs, plan reasonably, and follow best practices. Often, it’s not a technical issue but an attitude problem. There are truly no shortcuts in this field; you have to step on many pits to make fewer mistakes..
By the way, I recently had some time to study the data packet retransmission mechanism of industrial Ethernet, and I feel there is a lot of optimization potential in this area. Let’s chat about it next time.
Before you go, remember to click “Looking“~