Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29720

Re: PID controller: dummy questions

Show all headers | View raw

On 27/06/2020 16:53, pozz wrote:
> Il 27/06/2020 09:07, Rick C ha scritto:
>> On Saturday, June 27, 2020 at 2:12:21 AM UTC-4, Paul Rubin wrote:
>>> DJ Delorie <dj@delorie.com> writes:
>>>> Typical systems will limit the I term to some range so it won't go out
>>>> of bounds (or "wind up" as they say).  It doesn't decay on its own, but
>>>> the system can cause its value to reduce to zero due to the Ki math.
>>>
>>> Do you mean it saturates (controller stops increasing it once it reaches
>>> some maximum)?  Ok, but won't it reach the maximum and stay there?  The
>>> Ki math I think was:
>>>
>>>    I += Ki * err   (note += not = )
>>>    Vout = P + I
>>>
>>> So if the error is almost always positive, I will keep increasing.
>>>
>>>>> E.g. in a thermal system, you have to keep adding heat
>>>>
>>>> Yes, but the amount of extra energy you put in is constant in that
>>>> case,
>>>> and when the extra energy balances so that you stay at your set point,
>>>> the I term stops increasing, because the error is now zero.  Drain more
>>>> hot water, the I term goes up.  Insulate the tank, the I term goes
>>>> down..
>>>
>>> I'm imagining a tank starting with 20 degree water and you want to heat
>>> it to 50 degrees.  Now the error is 30 degrees, or am I interpreting the
>>> wrong thing as the error?  You turn on the heat and the error decreases
>>> as the water gets hotter.  Eventually the water reaches 50 degrees and
>>> the error is 0, but I is some positive number (the integral of the error
>>> over the time it took to reach 50 degrees).
>>>
>>> Now you draw out some hot water, say to wash dishes; you replace it with
>>> more 20 degree water, so the system is say at 40 degrees now (error is
>>> 10).  You turn the heat back on, but again, I keeps increasing.  You
>>> might overshoot a little (say to 51 degrees, error is -1) in which case
>>> I might decrease a little until the tank cools back down.  But really,
>>> the error will always be either positive or near 0.  So I keeps
>>> increasing.
>>>
>>> I have to be missing something.  Thanks.
>>
>> Yes, you are missing that the error variable can be both positive and
>> negative and by definition will balance the I variable to a value that
>> makes error return to zero.
>>
>> Once the water in your heater reaches the set temperature the error
>> will be zero but the heat sent to the water heater won't be zero.  If
>> water is drawn the temperature will drop and the error term will go
>> positive again, the integral term will increase to restore the error
>> to zero, but at that point the heat into the tank will be higher than
>> before so that the temperature will rise above the set point and the
>> error will go negative.
>>
>> It is a mistake to think there will be more positive error than
>> negative error.  Once the water is warmed to the appropriate
>> temperature the integral value will be back at the value it had before
>> cold water was added.
> 
> I think the wrong assumption was: as soon as the error goes to zero, P
> and I term should be zero as well, because we reached the set-point.

Yes - P goes to zero, and I /stabilises/ to a value of output that
results in a steady state.

If you overshoot - perhaps I has built up too much - the error term will
be negative, so the I term will decrease (but remain positive for a
while), while the P term will be negative.

> 
> For example, when I need to move the optical bar of a scanner to a
> certain position.
> As soon as the bar reached the wanted position, the power from the
> motors must be cut off immediately (because the bar doesn't move if the
> motors are off).
> This means that when the error is zero, P+I must be zero as well.

That works for some kinds of systems.  In other systems, you might have
gravity or a spring that means keeping the same position requires a
constant small force - you get that from the I term.

In this case, the I term will be zero at the perfect stable spot.  But
it could well be non-zero while moving - a P term alone rarely gets you
to the target.  (Imagine you are near the target.  The P term might give
too low a force to overcome the static friction and move the bar - then
the I term will build up until things are moving.)

> However this is impossible. P is really zero, but I isn't zero, because
> it's the sum of all the previous errors that are all positive. So the
> power doesn't drop to zero and we have an overshoot (the bar moves after
> the wanted position). Now the error starts being negative and I starts
> decreasing.

Yes.

In any regulation system, you have a balance between reacting quickly to
changes and minimising overshoot and oscillations.  The D term can be
helpful in reducing these unwanted effects.

> 
> I think that systems similar to optical bars (where the controlled
> signal must be stopped as soon as the set-point is reached) is best
> controlled by a P-only algorithm.

