Maker Pro
Maker Pro

PI: Integrator implementation

  • Thread starter Marco Trapanese
  • Start date
M

Marco Trapanese

Jan 1, 1970
0
Hi to all,

I've a question about the PI regulators. I'm wondering how to implement
the 'I' part of the following controller. I'm working on a position
controller equipment. So there are a motor and a position sensor which
provides feedback. I need to rotate the motor until it reaches the
desired position.

If I integrate the error signal I get a constant output also when the
system reaches the setpoint. This is because the integrator remembers
the past errors. However, I need the integral part of the controller
because if the system isn't getting close to the setpoint it must
increase the drive signal.

Please, may you provide me a simple C code to understand how to
implement such a controller?

For example, a raw PI (with no bells and whistles such as anti wind up,
output saturation, ecc...) looks like this:

error = setPoint - actualValue;
p = error * kp;
i = intState * ki;
intState += error;
output = p + i;


How to change it?

Thanks
Marco / iw2nzm
 
Hi to all,

I've a question about the PI regulators. I'm wondering how to implement
the 'I' part of the following controller. I'm working on a position
controller equipment. So there are a motor and a position sensor which
provides feedback. I need to rotate the motor until it reaches the
desired position.

If I integrate the error signal I get a constant output also when the
system reaches the setpoint. This is because the integrator remembers
the past errors. However, I need the integral part of the controller
because if the system isn't getting close to the setpoint it must
increase the drive signal.

Please, may you provide me a simple C code to understand how to
implement such a controller?

For example, a raw PI (with no bells and whistles such as anti wind up,
output saturation, ecc...) looks like this:

error = setPoint - actualValue;
p = error * kp;
i = intState * ki;
intState += error;
output = p + i;

How to change it?

You have to add anti-wind-up. If the magnitude of the error is too
high, you have to stop the integral term from winding up.

Effectively this means embedding the "intState +=error" statement
inside a conditional statement which tests for the absoulte magnitude
of "p" and either leaves the integral term alone when "p" is too big,
or resets it to the middle of its range.
 
T

Tim Wescott

Jan 1, 1970
0
Hi to all,

I've a question about the PI regulators. I'm wondering how to implement
the 'I' part of the following controller. I'm working on a position
controller equipment. So there are a motor and a position sensor which
provides feedback. I need to rotate the motor until it reaches the
desired position.

If I integrate the error signal I get a constant output also when the
system reaches the setpoint. This is because the integrator remembers
the past errors. However, I need the integral part of the controller
because if the system isn't getting close to the setpoint it must
increase the drive signal.

Please, may you provide me a simple C code to understand how to
implement such a controller?

For example, a raw PI (with no bells and whistles such as anti wind up,
output saturation, ecc...) looks like this:

error = setPoint - actualValue;
p = error * kp;
i = intState * ki;
intState += error;
output = p + i;


How to change it?
Why change it? It's doing what it's supposed to do. (I'll bet you wanted
to learn something useful, didn't you?).

With a PI controller purely in the forward path, and with most plants, the
control will still have some value to it (because of the integrator state)
when the plant output reaches the target. Consequently, the plant will
overshoot, then come back to the correct position.

There are a number of ways that you can prevent this overshoot if it is a
problem.

One way is to only put the integrator in the forward path, with the
proportional in the feedback path. The response will be slower, but the
overshoot will be diminished or eliminated. You can do a good job of
balancing the overshoot with the reduced speed by splitting up the
position gain between the forward and reverse passes.

Another way is to ramp the target, rather than moving it in steps. This
can significantly reduce the overshoot without slowing you down much.

Yet another way is to play clever games with feedforward, i.e. by
filtering the command signal and adding the filter output to the
controller's output. Feedforward won't change the stability
characteristics of a linear system, but it will change (hopefully for the
better) how it responds to setpoint changes.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
 
R

Rene Tschaggelar

Jan 1, 1970
0
Marco said:
Hi to all,

I've a question about the PI regulators. I'm wondering how to
implement the 'I' part of the following controller. I'm working on a
position controller equipment. So there are a motor and a position
sensor which provides feedback. I need to rotate the motor until it
reaches the desired position.

If I integrate the error signal I get a constant output also when
the system reaches the setpoint. This is because the integrator
remembers the past errors. However, I need the integral part of the
controller because if the system isn't getting close to the setpoint it
must increase the drive signal.

Please, may you provide me a simple C code to understand how to
implement such a controller?

For example, a raw PI (with no bells and whistles such as anti wind up,
output saturation, ecc...) looks like this:

error = setPoint - actualValue;
p = error * kp;
i = intState * ki;
intState += error;
output = p + i;

A standard way is to stop integration when the
output reaches the limitation. But still the I
part leads to an overshoot. This is compensated
with a fairly high P part.

Rene
 
M

MooseFET

Jan 1, 1970
0
A standard way is to stop integration when the
output reaches the limitation. But still the I
part leads to an overshoot. This is compensated
with a fairly high P part.

You can cut the remaining wind up way down if you do this:

... stuff ..
Total = IPart + PPart

if Total > Limit then
IPart = IPart - Total + Limit
Total = Limit

Output Total

Decreasing what is in the integrator when you hit the limit means that
the integrator has to run up once you get near the set point.
 
M

Marco Trapanese

Jan 1, 1970
0
You have to add anti-wind-up. If the magnitude of the error is too
high, you have to stop the integral term from winding up.

Effectively this means embedding the "intState +=error" statement
inside a conditional statement which tests for the absoulte magnitude
of "p" and either leaves the integral term alone when "p" is too big,
or resets it to the middle of its range.


Yes, the actual code has the behavior you described. But the anti-windup
doesn't reduce to zero the integral term. I reset intState when the
output is near the setPoint but it's a bit trivial :)

Marco / iw2nzm
 
M

Marco Trapanese

Jan 1, 1970
0
Tim said:
Why change it? It's doing what it's supposed to do. (I'll bet you wanted
to learn something useful, didn't you?).

Oh, yes, I do :)
With a PI controller purely in the forward path, and with most plants, the
control will still have some value to it (because of the integrator state)
when the plant output reaches the target. Consequently, the plant will
overshoot, then come back to the correct position.

This is exactly what I tried to write in my poor English!
There are a number of ways that you can prevent this overshoot if it is a
problem.

Ok, let's see...
One way is to only put the integrator in the forward path, with the
proportional in the feedback path. The response will be slower, but the
overshoot will be diminished or eliminated. You can do a good job of
balancing the overshoot with the reduced speed by splitting up the
position gain between the forward and reverse passes.

mmm, interesting! I'll give it a try.
Another way is to ramp the target, rather than moving it in steps. This
can significantly reduce the overshoot without slowing you down much.

So are you saying to ramp the set point? Actually, I have a simple IIR
filter on the command signal, so there aren't true steps. Maybe I can
try to increase the filter action.
Yet another way is to play clever games with feedforward, i.e. by
filtering the command signal and adding the filter output to the
controller's output. Feedforward won't change the stability
characteristics of a linear system, but it will change (hopefully for the
better) how it responds to setpoint changes.

This is the more complex solution, so I'll try the others before.

Thank you very much, I'll write here the result of the tests!
Marco / iw2nzm
 
M

Marco Trapanese

Jan 1, 1970
0
MooseFET said:
Total = IPart + PPart

if Total > Limit then
IPart = IPart - Total + Limit
Total = Limit

Output Total


This is also very interesting! Thanks
Marco / iw2nzm
 
Top