Click the blue text for more exciting information
Having worked in this field for 15 years, today let’s talk about the PID controllers in PLCs that many find confusing. Many beginners get a headache just hearing about PID, and to be honest, many veterans also struggle to understand it. This thing looks simple, but using it can be a pitfall! In 2019, a paper mill contacted me, saying their temperature control system was oscillating like it was on medication. When I looked at it, it was obvious—the derivative parameter was set too high; how could it not oscillate?
The Pitfalls of PID
First, let’s discuss why PID is so troublesome in PLCs. The key issue is that most people do not understand the purpose of the three PID parameters, and they adjust them blindly. When problems arise, they blame the PLC for being ineffective. The PID function block from Siemens is actually quite powerful, but many people are too lazy to read the manual and rely on guesswork for parameters.
Even more ridiculous, some people can’t even distinguish between the PLC scan cycle and the PID calculation frequency. I saw this in a factory in Suzhou two years ago; a guy placed the PID in a 100ms slow task, and the temperature control was unstable, fluctuating wildly. He was sweating profusely, unable to find the cause. Can you blame the PLC for that?
Let’s look at some common debugging pitfalls:
- Integral term too large, causing severe overshoot and constant device oscillation
- Derivative parameter set incorrectly, causing control output to fluctuate wildly
- Incorrect sampling time, leading to significant control delays
- Deadband set too small, causing the actuator to oscillate continuously
The most frustrating thing is that many people treat the PID controller as a black box; when something goes wrong, they just adjust parameters randomly, tweaking P and I values as if praying for a solution. This is not engineering thinking! Once, a new guy said he spent a whole day tuning the PID, and when I checked, he had connected the valve incorrectly; increasing the output actually closed the valve. How could he tune that correctly?
Why are there such big differences between PLCs from different manufacturers?
The differences between AB’s PID and Siemens’ are quite significant. I personally prefer the old Siemens; I’m so used to the FB41 PID function block that I can configure it with my eyes closed. AB’s is also good, with the Enhanced PID featuring auto-tuning, which is quite useful, but it’s a bit pricey. If a project can use Siemens, I definitely won’t use AB; the boss would have a heart attack looking at the budget. By the way, jitter compensation in MODBUS communication is crucial; many people overlook this, causing data to jump around.
Speaking of domestic PLCs, I have a lot of grievances… some counterfeit products are simply laughable. They claim to support PID, but the integral term resets on power loss, and you have to restart the integration after rebooting. What kind of design is that? Some PID implementations can’t even handle feedback correctly, and when issues arise, it’s all guesswork. I really admire those who boast about their capabilities but can’t even get basic functions right.
In 2020, a project required the client to use a certain domestic PLC to save costs, and during debugging, it failed twice; the PID controller inexplicably lost control, and in the end, the entire system had to be rebuilt with Siemens. The saying ‘you get what you pay for’ is absolutely true.
Practical experience is the hard truth
Let’s talk about some practical experiences; I’ve summarized a few tips for tuning PID controllers:
// Example of initial configuration for Siemens S7-300 PID
"PID_Temp_1".Retain.CtrlParams.Heat.Gain := 0.5; // Start with a small P gain
"PID_Temp_1".Retain.CtrlParams.Heat.Ti := 120.0; // Set a longer I time constant, take it slow
"PID_Temp_1".Retain.CtrlParams.Heat.Td := 1.0; // D usually doesn't need to be too large
"PID_Temp_1".Retain.CtrlParams.Heat.TdFiltRatio := 0.2; // Don't forget the derivative filter
I never use the manufacturer’s auto-tuning function; that thing is basically unreliable under actual working conditions. You still need to estimate the parameters roughly; set P small and I conservatively, and you generally won’t run into major issues. Once control is stable, you can slowly optimize. I remember staying up late tuning the PID for a fixture control system at an automotive factory, working from 8 PM to 6 AM, my throat was hoarse, and my hands were calloused, just to keep the temperature accuracy within ±0.2℃. The parameters I summarized later became the standard template.
If you ask me what the most stable method is, I actually summarized a set of methods years ago:
- First, confirm that the actuator is functioning properly; don’t tell me the PID isn’t working when the valve is stuck
- Set both I and D to zero, and just try using P to find the critical value where oscillation starts
- Multiply the critical value by 0.5 to get the practical P value
- Then add I, setting the I time constant larger at first; don’t rush
- Finally, fine-tune D; in most cases, D isn’t needed and can complicate things
On-site modifications are often more effective than theory. For example, in some temperature control systems, I deliberately add a first-order lag filter to smooth the measurement signal before it enters the PID. You won’t find this in theoretical textbooks; it’s all learned from painful experiences.
Performance bottlenecks? Nonsense, PLC performance is not the bottleneck; the bottleneck is the people. Many engineers can’t even see that the basic sampling period and PID calculations are mismatched, yet they blame the equipment. We have an old engineer in our factory, over 60 years old, who can still write ST code for PID tuning by hand, and it’s incredibly precise. Young people often only know how to use wizards, and when problems arise, they are at a loss.
By the way, in the past two years, there has been a shortage of PLC chips, and prices have skyrocketed. Some projects have been forced to use lower-performance PLCs, often encountering communication timeout issues. Here’s a little tip: when communicating, don’t read everything at once; jitter will be worse. Read and write data in batches, with at least a 50ms interval, and the results will be much better.
Finally, let me say something from the heart, there are no shortcuts; just do more, make more mistakes, and summarize. Yesterday, I encountered a young person who asked me if I had any PID tuning secrets, and I just laughed… there are no secrets; it’s all about using your brain and experience. Alright, that’s all for today. If you have questions, leave a message, and I’ll respond when I see it.
Disagree? Just give me a look