You'll never get to the target that way.  Maybe that's okay, and you'll
get close enough.  Sometimes overshoot must be avoided at all costs,
other times it is merely a mild inconvenience - there is no single
answer to all regulation problems.

And pure PID is just one way to regulate a system.  You can use
variations or ad-hoc methods (such as P regulation, but using an
artificial setpoint beyond the real target, or applying a break when you
hit the target), or you can use completely different regulation techniques.

> 
> Now come to mind another scenario. Suppose I need to transfer heat to a
> liquid to reach a set-point temperature, for example 80°C starting from
> 20°C. It's very import to avoid overshoots, because some strange and
> very dangerous chemical reactions happen when the temperature is over 82°C.
> I know I can tune the PID controller (i.e., find an optimal Kp, Ki, Kd)
> to avoid overshoots, but I'm wondering if some other techniques can be
> implemented too.
> 
> For example, changing dynamically PID coefficients when the error is
> negative.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

PID controller: dummy questions pozz <pozzugno@gmail.com> - 2020-06-25 19:55 +0200
  Re: PID controller: dummy questions Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-06-25 21:14 +0200
  Re: PID controller: dummy questions DJ Delorie <dj@delorie.com> - 2020-06-25 15:29 -0400
    Re: PID controller: dummy questions David Brown <david.brown@hesbynett.no> - 2020-06-26 08:43 +0200
  Re: PID controller: dummy questions Richard Damon <Richard@Damon-Family.org> - 2020-06-25 22:21 -0400
  Re: PID controller: dummy questions pozz <pozzugno@gmail.com> - 2020-06-26 10:59 +0200
    Re: PID controller: dummy questions David Brown <david.brown@hesbynett.no> - 2020-06-26 11:07 +0200
    Re: PID controller: dummy questions Rick C <gnuarm.deletethisbit@gmail.com> - 2020-06-26 09:10 -0700
    Re: PID controller: dummy questions Richard Damon <Richard@Damon-Family.org> - 2020-06-26 12:29 -0400
      Re: PID controller: dummy questions Rick C <gnuarm.deletethisbit@gmail.com> - 2020-06-26 12:00 -0700
        Re: PID controller: dummy questions Richard Damon <Richard@Damon-Family.org> - 2020-06-26 22:24 -0400
          Re: PID controller: dummy questions Paul Rubin <no.email@nospam.invalid> - 2020-06-26 21:41 -0700
            Re: PID controller: dummy questions DJ Delorie <dj@delorie.com> - 2020-06-27 01:15 -0400
              Re: PID controller: dummy questions Paul Rubin <no.email@nospam.invalid> - 2020-06-26 23:12 -0700
                Re: PID controller: dummy questions Rick C <gnuarm.deletethisbit@gmail.com> - 2020-06-27 00:07 -0700
                Re: PID controller: dummy questions pozz <pozzugno@gmail.com> - 2020-06-27 16:53 +0200
                Re: PID controller: dummy questions David Brown <david.brown@hesbynett.no> - 2020-06-27 17:31 +0200
                Re: PID controller: dummy questions Rick C <gnuarm.deletethisbit@gmail.com> - 2020-06-27 10:09 -0700
                Re: PID controller: dummy questions Rick C <gnuarm.deletethisbit@gmail.com> - 2020-06-27 15:44 -0700
                Re: PID controller: dummy questions Richard Damon <Richard@Damon-Family.org> - 2020-06-27 12:34 -0400
                Re: PID controller: dummy questions DJ Delorie <dj@delorie.com> - 2020-06-27 11:51 -0400
            Re: PID controller: dummy questions Rick C <gnuarm.deletethisbit@gmail.com> - 2020-06-26 23:06 -0700
              Re: PID controller: dummy questions Paul Rubin <no.email@nospam.invalid> - 2020-06-26 23:18 -0700
                Re: PID controller: dummy questions Rick C <gnuarm.deletethisbit@gmail.com> - 2020-06-27 00:23 -0700
            Re: PID controller: dummy questions Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-06-27 10:28 +0300
            Re: PID controller: dummy questions Richard Damon <Richard@Damon-Family.org> - 2020-06-27 18:13 -0400
    Re: PID controller: dummy questions Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-06-26 22:30 +0200
      Re: PID controller: dummy questions Phil Martel <pomartel@comcast.net> - 2020-06-28 13:10 -0400

csiph-web