Control loop for process with very high transportation lag


Thread Starter

Mauro Arecco

I need some information about control loop for process with very high transportation lag:
* CASE 1: the flow control element and the flow measure element are "separate" by a transportation lag of about 600 seconds.
* CASE 2: the flow control element and the current measure element (the current is quite proportional with flow rate but the ratio is
unknown) are "separate" by a transportation lag of about 600
The PID loop approach is not good, is it better a different control approach?


Best regards.

Mauro Arecco
SMS Demag S.p.A.
Italimpianti Division
ELC Electrical and Controls Dept.
Via di Francia 1 - 16149 Genova - Italy
e-mail: [email protected] <mailto:[email protected]>

phone: ++39 010 640 9376
fax: ++39 010 640 9471


Mehmet Zeki GURGUC

Hi ;

I think (not so sure)a lead compensator may work for your situation as it will help to diminish the effect of delay (By increasing the phase
margin and phase crossover frequency in the Bode plot but it will also make the system volatile to high frequency components(disturbance etc) as lead compensator will act as a high pass filter).

Mehmet Zeki GURGUC

Yeditepe University --Turkey
Systems & Control Engineering
Senior Student

Rogelio Diaz

Check out "":http:/ , a control system add-on specially created for high transport lag processes which are normally difficult to control with PID.

Johan Bengtsson

<P>First: are you sure PID is out of the question, by tuning it slow it would work quite nice - the control will of course be slow too so I definitely don't say you are wrong, it really depends on the situation.</P>

<P>Second what do you do if PID really is too slow? Well you need a dead time compensated controller, the usual one is called Otto-Smidth and is really a PID with a process model with and without the dead time.</P>

PID ---*------------------------------->process
| |
process model |PV
witout dead time |
| |
*------------dead-time |
| | |
|expected |expected |
|PV |PV |
|without | |
|lag | |
| | |


<P>A-B+C is then feed back as PV to the PID.
After an action by the controller the process model feeds back an expected PV as it would be without the lag. The PID sees this and actually controls the output from the process model.</P>

<P>The value passed the process model delayed with the lag is then compared to the actual value from the real process, any difference is directly affecting the feedback so proper action can be taken.</P>

<P>If the process model exactly matches the real process (not likely) there will never be any difference between B and C above. But if the process model is close enough to the real model the differences will be quite small.</P>

<P>/Johan Bengtsson

