You do if the plant model has an integrator in the transfer function. Kp is
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.
On Apr 11, 8:33 am, "Fred Thomasson" <fthomasson at comcast.net>
Yes, I see. When you used Ki and Kp together I think in terms of
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
OK, we are on the same page now.
I have been playing around with level control tuning optimisation
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
Please note that I haven't properly tested it, there are most probably
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
* 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
Thold=evstr(x_dialog('Tank holdup in seconds ?','50'));
Tpdt =evstr(x_dialog('actuator dead time ?','10'));
// 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');
* 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,
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;
sumDeltaCoSquared=0; // To penalise fast cahnges in controller
// Read tuning variables x
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
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
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;
t(n) = n*T; // Compute time indexes. This is needed
for time index
// calculate the new flow, as a function of controller output and dead
if Tpdt > 0 then
flow_out(n+1) = opBuffer(Tpdt) ; //pure dead time is applied to
flow_out(n+1) = CO(n);
// update dead time buffer
if Tpdt>1 then
for j = 0:Tpdt-2,
j1 = Tpdt - j;
opBuffer(j1) = opBuffer(j1-1);
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
elseif PV(n+1)<-100 then
PV(n+1) = -100
// 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));
sumAbsError = sumAbsError + abs(new_error(n+1));
up(n+1) = Kc*new_error(n+1); // calculate the proportional control
ui(n+1) = ui(n) + Ki*new_error(n+1); // calculate the integrator
control output percent
if ui(n+1) > 100 then
elseif ui(n+1)<-100 then
ui(n+1) = -100
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) -
if CO(n+1) > 100 then
elseif CO(n+1)<-100 then
CO(n+1) = -100
if plotON > 0.5 then
subplot(2,1,1); // Level on top
subplot(2,1,2); // Control output at bottom
f = maxErrorWeight*max_error + sumAbsErrorWeight*sumAbsError +
This is very good. I would have started a new thread because this is
actually more related to the iterative tuning thread than the level
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.
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.
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
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
// Mr. Peter Nachtway's program with very small modifications by Mr.
// 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
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 ; // 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
// equation Tp*flow_out_dot+flow_outy=Kp*CO(n). Note flow_out is
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);
err(n) = SP(n) - PV(n); // calculate error
up = Kc*err(n); // calculate the proportional control output
ui = ui + (Kc*T/Ti)*err(n); // calculate the integrator control
if ui > (100-up) then // limit the integrator contribution to the
ui = 100-up;
elseif ui < 0-up then
ui = 0-up;
CO(n+1) = ui + up; // the control output is the sum of the
integrator and proportional terms
PV($)=; // LIMIT TO 1200 ITEMS
// 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
clf(); // CLEAR OR RESET THE CURRENT GRAPHICS FIGURE
subplot(2,1,1); // PLOT TEMPERATURES ON THE TOP PLOT
xtitle('Tank Level Control Simulation','Time In Minutes','Tank
subplot(2,1,2); // PLOT CONTROL OUTPUT ON THE BOTTOM PLOT
// PLOT THE CONTROL OUTPUT TERMS
xtitle('Tank Level Control Simulation','Time In Minutes','Control
maximumLevel // added by Mr Lu Hing to display tha maximum deviation
That isn't very much.
In really difficult cases, when the
Why not? Be specific. You can see that my program changes the inflow.
You removed the derivative term. That invalidates the test.
I am already shit scared to write this posting, but I
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.
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?
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
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.
Thank you very much
OOPS! MY APOLOGIES TO ALL and to Mr Lu Hing. I must have updated my
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
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
The .gif and the updated tanklevel.sce is there. It has the
disturbances and the better PID control.
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
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:
I have worked on a number of similar "difficult" level control
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
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.
I have a NG ( news group ) directory on my FTP site where I will put
files so we are all talking about the same thing. That way this will
not happen gain.
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.
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.
In this simple model the Kp is the product of the Kt and Kp in the
Scilab model. Why can't you calculate this?
I will check this out.
If you have the model you can calculate the error. In the original
problem on www.plcs.net the mellow tuning was enough.
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.
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.
Doesn't the pump goo off while the level is low?
So can you graph this event?
I hope not. If you notice the pump will stop pretty quickly when the
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.
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.
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
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.
Yes, it is a standard feature.
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
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.
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.
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.
Tuning shouldn't be a hit or miss process.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.