I'd like to know how I can get the Imax and Imin values.
if (I_error > Imax) {
I_error = Imax;
}
else if (I_error < Imin) {
I_error = Imin;
}
I don't want my integral to keep summing up the error infinitely so to say therefore the above code.
Can I just pick a reasonable value randomly?
Answer
There are lots of techniques to cope with integral wind-up. I've used two (and modifications of them), as I was learning more how to handle the problem and facing different situations. These are:
- Setting a limit value (min and max, as I think you are considering) to the error value that is incorporated into the integral. If you know something about the proportional band and what the integral errors within it look like (and you can figure that out), then you can set these limitations to reasonable and meaningful values based on that. The problem with this is that you are accumulating error in your integral term when the process is just starting up and is under full power trying to move towards the set point. And it's almost always inappropriate since the integral term isn't intended to operate from a cold start. Instead, it is meant to deal with getting rid of the proportional band offset error, which really only matters when the process variable is within the proportional band region (or some approximation of it.)
- Holding the integral at zero (keeping it from accumulating any error at all) until the process arrives into either the proportional band itself or some closely related band. If the proportional band is really narrow, you may want to open up the band a bit for integral control to start operating.
There are many other ideas that have been floated and tried. The above two are abrupt in the sense that you are either placing arbitrary limits on the error value or else you are ignoring the error value until the process enters a range where it can freely operate. So another approach would be to smooth out that transition and make it less abrupt in behavior. Perhaps, for example, by diminishing the error value when the process variable is very far away from the proportional band and then bring it through some model formula into normal behavior once the process variable is within the proportional band.
(The concept of far away implies another, distance, and I think if you consider this idea you will find that the distance away from the proportional band probably should be related to the distance across the proportional band. A cold start from a process with a very narrow proportional band is "very far away," while a cold start from a process with a very wide proportional band is "closer," in this sense. Think about it, if you decide to try and smooth things out through some diminishing formula.)
What you decide to do may also impact any auto-tuning algorithm you have to generate, by the way. A lot of customers will expect auto-tuning and if you have to provide it, then you may have to impact that algorithm based on what you decide to do with this wind-up problem.
Per your comment below:
could you perhaps give a small example of setting a limit value?
I would have thought this would be obvious. You can work out the worst-case error term within the proportional band. It's either the difference between the upper limit and the set point or else the difference between the lower limit and the set point. (These may be the same difference, but I can't know that in advance.) So you can limit the computed error term, for the purposes of accumulating integral error, to either of these values (or the smaller of the two, or the larger of the two, or average, or some multiple or sub-multiple according to your design.)
The problem I have in giving you an exact example is that I don't know how you are specifying your proportional band. It can be done in any of a number of ways: (1) the upper and lower process variable values around the set point; or, (2) a percentage of the process variable value itself; or, (3) the direct, time-weighted multiplier constant itself. (And I'm sure there are others I haven't seen before, too.) So I can't provide an exact formula example without knowing more about your design. I have to leave this as descriptive, rather than quantitative, for now.
(Also, when the process variable is out of the proportional band, you could choose to compute the distance away using some model you design, where the value 0 would mean "infinitely far away" and 1 would mean "right at one of the edges of the proportional band" and use this value as a multiplier of the above maximum error term added to the integral error term. If so, this is about that "smoothing" I mentioned.)
Spehro Pefhany just reminded me of something else very important for PID controller software. It has nothing to do with integral wind-up, though. But I may as well capture this detail here.
Think about any closed loop control system as being very much like trying to poke a narrow bamboo pole through the hole in a bird house. It's easy if you have a short pole and the length of that pole doesn't vary while you are struggling with it. It's hard if the pole is really long, swaying about, and the length is constantly changing on you, besides. These two images capture two important aspects in closed loop control systems, which trump almost everything else.
- Keep the time between the measurement of a signal and the production of a control signal (and its use, by implication) to a minimum. The shorter, the better.
- Do not let this time vary. The less it varies, the better.
Point (1) above is the average magnitude of the length of that bamboo pole. Point (2) above is how the length of that bamboo pole varies around.
You want a short pole that doesn't vary in length. That makes the PID parameters work well. And no PID ever invented will do well with a long pole that is constantly changing widely in length.
The very first thing I do in scoping out a controller is to look at keeping the phase delay as short as I possibly can and to look at how I can keep that phase delay absolutely unvarying. I usually make this a matter of crystal control, so that it varies no more than the crystal oscillator does. That's how much I care about this. There is no getting around the fact that making your PID controller predictable and usable is as much, if not more, about making your "bamboo pole" as short as possible and as invariant as possible.
I can't always say which of these two factors trumps the other, as this is process dependent, but as a general rule I consider the invariant part actually more important than the magnitude of the phase delay, because design is about predictability and if you have a variable delay that is going this way and that, all over the place, there is no possible way of getting the PID parameters squared away. At least you have a chance at it, if the delay doesn't change on you from moment to moment, even if the delay is longer than it could have been.
My first implementation of a PID controller was applied by a Vancouver BC customer to control a GaAs boule puller. They had used dozens of different PID controllers and simply couldn't get rid of horrible oscillations in diameter during pulling. They were desperate and had called the company I was contracting with to ask them for help. (This company made the temperature measurement device -- a pyrometer with NIST traceable accuracy of \$500\:\mu\textrm{K}\$ and precision of \$50\:\mu\textrm{K}\$. But it didn't have any PID software at the time. It was just a measurement instrument.)
I was asked to write PID controller software to add to this piece of equipment, which already had \$0-10\:\textrm{V}\$ and \$4-20\:\textrm{mA}\$ outputs that could be re-purposed for control. I'd never used PID before and had no idea what I was getting into. But I got a book, read, and started thinking about the code. One thing I'd learned over the years working on measurement instrumentation was the importance of precision timing, so I applied that thinking to this problem almost as a matter of routine.
This customer called us within a week of receiving the new software updates, demanding to talk to me. He said, "It's working PERFECTLY!! My gosh, your PID is fantastic. You must be one of the world experts!"
Hehe. No. Not so. I had only just barely learned some of the terms, for gosh sake. What I did have were a few very important advantages over the competing PID controllers from the major players, such as Omega and their suppliers. I was inside the instrument making the measurements and I made dead sure that the time delay was as short as I could make it, plus I made sure that the controller output was crystal-driven and invariant to 1 CPU cycle. (Written in assembly to be certain of that.)
A short and unvarying length of the delay will make any PID look good. So that is where much of your efforts should be focused.
No comments:
Post a Comment