PID control analogy, revisited
Readers also provide feedback regarding control system maintenance and the benefits of PC-based control systems.
Regarding: “Understanding Derivative in PID Control,” by Peter Welander , Control Engineering North American edition, February 2010, budurl.com/9s5q
The articles I like best are “up to the minute” and yet timeless. The P.I.D. related articles are in that ballpark. Good goin’.
L Warren Rogers, electronics lab technician/engineer
Expanding on the vehicle analogy
Regarding: “Understanding Derivative in PID Control,” by Peter Welander , Control Engineering North American edition, February 2010.
A very nice article. I am going to keep a copy of this around. My only complaint is that the analogy between riding the brakes and the accelerator of a vehicle breaks down for the case of PID controllers. No chips are damaged in your PID controller as it mathematically resolves the conflict between energy supplying (P-I) terms and energy depeleting (D) terms in its formulas.
I have been told many times that derivative feedback is inherently destabilizing. While this simply not true, there is some basis for the paranoia, for reasons that this article does not explore.
1. Not all systems fit the crude “lag and delay” model postulated by Z-N tuning. Higher order behaviors that are normally negligible and “assumed away” can sometimes be excited by derivative control.
2. First-year calculus students are painfully aware that very few functions automatically evaluate their own derivatives. To make up for the missing information about system response, a PID controller estimates a derivative in some manner. This is important: it is a mathematical construct, not the REAL thing. There is a tradeoff between computational difficulty, estimation accuracy, and noise sensitivity. Derivative control tends to accentuate subtle differences between estimation methods.
3. A fact often overlooked is that many PID systems are implemented digitally, with inputs and outputs operating through converter devices operated at discrete time intervals. These devices have an inherent sampling time lag. While the time lags have negligible effects at low frequencies, they have relatively larger effects on phase shifts at high frequencies. These often do not play nicely with derivative controls, complicating hazards that already exist from filtering the derivative terms, as mentioned in the article.
This article presents a sensible approach: see what you can do without derivative control first, then see what incremental improvement is possible, not trusting magic formulas such as the Z-N rule too much.
[Also,] some minor comments about Dr. VanDoren’s side bar note “Derivative Action at Work”:
Ziegler and Nichols did not “discover by trial and error.” Read their paper. In fact, their contribution was providing a mathematical basis for systematically analyzing response loops. I never disparage their work, but consistently point out that it applies only under severely restrictive assumptions. We can do better today (and have!), but the Z-N rule is all you will read about in CE.
Other tuning rules, PID topologies, and nonlinear anti-windup features can facilitate overshoot control without sacrificing all benefits of derivative feedback. The note doesn’t say otherwise... but leaves a big gap.
The point about “overshoot can be eliminated entirely by leaving the derivative action disabled” should have been carefully qualified “in this case.” For the case of certain level control and low-loss systems this is not in general true. You can verify this theoretically, using simple feedback theory, applying it to the PI control law and a lossless second-order oscillator. Try it!
Larry Trammell, software engineer
Control system maintenance: Junkyard dog meets engineer
Regarding: “Control System Lifespan: How Long is Long Enough?” by Peter Welander , Control Engineering North America edition, January 2010 , budurl.com/9s5q
Having cut my teeth on dc motor generators drives, rotating amplifiers, drum memory and teletype machines, I know all too well the pain of maintaining a control system that is past its prime. Keeping a legacy system running requires a special kind of talent: 1/3 junk yard dog, 1/3 cutting edge engineer, and 1/3 anal records keeper. Its not enough to just go out everyday and make it work, it takes a deep historical understanding of the system to be able to modify and replace components that are no longer made. My hats off to anyone keeping the old stuff running!
Michael Ellebracht, Sr. Systems Intregrator
BIS Frucon Engineering, St. Louis, MO
PC-based control: Its openness is clear
Regarding: “Beckhoff Automation: Use PC-based control, not PLCs; Here’s why,” by Mark T. Hoske , Control Engineering News, January 30, 2010, tinyurl.com/y8oqz9n
I would assume that without an understanding of it, a PC-based control approach could possibly look like a closed system to some. I would think that if you are not familiar with the PC as a control platform that it may scare some control engineers. Just like the PLC scared those who had to replace relay logic in the '70s.
However, most of us who have the knowledge to understand and utilize the power of the PC in automation have seen that it is totally open. Unlike a PLC, most PC-based software will run on any vendor’s hardware and most PC hardware will run any vendor’s software.
The standard Industrial PC (IPC) does not even stipulate which operating system (OS) is used on the hardware platform. If you can find a more open hardware platform than that, then buy it! For those of us who used PC hardware as a control platform, we have seen a great range of OSs, such as Windows, Linux, Solaris or QNX, that give the user a more open environment to develop controls. Many of these OSs provide native connectivity to communicate with other software which, in turn makes access and interoperability of devices much more transparent than in the PLC world.
The IPC user can chose many programming development options such as IEC 61131 software packages which are global standards and are supported by many of the large PLC vendors as well. The open PC environment also provides the flexibility to use high level programming languages such as C++, VB or C# which most engineers coming out of school today are very familiar with.
The scalability of a PC-based system is also more flexible and open. In the PLC world, if you need to scale your system for more or less power, you need new programming software, which would be dedicated to that particular hardware platform. Since most PC-based software is able run on many different hardware platforms, users are able to scale the hardware platform to meet the application requirements without having to change the software. This means NO new software to learn or support.
I would conclude that the openness and flexibility of a PC-based system is far superior to the traditional PLC and, when you consider the performance, networking and cost advantages of a PC, it is a no-brainer if you have the initiative and aptitude to implement it.
Leo Young, manager
The only thing we have to fear is fear itself!
Regarding: “Beckhoff Automation: Use PC-based control, not PLCs; Here’s why,” by Mark T. Hoske, Control Engineering News, January 30, 2010
The only thing we have to fear is fear itself! PLCs have proprietary software and are typically far more closed than any PC-based system, TwinCAT software from Beckhoff adheres to IEC 61131-3 as established by PLCopen and users can program in structured text, ladder logic, function blocks, instruction list and sequential function chart. TwinCAT software has free updates, does not have renewal fees and users are supported by an engineering team in the U.S. without requiring a support contract (will your PLC vendor do that?).
To say that a plant with a PC-based controller is “held captive” to the manufacturer of the equipment is to say that my Dell desktop makes me captive to Dell. I believe this is a groundless assertion rooted in “protectionist” thinking and fear tactics that have positioned too many manufacturers in this country at the back of the pack when it comes to technology. To succeed in a global marketplace, we need to always be improving and looking forward toward new technology. If you aren’t moving forward, you’re falling behind.
Joe Ottenhof , manager
Toronto, ON, Canada
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.