<P>Do you need education in the area of automation?<BR>
P&L, Innovation in training<BR>
Box 252, S-281 23 H{ssleholm SWEDEN<BR>
Tel: +46 451 49 460, Fax: +46 451 89 833<BR>
E-mail: [email protected]<BR>

Peter Wurmsdobler

Search the net or libraries for "Smith predictor",
or set the closed loop dominant poles to be very

This is a case I use in seminars, and I've used several times in my column in "Flow Control" magazine.

There is no "Fuzzy Logic" cure for excessively long physical loop lag.

Rule Number One: do not introduce excessively long physical loop lag into an automatic control loop.

Rule Number Two: if you must deal with an excessively long physical loop lag, see Rule Number One.

What will happen is that the loop will be left in manual. It will sorta work all the time, except when it doesn't.

But it will neither oscillate wildly out of control or be so damped that it never responds anyway.

Walt Boyes

[email protected]
21118 SE 278th Place
Maple Valley, WA 98038
253-709-5046 cell
425-432-8262 home office

Bob Peterson

I don't necessarily agree with your assessment. It takes a lot of time, patience, observation, and sometimes some cleverness, but I have not run across a problem like this that is unsolvable. Often its as simple as making the loop stay in manual with a fixed output for some period of time before allowing it to go into manual. Sometimes you can watch how the operators control it manually and attempt to mimic that in your program.

The oddest case of this I ever had was a chiller. It took me three days of observation and some of the strangest looking tuning constants I had ever used, plus a lot of chatting with the plant people before I came up with a workable solution. This thing had a natural oscillation of about 30 minutes. Try tuning that. I actually would put it into manual, make a step change and it would take 5-10 minutes before any change in the PV was noticed. It helped that I had the capability to graph the output and PV of my loops, otherwise I would never have believed what was happening.

Sometimes you can make a rough process model in your software and estimate what your output should be and allow a feedback loop (not always a PID loop by the way) to correct maybe 20% of the output, rather then the full output. I have had some success with this approach on occassion.

Bob Peterson
Yes, you are right...if you want, have funds for, or have the time for, doing all the things you have mentioned. It depends, though on whether the measurement and the control function are critical or not. Doing what you did for the chiller must have taken several hours. Unless you are overhead, and not more profitably assigned doing this than something won't get done in my experience.

Walt Boyes

---------SPITZER AND BOYES, LLC-------------
"Consulting from the engineer
to the distribution channel"

[email protected]
21118 SE 278th Place
Maple Valley, WA 98038
253-709-5046 cell 425-432-8262 home office
Actually, there is a trick to tuning PID for a transport lag. First, turn off Derivative. Second measure the transport lag time and set your Integral term to one tenth of the lag time (Wierd, huh?) Next adjust the proportional band until it becomes stable but be aware that your Prop Band will be extremely large.

A PID controller tuned with classical settings gives a tight Prop Band and Integral which, with a dominant transport pag results in a near unity loop gain. This iterates any perturbation indefinitively, called a comb filter. The idea is to kill this iteration and hence the extremely wide Prop Band. To compensate you crank in the Integral to increase the recovery response.

I've used it before on a tubing extrusion process for diameter control which is almost purely transport lag. It ain't pretty but it works.

From my experience with chiller control, it is really hard to control a system with long lag time. Actually it is a bad control system if your measurement has a long lag. What I did was to put my sensor as close to the controlled unit as
possible. Smith predictor is a choice, but you need to know the dynamics of the controlled system before hand and it is impossible under most of the circumstances.

There are so many comments on this problem !
I just want to clarify whether you really have a large dead time in the process control loop.
It is large if it is large in comparison with the dominating time constant of the process that you control. If your process time constant is 10 hours your dead time of 1 hour is not large at all and you can apply a PID controller without any problems. If the process time constant is, for example, 0.5 hours it is a large dead time indeed and such means as Smith predictor can be of some help.
Dr. I. Boiko ([email protected])

paul salessy

You may have a look to our site "": describing a tool Graphidor that can help you to determine very quickly the optimised P, I parameters to tune with a robustness approach your controller. I you want some help or more information, don't hesitate to contact us.

Johan Bengtsson

Or try lambdatuning, it works quite nicely in this case as long as you don't demand too fast control.

1. Step response, measure lag (L), time constant (T) and process gain (Kp) 2. Select lambda, usually lambda=>2*L when L>T 3. integrator time, Ti=T controller gain Kc=Ti/(Kp*(lambda+L))

The parameters you get below are not that weird if you start comparing the methods.....

/Johan Bengtsson

Do you need education in the area of automation?
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Igor Boiko is correct. You need to compare the dead time with the dominant process time constant.

Can you relocate the sensor ?

There are lots of deadtime compensation techniques out in the market. I have used an ECA 600 controller by Alfa Laval (Now manufactured by
ABB) which is designed for process with large dead time in comparison to the time constant. It is an advanced controller with features such
as feed-forward and gain scheduling.

Do some step responses on the process (if possible)and estimate a first order plus deadtime model. If you have some simulation software such
as Simulink you will be able to opimise your PID settings in a simulation environment before trying them on the process

If the deadtime cannot be avoided or shortened, then the best approach is using a model based controller (MBC).

It avoids the problems stemming from the ramping of the output by the I-term of the PID during the deadtime and can deliver much better
performance and stability. Several examples are given on our Web site - see the 'Technology' pages.

We have a small and easy to use yet very powerful MBC controller called AMC, which is an ideal solution where the standard PID has reached
it limits.

Hans H. Eder
ACT, Brussels office
Madeliefjeslaan 13, B 3080 Tervuren
[email protected] and [email protected]
I suspect you mean "dead time", not "lag" - or at least a combination of dead time and lag, where the dead time is dominant (dead time > to >> lag time). If this is so, any simple model-predictive controller (e.g. Smith Predictor)
should work fine. It is easy to create this kind of scheme using the function blocks (dead time, lead/lag and basic arithmetic) available in most digital controllers. Shinskey's of Liptak's books should have an example of a Smith
Predictor you could use as a basis. Alternatively, use the web.
Alternatively, yet again... move the sensor point!

Neil Brown