4
\$\begingroup\$

I'm working with a PI controller that regulates temperature through a pwm duty cycle.

It generally controls well. However, the system requires a certain minimum duty cycle to balance the heat loss. When the PI finally gets it right, that is, when the Proportional error is Zero and the Integral error is Zero, the output also goes to Zero and throws the system off. Then the PI starts working hard at minimizing the error and repeats.

Is there a solution to this?

Additional Information

The heater is only allowed to go from 0 to 1 maximum of 3 times per unit time (a strict requirement). This causes the fixed frequency saw tooth wave you see.

Here is the overview:

Overview of Temperature.  Pink line is the outside of the vessel temperature

Here is the problem area zoomed and marked. The Integral crosses zero and results in a whimper output which then causes a large error and the pattern repeats:

Temperature Zoomed in, with problem area marked

PID output. Yellow: Integral, Magenta: Proportional, Cyan: Error, Red: Output.

You can see when the Proportional and Integral near zero, the whimper occurs.

The PI output is passed through a duty limiter and sign filter resulting in only 0 or 1 outputs. It is then passed to the frequency regulator that does not allow more than one 0->1 transition in the same 1/3 of unit time. This means that for a portion of the cycle, the output of pi controller is culled. The integral portion continues to build however and compensated in the next period.

PID output.  Yellow: Integral, Magenta: Proportional, Cyan: Error, Red: Output

\$\endgroup\$
  • \$\begingroup\$ Yes, it's called "tuning". You obviously have non-optimal coefficients for P and I. \$\endgroup\$ – Olin Lathrop Jan 29 '13 at 15:38
  • 3
    \$\begingroup\$ @OlinLathrop Perhaps you could explain the process a little? \$\endgroup\$ – NickHalden Jan 29 '13 at 16:23
  • \$\begingroup\$ @OlinLathrop: Kp * E + Ki * IntE. Exactly for which (finely tuned) Kp and Ki does the sum become non-zero when E and IntE are zero? With respect, I've enjoyed your other posts, though the condescension here is not productive. \$\endgroup\$ – MandoMando Jan 29 '13 at 16:31
  • 1
    \$\begingroup\$ @MandoMando Does the integral error really go to zero? Normally, it grows to some steady non-zero value, until the integral error gain is sufficient to balance the cause of the error. \$\endgroup\$ – Phil Frost Jan 29 '13 at 16:46
  • \$\begingroup\$ @PhilFrost yes. It eventually crosses zero. At which moment, the output is dropped. We would like the system to have zero avg error which means integral error needs to be driven to zero. It's good at following paths, step response and disturbance rejection, it's just not good at being a regulator. \$\endgroup\$ – MandoMando Jan 29 '13 at 17:03
3
\$\begingroup\$

I know exactly where you're coming from. The mistake you're making is assuming that the integral term drops to zero in steady state. This is not the case, and, indeed, is highly dependent on implementation details.

First off, understand the integral term in a mathematical PID is the integral from the start of time (or, well, the system) and not "error over last few cycles". Your implementation of PID or PI should not cause the older contributors of the integral term to drop in relative weightage of the I term. Let me explain. When writing the I term's code, the first instinct is to assume that the term will diverge, crossing the variable size and overflowing, and people attempt to fix this using moving averages, degrading the weightage of the older values, and all sorts of strange gimmicks. This should not happen in a properly implement PI or PID system. Instead, you should simply calculate I as I = I + Ki*Error.

The baseline level required to maintain the system, which you mention in your question, must be provided by the I term. Since you do not know how much this is apriori, you must allow the controller to discover this value for itself. That, in fact, is the job of the I term. The Ki value should be small enough for the controller to converge before it overflows. Some thought about how this works on paper will help. Try to visualize the process, not specific boundary conditions. One thing that you should keep in mind is that the I term is not constructed from absolute value of error. It includes both positive and negative values of error.

Further, imagine the condition where the controller is just reaching the steady state. You will realize that I is not necessarily zero at this point. Indeed, I is actually the baseline control force you mention in the question. If the state actually remains stable, and if error from here on in is continuously zero (or zero averaged over time), the value of I will remain as it is.

Now, when it comes to real implementations, the problem you will face is that even with a small I, by the time your system reaches the set point, I may well have saturated. The system will then have to err in the opposite direction for a long time to rid itself of the I term it accumulated while it was still reaching the set point. In fact, I've noticed that PI and PID work best for a single set point, and degrade when you have to keep changing that point by a large value. A big contributor to this is the fact that I has high inertia. Tuning the value of I is possible to keep rhe controller functional, but when the system itself responds to stimulus slowly (say you're heating a block of metal), tuning is often difficult. Instead, what can help is to activate I only when. The system is within a certain threshold of the set point. When you change the set point by something greater than this threshold, clear I and disable it (use only P/PD control) until you reach close to the new setpoint. By doing this, you add another tunable parameter (the threshold), but it makes setting both Ki and the threshold easier than setting Ki by itself to be optimal for both situations.

