I try to implement just 'proof' of concept simulation software where I need to use simulated ( in software) PID controller.
overall in this sim verywhere I use Euler method to integrate differential equitaions .. but as PID has a differential ( which is computationally unstable I think..) I'm looking for just sample code which implements PID controller. Maybe this could give me some hints.
I tried to break down PID into filters which only have integration ( using feed back loop) but so far did not find the way.... the looping into back loops it just never ends ...
so if someone could give a link to C /C++ code to implement PID controller or will provide some hints how to avoid streigforward differentiation ( and use instead integration in back loop) that would be nice.
( BTW I'm not control enginer and also I'm russian so sorry for my english)
I have some code in a generic Basic language, easily convertable to any other language, at:
formatting link
There are two versions. The first is more common but can produce some strange effects when the output is at a limit. The second section of code (actually on
formatting link
is an improved version that emulates analog controllers. It uses a positive feedback loop to provide the integral action.
Why not use the actual algorithm used in an actual digital controller? I recently sent a copy of the one used by Honeywell and it is very easy to program being only a simple difference equation. Send me an e-mail to snipped-for-privacy@driedger.ca and I can send a *.pdf copy. I've successfully used this in a simulator myself.
Your comment on the instability of the differential term is quite valid. They are also unstable in practice and should be applied with caution and only in 'safe' circumstances. (Never in a flow loop.) The traditional way to handle some of the problems is to have a first order filter at the input to your controller. This removes some of the trash that can make the D term useless.
I've used the derivative in a few flow controls with good success. I will agree that it is one of the trickier controls to use, but properly done in the right spots it has been a fantastic tool.
On the other hand, I will admit to seeing it used improperly with, well, we'll say "not good" results.
I suppose that you might consider the applications to be more in the line of a temperature or pressure control, as in several cases I was controlling steam to a heat exchanger or for direct injection to get a liquid up to temperature. I didn't want to overshoot.
In another case, I was using it to control the pressure of a primary condenser in a blow heat recovery system. Water was used to condense steam, but the controls were sluggish due to large diameter pipes and big valves. The control worked on the water to the condenser. Too much would create a vacuum, too little would mean too much pressure. The pressure came in a well defined transient. By working with the derivative controls, I could match the water flow to the incoming steam flow despite the system lags, and keep the pressure very nearly constant. We could safely say that this wasn't really a typical flow control, but more of a pressure control.
In strict flow case, I've kept the derivative gain rather low (or the derivative time very long) or off unless I have to accommodate a known upstream or downstream transient (pressure increase or decrease, for example).
I like derivative control as a cheap "feed forward" portion of a feedback controller, if that makes sense. One important point is that a lot of my controls are related to large transients with very strict overshoot limits. My systems have had a lot of lag time also. If you have to accurately change the a process value from 0 to 1000 units quickly, without overshoot, and a lot of system lag time, then derivative is useful. If you have to change from 998 to 1000, without an overshoot limitation and negligible lag time, then derivative isn't such a good idea.
I've had to remove a lot of derivative action from controllers over the ages. I've typically found that the derivative gain (in whatever form it is presented on a particular controller) is set way too high and contributes more to system woes than to stability.
I figured we were pretty much on the same wavelength, and we are. It would be hard to be too far off, as the laws of physics work about the same in the US and Canada.
My systems have generally had slow enough response that the proper D would decrease the overshoot without increasing variability. I tend to use filtered and averaged values for flow (again, it's ok on the systems I used), which further reduce the liability. The furnace application isn't far from what I used to do. Acutally, a furnace is one of the most common examples of runaway reaction kinetics. They make a fascinating control project.
Because D control has been so abused and maligned, it has been quite lucrative to locate the bad D's, and fix them. It has gotten to be one of my favorite control tricks. Some folks are afraid to use it because it can lead to so many problems. It is really an important control, and is probably under used (and over abused).
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.