why do you need integral action for level control
john
cascades to a flow controller on the total flow out of a vessel, then
this is an integrating process, if the response of the flow is much
faster than the response of the level, a good assumption for the
transfer funtion of the process would be kp/s. Building a software
model of this system, I find that a P-only controller works very well
and gives me steady state accuracy, i.e. I don't need integral control
action.
But if I do this in the plant, I find that I do need a PI-controller;
a P-only controller does not control the level to setpoint.
Why is this? Can somebody explain this to me please.
Peter Nachtwey
is no error the pump must keep pumping fluid out at the rate the fluid
is coming in so there is no net change and there error is maintained
at the SP. Where does this extra signal come from if you are using
only P gain and it sees no error? I bet you see an error in
proportion to the rate the fluid is being added to the tank. You have
found the answer. Use the I gain, It will windup to provide a
control signal in proportion to the flow rate,
Peter Nachtwey
pieter steenekamp
Because your model of Kp/s does not represent your plant.
You must just make a small modification to your model; add the varying
inflow to the controller output before applying it to the integrator
term Kp/s. Then you will find that the model, similar to the real
plant, will also not give steady state accuracy using a P-only
controller, and you will need the I-action for steady state accuracy.
PI Controller works well for level control, but use mainly P-action,
even with very weak I-action the closed loop response is very good.
There's nothing like strong I-action to make level control unstable
very quickly.
Pieter Steenekamp
Peter Nachtwey
wrote:
> On Apr 3, 1:13 pm, "john" <JohnJohn...@gmail.com> wrote:
>
> > According to the theory that I was taught, if your level controller
> > cascades to a flow controller on the total flow out of a vessel, then
> > this is an integrating process, if the response of the flow is much
> > faster than the response of the level, a good assumption for the
> > transfer funtion of the process would be kp/s. Building a software
> > model of this system, I find that a P-only controller works very well
> > and gives me steady state accuracy, i.e. I don't need integral control
> > action.
> > But if I do this in the plant, I find that I do need a PI-controller;
> > a P-only controller does not control the level to setpoint.
> > Why is this? Can somebody explain this to me please.
>
> Because your model of Kp/s does not represent your plant.
>
> You must just make a small modification to your model;
> add the varying
> inflow to the controller output before applying it to the integrator
> term Kp/s
>. Then you will find that the model, similar to the real
> plant, will also not give steady state accuracy using a P-only
> controller, and you will need the I-action for steady state accuracy.
Yes, I said that already.
> PI Controller works well for level control, but use mainly P-action,
How do you justify this?
> even with very weak I-action the closed loop response is very good.
How do you know? Is there an equation to justify your statement?
I don't believe you just stepped in it after I gave the forum a
warning about upgrading the quality of the posts..
> There's nothing like strong I-action to make level control unstable
> very quickly.
OK, but what is strong?
You are right that the OP needs to modify his model. For one thing
the gain is negative because increasing the pump speed makes the level
lower. I have more but I will wait for replies.
John, if you want more information go to
http://www.plctalk.net/qanda/showthread.php?t=26395&highlight=sigreg
There is a Scilab simulator script for your application at or near the
end of the thread. Download Scilab at www.scilab.org.
Peter Nachtwey
pieter steenekamp
> > You must just make a small modification to your model;
> > add the varying
> > inflow to the controller output before applying it to the integrator
> > term Kp/s
>
> Good, How?
You add a summer block with two inputs; one input from the controller
output, and the other on representing the inflow. The output of the
summer is then connected to the input of the pure integrator
representing the vessel.
> >. Then you will find that the model, similar to the real
> > plant, will also not give steady state accuracy using a P-only
> > controller, and you will need the I-action for steady state accuracy.
>
> Yes, I said that already.
Good, we agree then.
>
> > PI Controller works well for level control, but use mainly P-action,
>
> How do you justify this?
To close the material balance around a vessel with a uncontrolled
inflow and controlled outflow, the outflow must equal the inflow, then
the level will be stable. This stable level is not necessarily at the
required value; the setpoint could typically be 50% and this stable
level is maybe 70%.
In this scenario, proportional control action will do nothing, because
the level is not changing, but integral control action will now change
the outflow to make the level equal to the setpoint. But this is now
causing the material balance to go unbalanced. Strong integral control
action will cause strong material unbalance and this makes the closed
loop unstable.
If you do a bode-plot of the pure integrating process, you will also
see that. The P-action does not contribute to the -90 degrees phase
shift caused by the process 1/s term, so, disregarding the other lags
and dead times, P-action will never make an integrating-only process
unstable (In practice there are of cause lags and dead times also, but
still, you will find that with P-action, you can have very strong
control action before the loop goes unstable). I-action, on the other
hand, contributes another -90 degrees phase shift and with even the
slightest additional lag and dead time (that you always get in real
processes), the closed loop goes unstable very easily.
My experience over many years back this up too. In process plants I
have found many LCs with strong oscillatory closed loop behaviour. I
normally then just decrease the integral control action by a factor of
10, and increase the proportional control action by a factor of two,
and nine times out of ten, the closed loop response is then
significantly better. Try this.
Pieter Steenekamp
Bob
a real problem in all cases?) for a Level Loop lies in the 'bias'
value associated with the P-Only Controller.
The typical P-Only controller form is Output = BIAS + GAIN*ERROR.
For an integrating process (ie: a level loop), as mentioned earlier,
is only steady at its balancing point, (outflow=inflow). If the BIAS
value is set to the value of the controller output that makes the
outflow (if controller based on outflow) equal to the inflow then a P-
Only controller will not result in offset from SP. Now this is where
the 'real-world' kicks in, since the inflow is a wild-stream, you
would constantly have to change the BIAS to compensate, which is
basically what integral action does, albeit in a much less intelligent
fashion.
I have also seen papers on an internal feedback method (Sung and Lee
(1996) and Arbogast (2006)) that basically use an inner controller to
stabilize the non self-regulating process and an outer controller
which now sees a self-regulating (stable) process; its basically a
cascaded system where both controllers use the same process
variable.
Bob Rice
Peter Nachtwey
wrote:
> I-action, on the other
> hand, contributes another -90 degrees phase shift and with even the
> slightest additional lag and dead time (that you always get in real
> processes), the closed loop goes unstable very easily.
If you don't have enough integrator gain the tank will overflow before
the motor winds up enough to match the flow. It would be a real shame
to have the tank over flow when the flow is well within the capacity
of the pump just because the integral action is too low. So what
gain is is too high? We don't know becasue we don't really know what
John's system but the formulas within the tanklevel.sce allow one to
simulate what will happen one real numbers are entered for the plant.
One should be able to predict the maximum error in the level that
occurs as the flow goes from 0 to 100%. This would be handy because
then well will know if the tank will overflow. Unfortunately I didn't
include those computations in the tanklevel.sce. I also didn't plot
the in flow rates but you can add that. Notice that in the
tanklevel.sce there are some equations that calculate the PID gains as
a function of the plant gain, time constant and a closed loop time
constant. The tanklevel.sce program doesn't assume the pump will
respond instantly so the tanklevel.sce is just a little more
complicated. The response is supposed to be a critically damped
response. Take a look at the integrator gain or time constant. It is
calculated. The point here is that I don't have to fly by the seat
of my pants and neither does John now.
So what model did I use? Bob, I know you know.
if you don't have the model then how do you make one a phase-gain/
nichols charts to prove the system is stable or unstable?
Peter Nachtwey
pieter steenekamp
> the motor winds up enough to match the flow. It would be a real shame
> to have the tank over flow when the flow is well within the capacity
How do I just love this! I very nice technical challenge.
I am at the airport on my way to see a customer, so I can't do it
right now. But I will stick my neck out and make a statement and say
how I will test it. Maybe I'll be wrong, then I'll eat humble pie, but
who's right or wrong is not really the issue, we both want to help
John.
My statement is that your statement quoted above is wrong. Let me
qualify that: if you have a steady tank with the level at setpoint and
a disturbance is applied to the system, in the form of a change in
inflow, with the level control on outflow (typical arrangement in
process industries), P-only control will be able to give stronger
disturbance rejection than PI-control. (This is not typical objective
in the a typical process industries application)
I had a quick glance at the reference you gave above, so I'll try to
proof my statement using your Scilab models (I might of course need to
adjust it to reflect my scenario). I'll do it before Monday and get
back to this forum (maybe I'll proof myself wrong, but I won't have a
problem in admitting it, all I want is to help John)
Pieter Steenekamp
pieter steenekamp
wrote:
I think I've done it. Thanks for the challenge Peter.
I have taken Peter's Scilab program from the reference earlier, and
modified it to test disturbance rejection as opposed to setpoint
tracking.
My motivation for this is that there are many tank level controllers
with the setpont fixed for years, but the inflow changes all the time.
Given this scenario, response on inflow changes is more important than
setpoint tracking.
Peter made a statement that I interpreted that with P-only control,
the tank would overflow easier. So I tried to proof the opposite.
I used the Scilab simulation to get the proportional gain that will
minimise level disturbance on a step change in inflow, with a constant
setpoint, and then noted this max level variation, for different
integral control time constants.
Results:
Int time Gain for min level disturbance level disturbance (mm)
0.5 -7700 16.0
1.0 -8500 15.5
No -9200 15.2
Conclusion
If you tune the controller for minimum level disturbance on a step
change in inflow, then the more integral control action you use, the
bigger the level variation.
Warning
This is not a recommendation of how to tune a level controller.
You need integral control for steady state accuracy, but a very small
amount is sufficient.
Strong control action is in many cases not a very good way to tune a
level controller. Normally it's better to detune it to make use of the
surge capacity in the vessel.
Pieter Steenekamp
Appendix: Peter's Scilab program as modified by Pieter for the above
// TANK LEVEL CONTROL
Kp=-0.2368; // pump gain. (m^3/m)/CO%
Tp=1/12; // plump time constant. minutes
Kt=0.0279; // 1/(tank surface area) 1/m^2
Tc=0.25; // closed loop time constant. minutes
//Kc=-605.444; // controller Gain. percent output per meter of
error
//Ti=3*Tc; // integrator time constant minutes
Kc = evstr(x_dialog('controller Gain ?','-605.444'));
Ti = evstr(x_dialog('integrator time constant minutes ?','0.75'));
T=1/120; // simulation update period minutes
PV(1)=2; // fluid level meters
ui(1) = -10/Kp; // integrator contribution to CO
flow_in = 10; // flow in. m^3/min
CO(1) = -flow_in/Kp ; // control output. percent of full output
flow_out(1) = -10; // flow pumped out. m^3/min
maxLevel=0;
N=round(10/T); // CONVERT TO SAMPLE TIMES
for n=1:N; // simulate 10 minutes
SP(n)=2; // set point meters
if n==10 then
flow_in=20;
end
// calculate the rate of change in flow_out. This uses the simple
differential
// equation Tp*flow_out_dot+flow_outy=Kp*CO(n). Note flow_out is
negative.
flow_out_dot(n) = -flow_out(n)/Tp + (Kp/Tp)*CO(n);
// calculate the new flow out by adding the rate of change times T
flow_out(n+1) = flow_out(n) + flow_out_dot(n)*T;
// integrate the difference between the flow in and flow out.
PV(n+1) = PV(n) + Kt*(flow_in+flow_out(n))*T;
if PV(n+1) > maxLevel then
maxLevel = PV(n+1);
end
err(n) = SP(n) - PV(n); // calculate error
up(n+1) = Kc*err(n); // calculate the proportional control
output percent
if Ti>0 then
ui(n+1) = ui(n) + (Kc*T/Ti)*err(n); // calculate the integrator
control output percent
else
ui(n+1) = ui(n);
end
CO(n+1) = ui(n+1) + up(n+1); // the control output is the sum of
the integrator and proportional terms
end
PV($)=[]; // LIMIT TO 1200 ITEMS
CO($)=[];
// PLOT THE SIMULATION
// CREATE TO PLOTS USING THE SUBPLOTS FUNCTION
// THE TOP PLOT SHOWS THE SP AND PV. THE BOTTOM PLOT SHOWS THE CO
t=T:T:N*T; // COMPUTE TIME INDEXES. START A TIME T IN INCREMENTS OF T
TO N*T
clf(); // CLEAR OR RESET THE CURRENT GRAPHICS FIGURE
subplot(2,1,1); // PLOT TEMPERATURES ON THE TOP PLOT
plot(t,[SP PV]);
xtitle('Tank Level Control Simulation','Time In Minutes','Tank
Level');
legend("SP","PV");
subplot(2,1,2); // PLOT CONTROL OUTPUT ON THE BOTTOM PLOT
// PLOT THE CONTROL OUTPUT TERMS
plot(t,[CO]);
xtitle('Tank Level Control Simulation','Time In Minutes','Control
Output%');
legend("CO")
maxDeviation = maxLevel - 2
Peter Nachtwey
wrote:
> Peter made a statement that I interpreted that with P-only control,
> the tank would overflow easier. So I tried to proof the opposite.
>
> I used the Scilab simulation to get the proportional gain that will
> minimise level disturbance on a step change in inflow, with a constant
> setpoint, and then noted this max level variation, for different
> integral control time constants.
>
> Results:
> Int time Gain for min level disturbance level disturbance (mm)
> 0.5 -7700 16.0
> 1.0 -8500 15.5
> No -9200 15.2
>
> Conclusion
> If you tune the controller for minimum level disturbance on a step
> change in inflow, then the more integral control action you use, the
> bigger the level variation.
>
> Warning
> This is not a recommendation of how to tune a level controller.
> You need integral control for steady state accuracy, but a very small
> amount is sufficient.
> Strong control action is in many cases not a very good way to tune a
> level controller. Normally it's better to detune it to make use of the
> surge capacity in the vessel.
This is a good example of the problem with the tweak this gain here
and tweak that gain here iterative approach to tuning. If you tweak
the gains individually you are moving the poles. When you increased
the integrator gain how did you affect the poles? Chances are you
changed my critically damped response and changed it to something
under damped that wouldn't respond well to disturbances. Hence your
reaction is that more integrator gain is bad. The sad part is that
you will believe this for the rest of your life. Now do this my
way. First, run the original program. You will see the middle
disturbance shows an error of about 90mm. Now ONLY reduce the closed
loop time constant, tc, from .25 to .2 minutes and run the program
again. Now you will see the disturbance caused error of just over
60mm. How can this be? According to you increasing the integrator
gain should make the error worse. By making the close loop time
constant smaller you moved the poles to the left on the negative real
axis. If you look at the equation for Ti you will see that if was
reduced from .75 minutes to .6 minutes which effectively makes the
gain larger yet the error caused by the disturbance is MUCH smaller.
You can reduce this error even more by making .1 minutes.
The point is that you must look at the end goal. The goal is the
desired response, not a procedure for twiddling gains. The response
is dictated by where the poles and zeros are. So the first sub goal
is to move the poles and zeros to a place that will result in the
desired response. The PID gains are just a method of getting the
poles to the desired location. So what do you do? Change the PID
gains one at a time and hope they get you to the desired goal or do
you move the poles and then calculate out what the gains should be to
achieve those goals. Even if you change one PID gain in the right
direction, the poles may not move closer to the desired location and
there resulting response will be worse. Therefore you will come to
conclusions like you did that increasing the integrator gain is bad.
Lets take a detour back to the iterative tuning thread. Given the
knowledge from that all gains should be changed together or then you
can see that iterative tuning one gain at a time may not going to lead
you to the best results unless you can find a way to change all the
gains at the same time. If you looked at the article, to which I
posted a link, you will see is based on changing all the gains at once
by calculating the gradient of how the error changes as function of
the gradient of each gain. From this calculates a vector or
direction of change and there is a term that limits how much. This
is a method.
I just wish there was some that had actually implemented this method.
Finally, when I am twiddling gains I still have those equations in my
head but I think about it differently that the rest of you. I think
about what the system identifier did wrong. I can usually tell by
looking at the graph of the estimate response to the actual response.
I know how to change all the gains if a the estimated plant time
constant is too long and the plant time constant should be shorter.
I then think about how the a shorter plant time constant will change
all the gains.
Peter Nachtwey
pieter steenekamp
apples and I'm talking pears.
> The point is that you must look at the end goal. The goal is the
> desired response, ...
I can't but agree very strongly with this point; only by agreeing on
the end goal can you compare apples with apples. I will mention three
different possible end goals below.
First one is if you want to minimise the closed loop response time on
setpoint changes. Here I would support your arguments and follow your
design philosophy. Specific proportional and integral control tuning
coefficients would give the "best" response, and my statement of "more
integral control action is bad" would be wrong.
As an alternative consider a surge vessel where the objective is to
maximise (as opposed to the above minimising) the loop response time
on inflow disturbances, with the provision that you don't violate high
or low limits. Although very typical, this is still not my apples.
Let's move on.
Yet another end goal is simply to, starting from a stable system with
no setpoint changes, to minimise the level deviation on inflow
disturbances. With this being the case, and you tune the controller
ending up with non-negative P- and I- settings, using any method you
like, you can find other settings with less I-action that will give a
smaller level deviation on the same inflow disturbance.
I used your program and model coefficients to demonstrate this "more
integral control action is bad" point.
Pieter Steenekamp
Peter Nachtwey
> Thanks for the response Peter. I agree with you, but you're talking
> apples and I'm talking pears.
Yes, I am talking about being an engineer and doing a good job of
calculating or at least estimating instead of guessing or trial and error.
> As an alternative consider a surge vessel where the objective is to
> maximise (as opposed to the above minimising) the loop response time
> on inflow disturbances, with the provision that you don't violate high
> or low limits. Although very typical, this is still not my apples.
> Let's move on.
No problem. If you can model the system you can do that too. How are
you going to compute how much error is permissable?
> Yet another end goal is simply to, starting from a stable system with
> no setpoint changes, to minimise the level deviation on inflow
> disturbances. With this being the case, and you tune the controller
> ending up with non-negative P- and I- settings, using any method you
> like, you can find other settings with less I-action that will give a
> smaller level deviation on the same inflow disturbance.
I am beginning to think you are a lost cause. You didn't try my
suggestion of reducing the Tc ( closed loop time constant ). As you say,
increasing only the integrator is bad. When you do that the critically
damped response becomes under damped. I have said that before and I am
getting tired of repeating myself. The gains should be moved together
because the goal is to move the pole(s) in the desired direction, not
tweak a gain.
> I used your program and model coefficients to demonstrate this "more
> integral control action is bad" point.
One more chance. Change the closed loop time constant to .2 minutes and
see the difference. Note that changing the closed loop time constant
changes all the gains, not just the integrator time constant. That is
because changing the closed loop time constant actually move the poles
along the negative real axis.
Peter Nachtwey
pieter steenekamp
> suggestion of reducing the Tc ( closed loop time constant ). As you say,
It's interesting, that's exactly how my wife describes me too. And
then also, ever since primary school, I was one of the slow learners
in class, I haven't been very quick to pick up complex mental things.
So if you don't mind taking it slowly - let's leave the pole placement
and theoretical stuff for now, and just show me an example to proof
your point, if you can of course!
Please give me a Scilab (or any other "free" package, to share it with
the world, it's maybe unfair to expect the world to use an expensive
package) program, representing a tank with a varying inflow, level
control on the outflow, starting from steady state with the level at
setpoint and a step change in inflow. Then give us the PI controller
tuning, with greater than zero integral action, that will minimise the
maximum level error, and I will respond by taking your model
coefficients and your program and reduce your integral control action,
use my practical, no theory, iterative tuning, and the result will be
smaller maximum level error, for the same inflow disturbance. How's
that for a challenge!
I have done a similar exercise to demonstrate my point. I have taken
Peter's program from the reference given above, changed the
configuration to reflect the said scenario, and found the proportional
control for different integral control settings to minimise the
maximum level error. My conclusion was that the less integral control,
the smaller the maximum level error. Please refer to a previous
posting in this thread. If you don't agree, show me my error please.
The scenario I explained is not too uncommon - there are many (maybe
not most applications, but still not too uncommon) tanks where the
main objective of the level control is just to keep it from
overflowing or emptying. Tuning based on this objective will be good
for these applications. (Again, this is NOT valid for all level
controllers, this is a special case only)
I don't particularly care about me, feel free to call me names if
makes you feel better, but I'd like to continue this to some
conclusion for the other readers of this forum. So the challenge is
not only for Peter, but any other reader of the forum.
In the meantime my advice to the control world is that, given the said
objectives, less integral control is better. I do realise that even
hundred positive examples won't proof it, but one negative will proof
it wrong, but still, as a demonstration of my point, refer to the
Scilab program with different tuning settings that I gave earlier in
this thread.
Pieter Steenekamp
john
helpful.
Pieter's conclusion seems to be valid that for level control, it's
better to use less integral action.
I have taken his Scilab program and tried the three different tuning
sets provided. This does indicate that, for this model in any case, on
inflow disturbances a smaller integral control time constant (less
integral action) results in a smaller maximum level deviation. (It
seems like he used iterative tuning to find the best proportional
action for each different integral time). I have also tried some other
values and they confirm the general relationship of less integral
action resulting in smaller level deviation.
We have one application like this on our plant where the pump often
trips on low tank level and I have tried, without spectacular success,
tuning the LC to prevent this. I now realize that my integral control
action is probably too strong. I will go and try a combination of
weaker integral and stronger proportional control to prevent low level
trips. Fortunately, on this application, a sharp drop in feed,
resulting in a low level (and pump trip), is never followed closely by
another sharp drop in feed, so it's not required to recover the level
to setpoint fast after a drop in feed; in fact it's probably good if
it then stays low. We have one very constant flow going into the tank,
and another one that changes between low and high flow. The issue is
simply to prevent a low level trip.
This does raise the following questions though:
a) Is this Scilab model a good representation of a tank level
arrangement in real plants?
b) Are there other typical tank level arrangements for which this
conclusion is not valid?
c) Would it also be valid for the control structure of a LC cascading
to a FC that we typically use on our chemical plant?
john
Peter Nachtwey
> Thanks to all the contributors for all the comments; they are very
> helpful.
>
> Pieter's conclusion seems to be valid that for level control, it's
> better to use less integral action.
That is only because you didn't follow the thread.
http://www.plctalk.net/qanda/showthread.php?t=26395&highlight=sigreg
Pieter modified the program so that it proved his point by disabling the
the code that computed the PID gains by just changing the closed loop
time constant.
>
> I have taken his Scilab program
First, it isn't his program. He modified mine, you would know that if
you follow the thread. He removed the code that would prove my point
and inserted his own so he could play his trial and error games.
and tried the three different tuning
> sets provided. This does indicate that, for this model in any case, on
> inflow disturbances a smaller integral control time constant (less
> integral action)
A smaller time constant results in more integral action
results in a smaller maximum level deviation. (It
> seems like he used iterative tuning to find the best proportional
> action for each different integral time). I have also tried some other
> values and they confirm the general relationship of less integral
> action resulting in smaller level deviation.
If you look at the original program you will find the opposite.
> We have one application like this on our plant where the pump often
> trips on low tank level and I have tried, without spectacular success,
> tuning the LC to prevent this. I now realize that my integral control
> action is probably too strong.
No, it is probably a poorly implemented PID. Again look at the orignal
program and change the Tc ( closed loop time constants ) from .25 to .1
minutes. Change the final flow_in to 0. Now try the Tc at 0.25 (
Ti=.75) then try Tc=0.1 ( Ti=.3). You will see the level stops receding
faster when the Tc=0.1 and the integrator time constant is smaller (
higher gain ). At this point I am not sure if Pieter isn't confused
,like you are, about the relationship time constant and the gain.
Longer integrator time constants result in lower integrator gains.
I will go and try a combination of
> weaker integral and stronger proportional control to prevent low level
> trips. Fortunately, on this application, a sharp drop in feed,
> resulting in a low level (and pump trip), is never followed closely by
> another sharp drop in feed, so it's not required to recover the level
> to setpoint fast after a drop in feed; in fact it's probably good if
> it then stays low. We have one very constant flow going into the tank,
> and another one that changes between low and high flow. The issue is
> simply to prevent a low level trip.
>
> This does raise the following questions though:
> a) Is this Scilab model a good representation of a tank level
> arrangement in real plants?
Read the thread. The problem was submitted by a young engineer in Poland.
> b) Are there other typical tank level arrangements for which this
> conclusion is not valid?
Yes, the pump can be on the inlet or the outlet.
> c) Would it also be valid for the control structure of a LC cascading
> to a FC that we typically use on our chemical plant?
Yes, but I doubt that your flow controller can change the flow rate
instantly. SIGreg in the thread said his pump definitely had a time
constant and took time to change speeds. The model in the www.plcs.net
thread assumes the pump or flow controller has a time constant.
Before Pieter lures you to the dark side you really should look at the
whole thread and download the program that is there. It is obvious to
me that Pieter has not followed my advice. He never tried just changing
the Tc so that all the gains are changed at once.
Peter Nachtwey
john
> john wrote:
> > Thanks to all the contributors for all the comments; they are very
> > helpful.
>
> > Pieter's conclusion seems to be valid that for level control, it's
> > better to use less integral action.
>
Please help me.
I tried to follow your recommendations very carefully, but the
response does not look like it reflects my problem; the PV is not
equal to the SP when the run starts.
So I changed the SP(n)=0 and kept the flow_in = 20. This does seem to
reflect my problem. It is also very typical in the chemical process
industry where I work; the PV=SP for long periods with everything else
also steady. Then there is a sudden inflow upset. I'd like the
simulation to reflect this scenario. And this is the way Pieter
described his scenario and his modifications to your program seems to
reflect this too. Your's do not.
I then ran your program with above mod to reflect my problem and
tested your two recommended values, and then also ran it with Pieter's
recommended tuning of P=only control
Your first recommendation:
Tc=0.1
Max level deviation = 0.1081467
Your second recommendation:
Tc=0.25
Max level deviation = 0.1208479
Pieter's recommended tuning Kc = -9200 (no integral action):
Max level deviation = 0.0440022
Did I do anything wrong?
john
Peter Nachtwey
> On Apr 8, 4:10 pm, Peter Nachtwey <pnacht...@comcast.net> wrote:
>
> Please help me.
>
> I tried to follow your recommendations very carefully, but the
> response does not look like it reflects my problem; the PV is not
> equal to the SP when the run starts.
So is the level lower or higher than the set point? If the level is
much higher then the pump will be on 100% until it approaches the SP If
the level is lower the pump can do nothing. It must remain off. Try
changing my program so that PV(1)=2.5 and then PV(1)=1.5
>
> So I changed the SP(n)=0 and kept the flow_in = 20. This does seem to
> reflect my problem.
Notice that the pump gain is only -0.2368 m^3/min/%CO. At 100% this
example can only pump 23.68 M^3/min. It would be close to the maximum
capacity and couldn't get the level down to the set point very quickly.
Does your pump work at maximum capacity very often?
It is also very typical in the chemical process
> industry where I work; the PV=SP for long periods with everything else
> also steady. Then there is a sudden inflow upset. I'd like the
> simulation to reflect this scenario.
What kind of disturbance do you want? Change the in_flow values on my
program to reflect the disturbance you want.
And this is the way Pieter
> described his scenario and his modifications to your program seems to
> reflect this too. Your's do not.
GET MY PROGRAM and don't bother to comment until you do! You have been
led astray by sloppy programming. Pieter obviously didn't understand my
trick to limited integrator wind up so he removed it which will make
using an integrator look bad. My program changes the in_flow as a
function of time to reflect disturbances. If you had run my program you
wouldn't make false statements like mine program does not reflect
disturbances. Read the original thread on PLCs.net. Pieter removed
some of the vital parts of my program like the limit on the output of 0
to 100%. I think I can get better results if I didn't have to worry
about details like that. He also removed the derivative gain or time
constant and that is required to keep a critically damped response and
avoid overshoot. One more thing that he did is that his disturbance goes
from 10 to 20 m^3/min. Whereas mine goes from 5 to 20m^3/min
>
> I then ran your program with above mod to reflect my problem and
> tested your two recommended values, and then also ran it with Pieter's
> recommended tuning of P=only control
>
> Your first recommendation:
> Tc=0.1
> Max level deviation = 0.1081467
My program didn't calculate the max level deviation. Did you add it or
are you using Pieter's messed up version.
0.029769
That beats Pieter's easily even though my disturbance goes form 5 to 20
m^3/min instead of just 10 to 20.
>
> Your second recommendation:
> Tc=0.25
> Max level deviation = 0.1208479
On my program it is 0.091695 even with the 5 to 20 m^3/min disturbance.
>
> Pieter's recommended tuning Kc = -9200 (no integral action):
> Max level deviation = 0.0440022
>
> Did I do anything wrong?
WHY ASK ME? YOU AREN'T DOING WHAT I ASK ANYWAY!
YES, YOU USED PIETER's PROGRAM!!!
I told you were to get my program and to read the thread.
When I run Pieter's program with Kc=-9200 it oscillates. I doubt the
even the Tc as low as 0.1 minutes is practical. Think about this, if
the gain is -9200 that means that 1 mm of ripple in the tank will cause
the output to change by 9.2 percent. Quantizing and noise will also be
a problem.
Peter Nachtwey
Fred Thomasson
modeled as Kp/s and we control the flow out with a linearized flow control
valve (just to make the problem simple) using a standard ISA PID
controller. The tuning will be for disturbance rejection - where the
disturbance is a change in the inlet flow. Let us look at the root locus
sketch as the proportional gain increases from zero to infinity for a fixed
integral gain. There will be two poles at the origin for Kc = 0. As Kc is
increased, the closed loop poles move into the left hand plane and the
sketch forms a circle. The two poles converge on the negative real axis when
Kc = Ki/15Kp. Ki is in repeats per minute and Kc is the proportional gain
and Td = 0. These poles will be at -KpKc/2. If Kc is increased further, the
two poles travel on the negative real axis (one toward the origin and the
other toward - infinity. For Kc less than Ki/15Kp, the response will be
under damped. It is critically damped for Kc = Ki/15Kp. For Kc greater than
Ki/15Kp, the response will be overdamped. If you want it be critically
damped, you would have to adjust Kc every time you adjusted Ki. However if
the Kc is large so that you are overdamped, you can tweak Ki without
adjusting Kc (as long as the poles stay on the real axis) and this is what I
often do.
The concept of Allowable Level Variation (ALV) simplifies tuning of the
level controller. First you must do an open loop bump test to get an
estimate of Kp. The ALV is the maximum variation from setpoint that you will
allow under regulatory operation. It is expressed in %. Use the largest ALV
possible so the tank can absorb the disturbace. The tuning equations are:
Kc = 100/ALV, Ki = 15KcKp (for critical damping). Then decrease the Ki
some to make the response more robust. During my 30 year career in the Pulp
& Paper Industy, I used this method on hundreds of tank level controllers.
"Peter Nachtwey" <pnac...@comcast.net> wrote in message
news:zNKdnW-JOoJazYTb...@comcast.com...
luhi...@yahoo.com
I am very happy to confirm that, yes it is true that, if you start a
level from steady with level at required value, then the input floe
changes, and you are not concerned about the level coming back fast,
it is better to use only proportional control. That is because I have
been doing it for years with good success, and just confirmed it using
different models. I normally do add at least a very tiny bit of
integral control; maybe use an integral time constant of 1000 times
the time it would take the tank to empty from full with no in-flow and
maximum controller output. In really difficult cases, when the
"actuator" behaves like it has significant dead time, I have been
forced to use even longer integral time constants to achieve
acceptable response. (I use inverted commas, because it is mostly the
process arrangements causing this apparent dead time and not directly
the actuator, but for modeling purposes you can just as well model it
as though the actuator is sluggish)
I followed this thread and did do testing, and found, yes indeed, the
simulations confirm my experience. If you have a difficult level
control, prone to level reaching high and/or low limits, and you are
not worried with other things, like changing the controller output
fast, or the level actually at SP, then indeed if you use less
integral control you can then use stronger proportional control
without level going unstable, and this will give you less risk of
level tripping on low or high limit. Especially if an increase in-flow
is not normally followed shortly by another increase in in-flow. This
will make it that if you "caught" the level from violating the limit
with proportional control, very weak integral action is sufficient to
bring to back to SP very slowly.
I read Mr. Peter Nachtway concerns that they did not use his program
so I check. So I see Mr. Peter Nachtway's program does not model the
issue at hand. So I said, no problem it is very easy to make very
small change so that the program of Mr. Peter Nachtway does indeed
model the issue at hand. I was very careful not to change the other
things that he said Mr. Pieter Steenekanp changed. Please look below
for the program after I made the changes.
Please note Mr. Peter Nachtway, I did not use Mr Pieter Steenekanps
program. I copied the one in the reference you gave in the thread and
modified it, using absolutely minimum modifications, just to test the
response from steady state when the in-flow changes. Please don't get
mad at me too! I am already shit scared to write this posting, but I
think I owe it to the other people to share my experience and testing
results using your program.
So I also download Scilab. This is a very nice package. I then also
build other models using the Scicos application in Scilab to test this
statement and found it to be generally true. There might be some
strange combinations or conditions that makes it untrue, but
consistent with my doing it practically and testing many, including
Mr. Peter Nachtway's (see below) models, I am very confident that it
is true and valid and a good practical tuning method.
Of course, in Mr Peter Nachtway's this model - do not interpret the
tank level as the actual level, consider it to be the changes from
steady state. You can change the program of course to reflect actual
level, but when Mr. Pieter Steenekanp did that, Mr Peter Nachtway got
mad, so I rather make minimum changes to Mr. Peter Nachtway's program.
I don't like it when Mr. Peter Nachtway get mad.
But on the other hand, this proportional-only control using a gain of
-9200 is indeed very strong, with a strong under-damped, but still not
unstable, behavior. So I reduced the proportional gain, but the
maximum level is still smaller than if you have any integral control.
But on the other hand, this model is "very kind" to some difficult
tank level controls in the chemical industry. So I build a Scicos
model of tank level control, but instead of the pump having just a
single lag, I added two more lags, also including some dead time, to
make the closed loop control "not so very kind". And I changed the
coefficients to try to duplicate the problem that Mr. John Jay
described. With Mr Peter Nachtway's model coefficients you will very
easily prevent a low level trip. So there must be some other
combination of model parameters replicating this problem. So I found
this by adding apparent dead time to the "actuator" and made the tank
surface area smaller.
And indeed, I also find that for "not so very kind" applications, if
the tank is prone to empty on an in-flow disturbance, and if there is
a more sluggish response (like in 3 lags in series, or dead time)
included, the conclusion is not only valid, but it translates to very
practical way of tuning the level control. Although it is true for Mr.
Peter Nachtway's coefficients, this represents a "very kind" level
control and it does not really make much of a difference. Although the
statement is true, it does not translate to practical advice unless
you start with a level control that is difficult to tune to prevent
level trips.
Please Mr Peter Nachtway, don't get mad. Just give us a model to show
us that we are wrong. Don't say we must read your thread, because your
thread is very helpful for another application, not this one. Just
show us your model, representing a level control starting from steady
state, with the level at SP. Then test the response on a change in in-
flow. Then you try it out with your PI control, and then also with the
P-only control giving the smallest level deviation. If you find that
PI-control does better, try to increase the gain of the P-only
control, until you get to the point where it goes unstable and does
indeed not decrease the maximum level deviation further. If you find
the biggest gain for the proportional-only controller so that if you
increase the gain further, the maximum level deviation increases, and
this maximum gain for the proportional-only control gives a maximum
level deviation that is larger than the maximum level deviation of
your PI-controller with non-negative integral control action, then you
will have proofed your point. If you achieve that I would say: well
done Mr. Peter Nachtway, you taught me something very useful, thank
you very much. And I will go and find where did I go wrong.
Thank you very much
Lu Hing
// Mr. Peter Nachtway's program with very small modifications by Mr.
Lu Hing
// to represent the case where you start from steady state
// with level at required value and there is a change in in-flow.
// TANK LEVEL CONTROL
maximumLevel=0; // added by Mr. Lu Hing to check the maximum level
Kp=-0.2368; // pump gain. (m^3/m)/CO%
Tp=1/12; // plump time constant. minutes
Kt=0.0279; // 1/(tank surface area) 1/m^2
Tc=0.25; // closed loop time constant. minutes
Tc=0.1; // closed loop time constant. minutes
Kc=-605.444; // controller Gain. percent output per meter of error
Ti=3*Tc; // integrator time constant minutes
// For Mr. Peter Nachtway's tuning keep the following commented out,
to test proportional only, delete the comment signs
// Ti = 1000000 // added by Mr. Lu Hing to practically remove
integral so to check proportional control only
// Kc = -9200 // added by Mr. Lu Hing to check strong
proportional control
T=1/120; // simulation update period minutes
PV(1)=0; // fluid level meters
CO(1)=0; // control output. percent of full output
ui(1) = 0; // integrator contribution to CO
flow_in=20; // flow in. m^3/min
flow_out(1)=0; // flow pumped out. m^3/min
N=round(10/T); // CONVERT TO SAMPLE TIMES
for n=1:N; // simulate 10 minutes
SP(n)=2; // set point meters
SP(n)=0; // added by Mr. Lu Hing to check max level on inflow
disturbance from steady state and not from SP change
// calculate the rate of change in flow_out. This uses the simple
differential
// equation Tp*flow_out_dot+flow_outy=Kp*CO(n). Note flow_out is
negative.
flow_out_dot(n) = -flow_out(n)/Tp + (Kp/Tp)*CO(n);
// calculate the new flow out by adding the rate of change times T
flow_out(n+1) = flow_out(n) + flow_out_dot(n)*T;
// integrate the difference between the flow in and flow out.
PV(n+1) = PV(n) + Kt*(flow_in+flow_out(n))*T;
// added by Mr Lu Hing to test the maximum level deviation
if PV(n+1) > maximumLevel then
maximumLevel = PV(n+1);
end
err(n) = SP(n) - PV(n); // calculate error
up = Kc*err(n); // calculate the proportional control output
percent
ui = ui + (Kc*T/Ti)*err(n); // calculate the integrator control
output percent
if ui > (100-up) then // limit the integrator contribution to the
control output
ui = 100-up;
elseif ui < 0-up then
ui = 0-up;
end
CO(n+1) = ui + up; // the control output is the sum of the
integrator and proportional terms
end
PV($)=[]; // LIMIT TO 1200 ITEMS
CO($)=[];
// PLOT THE SIMULATION
// CREATE TO PLOTS USING THE SUBPLOTS FUNCTION
// THE TOP PLOT SHOWS THE SP AND PV. THE BOTTOM PLOT SHOWS THE CO
t=T:T:N*T; // COMPUTE TIME INDEXES. START A TIME T IN INCREMENTS OF T
TO N*T
clf(); // CLEAR OR RESET THE CURRENT GRAPHICS FIGURE
subplot(2,1,1); // PLOT TEMPERATURES ON THE TOP PLOT
plot(t,[SP PV]);
xtitle('Tank Level Control Simulation','Time In Minutes','Tank
Level');
legend("SP","PV");
subplot(2,1,2); // PLOT CONTROL OUTPUT ON THE BOTTOM PLOT
// PLOT THE CONTROL OUTPUT TERMS
plot(t,[CO]);
xtitle('Tank Level Control Simulation','Time In Minutes','Control
Output%');
legend("CO")
maximumLevel // added by Mr Lu Hing to display tha maximum deviation
Peter Nachtwey
>
> I am very happy to confirm that, yes it is true that, if you start a
> level from steady with level at required value, then the input floe
> changes, and you are not concerned about the level coming back fast,
> it is better to use only proportional control. That is because I have
> been doing it for years with good success, and just confirmed it using
> different models.
What about the offset in the level?
> I normally do add at least a very tiny bit of
> integral control; maybe use an integral time constant of 1000 times
> the time it would take the tank to empty from full with no in-flow and
> maximum controller output.
That isn't very much.
In really difficult cases, when the
> "actuator" behaves like it has significant dead time, I have been
> forced to use even longer integral time constants to achieve
> acceptable response. (I use inverted commas, because it is mostly the
> process arrangements causing this apparent dead time and not directly
> the actuator, but for modeling purposes you can just as well model it
> as though the actuator is sluggish)
>
> I followed this thread and did do testing, and found, yes indeed, the
> simulations confirm my experience. If you have a difficult level
> control, prone to level reaching high and/or low limits, and you are
> not worried with other things, like changing the controller output
> fast, or the level actually at SP, then indeed if you use less
> integral control you can then use stronger proportional control
> without level going unstable, and this will give you less risk of
> level tripping on low or high limit. Especially if an increase in-flow
> is not normally followed shortly by another increase in in-flow. This
> will make it that if you "caught" the level from violating the limit
> with proportional control, very weak integral action is sufficient to
> bring to back to SP very slowly.
>
> I read Mr. Peter Nachtway concerns that they did not use his program
> so I check. So I see Mr. Peter Nachtway's program does not model the
> issue at hand.
Why not? Be specific. You can see that my program changes the inflow.
> So I said, no problem it is very easy to make very
> small change so that the program of Mr. Peter Nachtway does indeed
> model the issue at hand. I was very careful not to change the other
> things that he said Mr. Pieter Steenekanp changed. Please look below
> for the program after I made the changes.
>
> Please note Mr. Peter Nachtway, I did not use Mr Pieter Steenekanps
> program. I copied the one in the reference you gave in the thread and
> modified it, using absolutely minimum modifications, just to test the
> response from steady state when the in-flow changes. Please don't get
> mad at me too!
You removed the derivative term. That invalidates the test.
If you read the original thread you will see that is the model of a real
system provided to us by an engineer trying to model his system. I
don't understand why you would complain about the model. It was good
for the engineer on www.plcs.net.
My program changes the in_flow variable 3 times to simulate
disturbances. I should probably add another graph that shows the in
flow levels just to make that clear.
Provide us with another one if you don't like that provided. From what
I see both Pieter and Lu Hing have both miss represent the tuning I use
because they have modified the program.
Mr. Lu Hing, what about the derivative time constant or derivative gain?
Your 'small change' got rid of the derivative time constant. Well?
All the gains must 'work together' to achieve the desired response. You
effectively sabotaged my controller and made it look bad. What is wrong
with you guys? You seem to pick and choose the gains you want to use
and ignore the ones you don't with out any concern as to how the gains
work together. See the other thread on iterative tuning.
Here is a link to where I going to keep news group data.
ftp://ftp.deltacompsys.com/public/NG
There are two .gif files. One showing Pieter's tuning and the other
showing my tuning with the Tc set to 0.1 minutes. Which would you
rather use. Both have an max error of about 0.030 meter. My
tanklevel.sce is in the same directory. It has only been modified to
add Pieter's tuning and a max_error variable was added. If you run my
program you will see my tuning provides a slightly smaller peak but the
average error and wear and tear on the pump is much less.
Which one would you use?
Peter Nachtwey
luhi...@yahoo.com
>
> There are two .gif files. One showing Pieter's tuning and the other
> showing my tuning with the Tc set to 0.1 minutes. Which would you
> rather use. Both have an max error of about 0.030 meter. My
> tanklevel.sce is in the same directory. It has only been modified to
> add Pieter's tuning and a max_error variable was added. If you run my
> program you will see my tuning provides a slightly smaller peak but the
> average error and wear and tear on the pump is much less.
> Which one would you use?
>
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Thank you very much Mr Peter Nachtwey.
a) The reference you gave in the thread definitely had no derivative
action, Maybe you got confused and thought you gave another reference?
Do me a favour and go check the reference again please.
b) You imply I take out the derivative term. I did no such thing. I
took your program and made the changes that I very clearly commented
as my changes.
Yes, thank you very much, but we never doubted that if you include
derivative it can make the control response better. But then you must
consider the response of derivative on the noise, and then you can
come up with even better algorithm like to use feed-forward on the in-
flow (similar to three term boiler drum level control. But those are
other discussions.
This discussion is very clear on comparing P-only to PI- control, The
question was not to find the best control scheme. Do you mind not
changing the subject until we have reached some closure on PI- against
P-only for the specific application as described.
Peter Nachtwey
program since that thread and forgotten that I had done that. We
were talking apples and oranges. All of you were correctly looking
at what I had referenced and I was looking at the updated version. I
should have posted a link to the program I was talking about on my FTP
site.
I APOLOGIZE , I can see how all of you came up with the conclusions
you did and I wasted valuable time.
Please see this site
ftp://ftp.deltacompsys.com/public/NG
The .gif and the updated tanklevel.sce is there. It has the
disturbances and the better PID control.
Peter Nachtwey
pieter steenekamp
> OOPS! MY APOLOGIES TO ALL and to Mr Lu Hing. I must have updated my
No problem Peter, apologies accepted. We all make mistakes sometimes.
I do want to go back on this thread to pick up the main unresolved
point, but first some other points though:
a) First John started it about modelling his tank level control, and
this issue has been sorted out, I think.
b) There was a lot of other messages and ideas, but before going back
to John's difficult level control that has been side-tracked
significantly by Peter's small mistake, maybe first a comment on Fred
Thomasson's two cents. I quote from his posting:
I support this tuning method for level control on tanks that are used
to steady out the flow; this is typical used on surge vessels and are
very applicable in oil refineries where I have done a lot of work. The
objective is to keep the outflow as steady as possible, without
violating the level limits. So you ensure the proportional control
action will "catch" the maximum allowable error, caused by an inflow
disturbance, using the smallest amount of control effort. And then you
calculate the integral action for critical damped response to bring
the level back to setpoint again. So your tuning method starts from,
not a given time response, but a maximum allowable level variation
(ALV).
This concept (albeit in a slight different format), was first
explained to me by a Shell process control engineer, Fatolla Azodi,
more than 15 years ago, so I think it's safe to say that this method
is reasonably well established in industry and it works well.
c) Then there is John's difficult tank level where we were somewhat
side-tracked. Let me quote him again:
> We have one application like this on our plant where the pump often
> trips on low tank level and I have tried, without spectacular success,
> tuning the LC to prevent this. I now realize that my integral control
> action is probably too strong. I will go and try a combination of
> weaker integral and stronger proportional control to prevent low level
> trips. Fortunately, on this application, a sharp drop in feed,
> resulting in a low level (and pump trip), is never followed closely by
> another sharp drop in feed, so it's not required to recover the level
> to setpoint fast after a drop in feed; in fact it's probably good if
> it then stays low. We have one very constant flow going into the tank,
> and another one that changes between low and high flow. The issue is
> simply to prevent a low level trip.
...
> john
I have worked on a number of similar "difficult" level control
applications too.
Although Peter's model coefficients that he used (in the very nice
Scilab level control models, thanks Peter) is very typical of many
tank levels in industry, it does not capture the essence of this
specific problem of John's. In a most tank level control, like
Peter's, you can use relatively very strong control action without
stability problems. Peter's example of his best tuning is a case in
point. It's a good desk top exercise to demonstrate the concept, but
you would not really implement strong control action like this on a
chemical plant.
But let's return to John's difficult level control application: In all
the "difficult" level controls, similar to John's, that I have come
across, the relative magnitudes of the tank capacity and apparent dead
time of the actuator response is such that the control system becomes
unstable and force you to use weaker control settings, with the result
that level deviation on an inflow disturbance is sometimes too large
to prevent level trips.
Let me side-track a bit: now this type of application would be
suitable for Peter's derivative control; there's nothing like
derivative control to allow stronger proportional control action
without the loop going unstable.
But .. I would be very careful in using derivative for level control.
The little waves on the liquid surface that Peter referred to in one
if his postings get amplified by the derivative action, so it's not
always a good idea. I say "not always", if you can not "catch" the
level from tripping, you might want to consider derivative action.
Some DCSs (I know ABB's has), PID algorithm let you filter the
derivative only, making it less risky using derivative of course.
So let's stay with PI only for now (but keeping derivative for plan B
of course). For John's application, it would be valid to say that to
use proportional control only (well, you would have a tiny bit of
integral of course, but for all practical purposes you can say it is
proportional only), is the best fit for this purpose.
Now the question is of course: how do you find the proportional gain.
Well, there is more than one way to skin a cat. There are people, like
Peter, who seem to have a very strong dislike of iterative tuning, so
you can model your process and use desk-top tools, nothing wrong with
that at all.
Or you can simply use on-line iterative tuning.
If P-only does not work, then try derivative, you would still use very
little Integral, so it would almost become a PD-controller, or feed-
forward on inflow.
It's up to you and your tank level now my friend, good luck.
Please keep us updated on your progress on this one.
Regards
Pieter Steenekamp
Peter Nachtwey
>> On Apr 9, 8:34 pm, "Peter Nachtwey" <p...@deltacompsys.com> wrote:
>> OOPS! MY APOLOGIES TO ALL and to Mr Lu Hing. I must have updated my
>
> No problem Peter, apologies accepted. We all make mistakes sometimes.
files so we are all talking about the same thing. That way this will
not happen gain.
>
> I do want to go back on this thread to pick up the main unresolved
> point, but first some other points though:
>
> a) First John started it about modelling his tank level control, and
> this issue has been sorted out, I think.
>
> b) There was a lot of other messages and ideas, but before going back
> to John's difficult level control that has been side-tracked
> significantly by Peter's small mistake, maybe first a comment on Fred
> Thomasson's two cents. I quote from his posting:
>> Let me add my two cents to this discussion. Assume that the process can be
>> modeled as Kp/s and we control the flow out with a linearized flow control
>> valve (just to make the problem simple) using a standard ISA PID
>> controller. The tuning will be for disturbance rejection - where the
>> disturbance is a change in the inlet flow. Let us look at the root locus
>> sketch as the proportional gain increases from zero to infinity for a fixed
>> integral gain. There will be two poles at the origin for Kc = 0. As Kc is
>> increased, the closed loop poles move into the left hand plane and the
>> sketch forms a circle. The two poles converge on the negative real axis when
>> Kc = Ki/15Kp. Ki is in repeats per minute and Kc is the proportional gain
>> and Td = 0. These poles will be at -KpKc/2. If Kc is increased further, the
>> two poles travel on the negative real axis (one toward the origin and the
>> other toward - infinity. For Kc less than Ki/15Kp, the response will be
>> under damped. It is critically damped for Kc = Ki/15Kp. For Kc greater than
>> Ki/15Kp, the response will be overdamped. If you want it be critically
>> damped, you would have to adjust Kc every time you adjusted Ki.
Yes, over damped is good too if you don't want over shoot. I was
mainly objecting to P only control with gains at -9200.
>> However if
>> the Kc is large so that you are overdamped, you can tweak Ki without
>> adjusting Kc (as long as the poles stay on the real axis) and this is what I
>> often do.
I will check that out. I don't normally deal with models like K/s so I
don't have a lot of pre made examples I can modify. That is why I
haven't responded. It takes time.
>>
>> The concept of Allowable Level Variation (ALV) simplifies tuning of the
>> level controller. First you must do an open loop bump test to get an
>> estimate of Kp.
In this simple model the Kp is the product of the Kt and Kp in the
Scilab model. Why can't you calculate this?
>> The ALV is the maximum variation from setpoint that you will
>> allow under regulatory operation. It is expressed in %. Use the largest ALV
>> possible so the tank can absorb the disturbace. The tuning equations are:
>> Kc = 100/ALV, Ki = 15KcKp (for critical damping). Then decrease the Ki
>> some to make the response more robust. During my 30 year career in the Pulp
>> & Paper Industy, I used this method on hundreds of tank level controllers.
>
I will check this out.
> I support this tuning method for level control on tanks that are used
> to steady out the flow; this is typical used on surge vessels and are
> very applicable in oil refineries where I have done a lot of work. The
> objective is to keep the outflow as steady as possible, without
> violating the level limits. So you ensure the proportional control
> action will "catch" the maximum allowable error, caused by an inflow
> disturbance, using the smallest amount of control effort. And then you
> calculate the integral action for critical damped response to bring
> the level back to setpoint again. So your tuning method starts from,
> not a given time response, but a maximum allowable level variation
> (ALV).
>
If you have the model you can calculate the error. In the original
problem on www.plcs.net the mellow tuning was enough.
> This concept (albeit in a slight different format), was first
> explained to me by a Shell process control engineer, Fatolla Azodi,
> more than 15 years ago, so I think it's safe to say that this method
> is reasonably well established in industry and it works well.
>
> c) Then there is John's difficult tank level where we were somewhat
> side-tracked. Let me quote him again:
>> We have one application like this on our plant where the pump often
>> trips on low tank level and I have tried, without spectacular success,
>> tuning the LC to prevent this.
It is hard to know exactly why this happens but I suspect that it is
improper tuning coupled with a poor implementation of the integrator.
In my tanklevel.sce the worst case occurs if the last in_flow is set to
0. In this case the integrator must wind down and during this time the
level keeps going down.
>> I now realize that my integral control
>> action is probably too strong. I will go and try a combination of
>> weaker integral and stronger proportional control to prevent low level
>> trips.
The stronger integrator gain means that it should unwind faster too.
If you were using a Rockwell PLC I was tell you to get a trend.. These
are very informative. Plot the SP PV and CO.
>> Fortunately, on this application, a sharp drop in feed,
>> resulting in a low level (and pump trip), is never followed closely by
>> another sharp drop in feed, so it's not required to recover the level
>> to setpoint fast after a drop in feed; in fact it's probably good if
>> it then stays low.
Doesn't the pump goo off while the level is low?
>> We have one very constant flow going into the tank,
>> and another one that changes between low and high flow. The issue is
>> simply to prevent a low level trip.
> ...
>> john
So can you graph this event?
>
> I have worked on a number of similar "difficult" level control
> applications too.
> Although Peter's model coefficients that he used (in the very nice
> Scilab level control models, thanks Peter) is very typical of many
> tank levels in industry, it does not capture the essence of this
> specific problem of John's.
I hope not. If you notice the pump will stop pretty quickly when the
in_flow drops.
> In a most tank level control, like
> Peter's, you can use relatively very strong control action without
> stability problems.
> Peter's example of his best tuning is a case in
> point. It's a good desk top exercise to demonstrate the concept, but
> you would not really implement strong control action like this on a
> chemical plant.
I don't think original control with Tc = .25 is very strong. If the Tc
is changed to 3*Tp then the derivative gain isn't required.
> But let's return to John's difficult level control application: In all
> the "difficult" level controls, similar to John's, that I have come
> across, the relative magnitudes of the tank capacity and apparent dead
> time of the actuator response is such that the control system becomes
> unstable and force you to use weaker control settings, with the result
> that level deviation on an inflow disturbance is sometimes too large
> to prevent level trips.
If you are using a control valve to control the out flow then that is a
WHOLE different problem. The valve probably is non-linear and the flow
through it isn't linear as it changes as a function of the pressure
drop. I don't see where there would be a dead time in a simpler
application like tanklevel.sce example.
>
> Let me side-track a bit: now this type of application would be
> suitable for Peter's derivative control; there's nothing like
> derivative control to allow stronger proportional control action
> without the loop going unstable.
> But .. I would be very careful in using derivative for level control.
> The little waves on the liquid surface that Peter referred to in one
> if his postings get amplified by the derivative action, so it's not
> always a good idea.
I was wondering when someone would call me on that. There are cures for
that ranging from a simple low pass filter on up. Since PLCs can do
anymore than the low pass filter technique I think I will limit the
tricks to that, for now.
I say "not always", if you can not "catch" the
> level from tripping, you might want to consider derivative action.
SIGreg's application on plcs.net requires a derivative gain most of the
time because it has two poles. One for the tank integrator and one for
the pump time constant. Each system must be evaluated on a case by case
basis. A simple Kp/s plant shouldn't require an derivative gain.
> Some DCSs (I know ABB's has), PID algorithm let you filter the
> derivative only, making it less risky using derivative of course.
Yes, it is a standard feature.
>
> So let's stay with PI only for now (but keeping derivative for plan B
> of course). For John's application, it would be valid to say that to
> use proportional control only (well, you would have a tiny bit of
> integral of course, but for all practical purposes you can say it is
> proportional only), is the best fit for this purpose.
I don't know and am reluctant to say because we really don't know the
kind of information about John's plant. SIGreg on the plcs.net forum
supplied us with the required information.
I think John is using a poorly implemented integrator which makes the
situation worse.
If John's system works like Fred's model ( K/s ) you are probably right
P gain will do the trick. The problem with using P gain only is shown
by your example. The output term from the proportional gain gets too
high. The integrator filters things out a bit. One could do better by
just having an in-flow meter using feed forward with just a P gain.
> Now the question is of course: how do you find the proportional gain.
Look at the interative tuning thread. I used the Ackermann equations to
compute the gains. Look at Pandiani's .pdf on www.plcs.net. He
computes the gains although I think he made a mistake in calculating the
derivative gain. I need to check that.
> Well, there is more than one way to skin a cat. There are people, like
> Peter, who seem to have a very strong dislike of iterative tuning, so
> you can model your process and use desk-top tools, nothing wrong with
> that at all.
The problem with iterative tuning is that people change the gains
without knowing what is happening to the poles. Look at Fred's
response. I need to verify what he said but it looks like he has a good
approach and is very mindful of where the poles are.
>
> Or you can simply use on-line iterative tuning.
>
> If P-only does not work, then try derivative, you would still use very
> little Integral, so it would almost become a PD-controller, or feed-
> forward on inflow.
>
Tuning shouldn't be a hit or miss process.
Peter Nachtwey
Peter Nachtwey
> Let me add my two cents to this discussion. Assume that the process can be
> modeled as Kp/s and we control the flow out with a linearized flow control
> valve (just to make the problem simple) using a standard ISA PID
> controller. The tuning will be for disturbance rejection - where the
> disturbance is a change in the inlet flow. Let us look at the root locus
> sketch as the proportional gain increases from zero to infinity for a fixed
> integral gain. There will be two poles at the origin for Kc = 0. As Kc is
> increased, the closed loop poles move into the left hand plane and the
> sketch forms a circle. The two poles converge on the negative real axis when
> Kc = Ki/15Kp.
???? Where does this come from? Look at the T1 pi.pdf at the bottom.
The result will be critically damped when the square root term is 0.
This happens when Ti = 4/(Kc*Kp) or Kc=4/(Ti*Kp) and the poles are at
Kp*Kc/2. Remember I define Kp as negative because it reduces the level.
Ki should be Kc/Ti. There must be some confusion here.
> Ki is in repeats per minute and Kc is the proportional gain
> and Td = 0. These poles will be at -KpKc/2.
Yes.
If Kc is increased further, the
> two poles travel on the negative real axis (one toward the origin and the
> other toward - infinity.
Yes and no. See the equation for Kc. Increasing Kc could just move
both poles to the left. It depends on what Ti is doing too.
> For Kc less than Ki/15Kp, the response will be
> under damped. It is critically damped for Kc = Ki/15Kp. For Kc greater than
> Ki/15Kp, the response will be overdamped.
I don't agree with the Ki/15Kp but if you substitute my numbers I agree.
If you want it be critically
> damped, you would have to adjust Kc every time you adjusted Ki.
YES, EXACTLY. That is what I do using the formulas for the gains as a
function of the closed loop time constants.
> However if
> the Kc is large so that you are overdamped, you can tweak Ki without
> adjusting Kc (as long as the poles stay on the real axis) and this is what I
> often do.
Yes, but making the integrator time constant too long means it takes a
long time for the controller to eliminate the error.
>
> The concept of Allowable Level Variation (ALV) simplifies tuning of the
> level controller. First you must do an open loop bump test to get an
> estimate of Kp. The ALV is the maximum variation from setpoint that you will
> allow under regulatory operation. It is expressed in %. Use the largest ALV
> possible so the tank can absorb the disturbace. The tuning equations are:
> Kc = 100/ALV,
That seems too work. I picked an ALV of .020 meters which yields a gain
of -5000. I adjusted the time constants until Kc = 5000. You can
see the error is about half that ( 0.010m )when the integrator is used
ftp://ftp.deltacompsys.com/public/NG/Mathcad%20-%20t1%20pi.pdf
when the integrator is not used the error is a little larger 0.017m
ftp://ftp.deltacompsys.com/public/NG/Mathcad%20-%20t1%20p.pdf
> Ki = 15KcKp (for critical damping). Then decrease the Ki
> some to make the response more robust. During my 30 year career in the Pulp
> & Paper Industy, I used this method on hundreds of tank level controllers.
So far we agree except for the Ki=15KcKp. Where does this come from? I
show how I derive my Ti = 4/(Kc*Kp) at the bottom of the .pdf.
Peter Nachtwey
Fred Thomasson
> So far we agree except for the Ki=15KcKp. Where does this come from? I
> show how I derive my Ti = 4/(Kc*Kp) at the bottom of the .pdf.
The difference is in the definition of Kp. My value comes from making a step
change in the controller output and record the change in level (level needs
to be steady first) over a given time period(in seconds).
Kp = delta_level / [(delta_CO)(delta_time)]
If I had used the time period in minutes, my Kp would have been smaller by a
factor of 60 and Ki = (Kc*Kp)/4 or Ti = 4/(Kc*Kp). Hence we have the same
value.
One last comment. When I tuned level controllers for tanks, I rarely used Kc
above 20. But I usually used ALVof 20% to 50%. There may be some instances
where you can only tolerate a very small deviation from the setpoint but in
most industial applications the purpose of the tank is to take the surge in
process demand that defines the disturbance. Using a large Kc passes the
disturbance and create quality problems in the product.
> Peter Nachtwey
Peter Nachtwey
> "Peter Nachtwey" <pnac...@comcast.net> wrote in message
> news:Av-dnRnj7IEU8oHb...@comcast.com...
>> So far we agree except for the Ki=15KcKp. Where does this come from? I
>> show how I derive my Ti = 4/(Kc*Kp) at the bottom of the .pdf.
>
> The difference is in the definition of Kp. My value comes from making a step
> change in the controller output and record the change in level (level needs
> to be steady first) over a given time period(in seconds).
>
> Kp = delta_level / [(delta_CO)(delta_time)]
>
> If I had used the time period in minutes, my Kp would have been smaller by a
> factor of 60 and Ki = (Kc*Kp)/4 or Ti = 4/(Kc*Kp). Hence we have the same
> value.
>
to it.
Peter Nachtwey
Fred Thomasson
a slope for this type. You can use any delta time you want. The slope will
be constant. If you want to to know more, look at the book titled: "Process
Control Fundamentals for the Pulp & Paper Industry" published by TAPPI. I
wrote Chapter 7: Controller Tuning Methods. This method of tuning level
control is discussed thoroughly including simulation results.
> Peter Nachtwey
Peter Nachtwey
wrote:
> "Peter Nachtwey" <pnacht...@comcast.net> wrote in message
>
> news:Aamdnc3j3dpSZYHb...@comcast.com...
>
> > Fred Thomasson wrote:
> > >news:Av-dnRnj7IEU8oHb...@comcast.com...
> > >> So far we agree except for the Ki=15KcKp. Where does this come from? I
> > >> show how I derive my Ti = 4/(Kc*Kp) at the bottom of the .pdf.
>
> > > The difference is in the definition of Kp. My value comes from making a
> step
> > > change in the controller output and record the change in level (level
> needs
> > > to be steady first) over a given time period(in seconds).
>
> > > Kp = delta_level / [(delta_CO)(delta_time)]
>
> > > If I had used the time period in minutes, my Kp would have been smaller
> by a
> > > factor of 60 and Ki = (Kc*Kp)/4 or Ti = 4/(Kc*Kp). Hence we have the
> same
> > > value.
>
> > One doesn't normally think that a proportional term has a time element
> > to it.
>
> You do if the plant model has an integrator in the transfer function
motion control gains here Kp is the proportional gain, not a plant
gain, and Ki is the integrator gain not a time constant.
It would have been clearer if you said you were dealing in seconds,
that would have explained the 15, and used Ti instead of Ki like we
were.
OK, we are on the same page now.
> > Peter Nachtwey
pieter steenekamp
using Scilab. What I have come up with is a draft Scilab program that
will find the optimum PID settings to minimise a cost function with
configurable weighting coefficients so that you can specify the
relative importance of:
a) Max level error on inflow disturbance
b) Sum of error
c) Small valve movements
all on an inflow disturbance. (I should really add setpoint responses
too)
Please note that I haven't properly tested it, there are most probably
bugs in.
The using of integral gain instead if time constant is because you get
better optimiser performance like that.
To use it, copy from below the "level Optimse.sce" and "level.sci"
into two separate files and change the Scilab directory to there and
then "exec" the "level Optimse.sce" from the menu in Scilab. It will
then prompt you for values and return the optimised tuning
coefficients.
Regards
Pieter Steenekamp
*************************************************
* Fiirst the "level Optimise.sce" program *
*************************************************
// This program finds the PID settings to optimise the response
// on a level controller with significant dead time in the actuator
// it uses the SciLab functions "NDcost" and "optim"
// to do the optimisation
clear;
plotON=0;
exec('level.sci')
Thold=evstr(x_dialog('Tank holdup in seconds ?','50'));
Tpdt =evstr(x_dialog('actuator dead time ?','10'));
maxErrorWeight=evstr(x_dialog('maxErrorWeight ?','10'));
sumAbsErrorWeight=evstr(x_dialog('sumAbsErrorWeight ?','1'));
sumDeltaCoSquaredWeight=evstr(x_dialog('sumDeltaCoSquaredWeight ?','1'));
// initial tuning values:
x(1)= -1; // for proportional gain
x(2)= 0; // for integral gain
x(3)= 0; // for derivative gain
printf(' Maybe now is a good time to have coffee, because this optim-
function is sometimes slow \n');
[f,xopt,gopt]=optim(list(NDcost,level),x)
Kc=xopt(1)
Ki=xopt(2)
Kd=xopt(3)
plotON=1;
g=level(xopt);
*************************************************
* Now for the "level.sci" function *
*************************************************
function f = level(x)
// The basic intent of this function is to be called by "optim" from
outside of this to find the optimum x
// This fuction calculates the optimisation cost function as a
function of Kc, Ki & Td, supplied as vector x
// Thold, Tpdt,
plotON,maxErrorWeight,sumAbsErrorWeight,sumDeltaCoSquaredWeight must
be global variables, declared outside
// The approach on units taken is to work in percent of range and not
in engineering units
// Optimisation variables:
max_error = 0;
sumAbsError=0;
sumDeltaCoSquared=0; // To penalise fast cahnges in controller
output
// Read tuning variables x
Kc=x(1);
Ki=x(2);
Kd=x(3);
T=1; // simulation update period in seconds
Kp = -T/Thold; // Tank gain - take it as negative because
control on outflow
PV(1)=0; // fluid level in meters
CO(1)=0; // Control output in percent of full
output
ui(1) = 0; // integrator contribution to CO
up(1) = 0; // proportional contribution to CO
ud(1) = 0; // derivative contribution to CO
flow_out(1)=0; // flow pumped out in cubic meters per
minute
flow_in = 10;
new_error=0; // error in level meter
old_error=0; // error in level meter
max_time = 200; // length of simulation in seconds
N=round(max_time/T); // convert to sample periods
// intialise dead time buffer
if Tpdt>0 then
for j = 1:Tpdt,
opBuffer(j) = 0;
end
end
for n=1:N;
t(n) = n*T; // Compute time indexes. This is needed
for time index
SP(n)=0;
// calculate the new flow, as a function of controller output and dead
time:
if Tpdt > 0 then
flow_out(n+1) = opBuffer(Tpdt) ; //pure dead time is applied to
out floe
else
flow_out(n+1) = CO(n);
end
// update dead time buffer
if Tpdt>1 then
for j = 0:Tpdt-2,
j1 = Tpdt - j;
opBuffer(j1) = opBuffer(j1-1);
end
end
opBuffer(1) = CO(n);
// Integrate the difference between the flow in and flow out.
PV(n+1) = PV(n) + Kp*(flow_in - flow_out(n))*T;
if PV(n+1) > 100 then
PV(n+1)=100
elseif PV(n+1)<-100 then
PV(n+1) = -100
end
// Calculate the control output using a simple PID
old_error = new_error(n); // shift the error history. this is
necessary for the differentiator
new_error(n+1) = SP(n)-PV(n); // calculate error
if abs(new_error(n+1)) > max_error then
max_error = abs(new_error(n+1));
end
sumAbsError = sumAbsError + abs(new_error(n+1));
up(n+1) = Kc*new_error(n+1); // calculate the proportional control
output percent
ui(n+1) = ui(n) + Ki*new_error(n+1); // calculate the integrator
control output percent
if ui(n+1) > 100 then
ui(n+1)=100
elseif ui(n+1)<-100 then
ui(n+1) = -100
end
ud(n+1) = Kd*(new_error(n+1)-old_error); // calculate the derivative
control output percent
CO(n+1) = ui(n+1) + up(n+1) + ud(n+1); // The control output
is the sum of the integrator and proportional terms
sumDeltaCoSquared = sumDeltaCoSquared + (CO(n+1) - CO(n))*(CO(n+1) -
CO(n));
if CO(n+1) > 100 then
CO(n+1)=100
elseif CO(n+1)<-100 then
CO(n+1) = -100
end
end
if plotON > 0.5 then
subplot(2,1,1); // Level on top
plot(PV);
xtitle('Level');
legend("level");
subplot(2,1,2); // Control output at bottom
plot(CO);
xtitle('Control Output');
legend("CO");
end
f = maxErrorWeight*max_error + sumAbsErrorWeight*sumAbsError +
sumDeltaCoSquaredWeight*sumDeltaCoSquared;
endfunction
Peter Nachtwey
actually more related to the iterative tuning thread than the level
control thread.
I have used lqrsolve but not optim. I will have to see if there is a
difference. From what I have seen evaluation function for qrsolve
returns a vector of errors that lqrsolve uses to calculate the gradient
of the error function as a function of the change in gains. It looks
like optim only requires the evaluation function only return an error
value. I doubt the optim can be as smart about how it changes the gains
as the lqrsolve. This may result in more iterations because the gradient
may not be calculated. I think this point is VERY important because it
is critical that the number of iterations be minimized.
Do you mind if I put this on my FTP site in the NG directory and update
it as you update your files?
I can see you added a dead time to the model. That will make things
interesting but very general.
Peter Nachtwey
pieter steenekamp
> difference. From what I have seen evaluation function for qrsolve
> returns a vector of errors that lqrsolve uses to calculate the gradient
> of the error function as a function of the change in gains. It looks
> like optim only requires the evaluation function only return an error
> value. I doubt the optim can be as smart about how it changes the gains
> as the lqrsolve. This may result in more iterations because the gradient
> may not be calculated. I think this point is VERY important because it
> is critical that the number of iterations be minimized.
I concur. Another reason why the choice of solver is important is to
ensure you do find the global optimum. I haven't tried lqrsolve, but
found Matlab's Optimisation and Genetic Algorithm Toolboxes to be
significantly better than Scilab's optim; both in terms of speed and
ability to find "difficult" global optimums.
> Do you mind if I put this on my FTP site in the NG directory and update
> it as you update your files?
I don't mind.
Pieter Steenekamp