\$\endgroup\$
  • 1
    \$\begingroup\$ I like your handling of I versus a "threshold", but aren't you afraid of having invented another "strange gimmick"? \$\endgroup\$ – gbarry Jan 29 '13 at 19:20
  • \$\begingroup\$ To be fair, I have. And once you introduce that, it's no longer PID (or PI), and instead a time multiplexed combination of PD (or P) and PID (or PI). This messy scheme only works when the system has a ridiculously high inertia, and in my opinion is simply an explicit acknowledgement of the fact that the transition state is not ideal for full PID control. Of course, this isn't necessary if you're system reacts fast, or you don't mind waiting for the order of time it took you to go from 0 to set point for it to stabilize. \$\endgroup\$ – Chintalagiri Shashank Jan 29 '13 at 19:29
  • \$\begingroup\$ @ChintalagiriShashank thanks for the post. What seems to work well is to limit I to a small saturation so that it's only able to offset the droop and no more. Though that threshold idea is similar. \$\endgroup\$ – MandoMando Jan 30 '13 at 16:45
1
\$\begingroup\$

You don't seem to understand how the system is supposed to work. If the errors are zero, that means the temperature is at the set point and the output should be off. When the temperature changes (presumably drops), then there will be corresponding errors and there should be an output to correct that.

A system such as this, using P only, can achieve equilibrium, but will not reach the set temperature. With I added in, the system can achieve equilibrium and reach the set temperature, but there will be a constant offset from the I term in order to keep it there. This offset represents the heat that the system is constantly losing.

It appears your system is working as designed. Though you may want a different result. Tuning certainly applies, as all the comments are calling for.

For those who don't have a good understanding of PID systems, the article "PID Without a PHD" is highly recommended. Search on the title. The original, which appeared in Embedded Systems Programming had links to the illustrations. For a more convenient read, with the illustrations embedded, find one of the PDF's instead.

\$\endgroup\$
  • \$\begingroup\$ Thanks @gbarry. I'm familiar with Tim Wescott's work. I've added more information, hopefully it'll clarify things. Tuning is NOT the issue here, the effect of the frequency limiter is the issue. \$\endgroup\$ – MandoMando Jan 29 '13 at 18:11
1
\$\begingroup\$

It doesn't sound like it generally controls well. A PI type loop control should result in a PWM duty cycle (at steady-state) that is basically a constant value. It should not cycle from zero to some large value. Since this is a thermal loop your time constants will be long, and oscillations would be tens of seconds long. Also with thermal systems the open loop gain will vary, perhaps as much as an order of magnitude, as a function of the ambient conditions. Some things to be aware of for a system that has any load on it:

  • Output of the proportional part of the loop will never be zero.
  • Overall error, after correction by the proportional part of the loop, will not be zero either. Since the proportional part has a finite gain it will not totally correct the error.
  • The integrator part can have infinite gain, but it takes infinite time to reach it. So, the integrator is used to correct the error left over by the proportional part, but only for low frequencies. This means that the integrator output will not ever be zero for steady-state operation either.

You need to choose the values for the gain of the proportional part and the integral part to stabilize the closed system loop. It sounds like the gain of one or both of these parts is too high. In the history of PI(D) style loops, choosing these gains was known as "Tuning", since people would empirically iteratively choose them in place. With a thermal loop or system, empirically tuning the loop is a long slog.

Start with just the proportional part of the loop, disable the integrator. Start with a low value of gain for the proportional part, maybe unity. Them slowly raise the gain until you see just a hint of oscillation (use ambient conditions that result in maximum gain for the open loop system). When you see some oscillation, reduce the gain. For example reducing the gain by half is a 3dB reduction, which if you have done things carefully would give your loop 3dB of gain margin ... not nearly enough. You will want to shoot for 20dB of gain margin.

In some low performance systems, a proportional loop is all you need. It will have an error that varies with system load, but maybe it's good enough. But, if it is not good enough, then an integral part will be needed. Since you now have a stable system with the proportional part in place, you can start adding gain to the integral part. Follow a similar process of adding gain to the integrator (as you did to the proportional part) to find the maximum stable gain. For a thermal system this will take days, and that is if you get it right the first time.

It is possible that a some point you will find that, for optimal response, you also need to add a derivative part to the loop ... although with thermal systems this is not usually necessary.

Really though, people who are serious about compensating system loop responses will first write a mathematical model of the system. From this they will be able to discern the poles, zeros, and gain that exists in the system, and the sensitivity of these to changes in ambient conditions and load. Then the required compensating proportional part and integral part can be calculated to get optimal values. Then numerical simulations would be run, in a Monte Carlo sort of way, to take care of system variability. This is the only practical way to proceed ultimately. Very little empirical "Tuning" is done anymore, and what is done is very much just fine tuning.

\$\endgroup\$
1
\$\begingroup\$

Solution

It turns out that I wrong about the output going to zero (and no one else spotted this on the graphs?).

The kinked problem was not caused by sub-optimal tuning of P and I. It was caused by the sampling rate being too low! Once we doubled the loop frequency, the output became quite steady. Either way, thanks for the input.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.