PI controller + antiwindup + time delay + noise

I've been seeking help regarding this issue for some time now, I'll try to explain it as best as I could:
I am simulating a system of ODEs using MATLAB, then as some variables
may be controlled it is required to incorporate a PI controller into the main system. Thus a new state variable is added to represent the integral part of the error related to the difference between the set point & measurement of the controlled variable, and a new ODE to respresent the derivative of this error.
so say (ipart) is a new state variable e= reference - So; % error dipart = K/Ti*e; % the additional ODE where K, Ti are the gain & integral time constant of the controller
outputtemp=K*e + ipart; % the value of the controlled variable prior to limitation
if outputtemp <0 outputlim=0; end
if outputtemp > max outputlim =max; end
if 0<=outputtemp<=max outputlim=output; end
then the controlled variable (outputlim) is inserted in its right position within the ODEs.
Now this should represent an ideal PI controller, what if the PI controller experiences time delay & noise, also how could the code be modified to compensate for integral windup.
Please incase the original representation of the ideal PI controller is missing something kindly clarify the missing point as well.
I've no control experience & I've been looking for this information for some time now, so incase someone has an idea of some useful URLs please point them out to me.
I've been trying Google & other search engines & I've found endless information but usually it is too complicated for me to follow & no simple code is provided to help.
I just need simple explaination with a MATLAB code of the PI controller if possible.
Thank you in advance for your assistance.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
One way to do windup protection is to add a term that forces the integral to track the limit. You can do this logic or pure algebra as shown below.
On 3 Sep 2003 01:13:46 -0700, snipped-for-privacy@yalla.com (lucy borrelli) wrote:

dipart = K/Ti*e + K2*UE; %UE is the limit Error %K2 is a limit tracking gain to be selected

UE = 0-outputtemp;

UE = max - outputtemp;

UE = 0;

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Lucy,
A modern controller does not "experience time delay & noise". The input signals often contain noise. The best way to simulate that is to add noise to the feedback signal. This is a property of the measurement, not the controller.
Time delay occurs between the output to the process and the measurement of the process. It is a property of the process. For example, a valve dumps onto a conveyer. Ten seconds later the conveyor passes over a weigh bridge. By-the-way, avoid the term 'time delay'. It has too many meanings. I'm assuming you are referring to deadtime in the process. If you are referring to the phenomenon of the process having a first, or higher, order lag, this is process lag, not deadtime but it may also be called time delay.
Standard process control terminology is:
deviation = process variable - setpoint (Note the sign change)
There are numerous ways to counter reset windup. Assuming that the only time this is relevant is when your output hits 0% or 100%, it is simple to implement reset windup. Simply stop integrating when that happens. That is, whenever you execute the logic that sets the output to the high or low limit simply use 0 instead of the deviation in your integral term.
You are using the 'ideal' form of the equation. Everybody uses a different form and they all consider theirs to be 'ideal'. I call the form you are using the 'academic' form because it is one they always use in schools. No one in industry uses it.
If you like, send me an e-mail at snipped-for-privacy@driedger.ca and I can send you a copy of a detailed presentation of a real industrial controller that has been used many tens of thousand of times in the most widely used controller in the world.
Walter.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Lucy,
Pure dead time is not easily accomplished in analog systems but is not too hard in digital. Assume you have a deadtime of T seconds and a sampling interval of dt seconds. You need a strip of memory with T/dt registers. At every sample you drop the bottom value while shifting the contents of all registers down one. Then you place the new sample at the top. (The efficiency of this can be improved with a rotating pointer.) The value you dropped is the one you use in your controller. As I mentioned before, this is really part of the process, not part of the controller. Incidentally, dead time due to process flow varies inversely with flow rate.
Walter.

variables
into
of
respresent
prior
be
controller
information
URLs
endless
no
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I am sorry but I find it difficult to follow you because I don't acquire any control background. I am only interested in the simulation of a biological model that represents what takes place in a certain wastewater treatment plant & as these plants are usually automated or at least some of the operating variables such as dissolved oxygen rate or internal recycle stream, thus I was just trying to incorporate such aspects into my system.
The features of the PI controllers I am trying to simulate are meant to be a sort of standard & simple control. The first PI controller is described as ideal, whereas the second is described as experiencing white normally distributed noise of deviation = 0.1 & a 10 minutes delay.
I understood from your previous post that the noise is added to the measurement so now if there a delay (a feature of the process as you describe), how should I handle this delay?
Thanks very much for your information.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Lucy, I've been following this thread a bit. You asked a pretty good question and got some great answers from the wizards. I think they figured from your question that you were ready for the high end answer.
At any rate, in a simulation, you could use a time delay element, which would basically be an array holding your control actions for each control time. Lets say you have a 10 minute delay in control, and you are allowing your controller to run every 30 seconds. You will need 20 elements in the array. Every 30 seconds, shift the values up (or use a pointer and shift it) and send the oldest control value to the process, then insert the newest value into the array.
For the noise, you will look at the range of each input point. Lets say that you have an input with a lower value of 20 and an upper value of 40. Your range is 20. Add to the input values a random value constructed as
20 * (random_number - 0.5)* 0.01 [random_number's interval is 0 to 1]
Which should just about do it.
You will notice that the noise isn't going to affect the PI controller too much. Most of the time, we measure a lot faster than we control, and often take a filtered average of the last several values. This has a tendency to drop the noise levels down inversely proportionately to the square root of the number of averaged points.
Michael

variables
into
part of

respresent
prior
right
code be

controller
information
URLs
endless
no
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Lucy,
Perhaps our posts crossed in the mail (does that make it cross-posting?) or perhaps you missed one, so I'll just cut and paste what I said yesterday.
"Pure dead time is not easily accomplished in analog systems but is not too hard in digital. Assume you have a deadtime of T seconds and a sampling interval of dt seconds. You need a strip of memory with T/dt registers. At every sample you drop the bottom value while shifting the contents of all registers down one. Then you place the new sample at the top. (The efficiency of this can be improved with a rotating pointer.) The value you dropped is the one you use in your controller. As I mentioned before, this is really part of the process, not part of the controller. Incidentally, dead time due to process flow varies inversely with flow rate."
Walter.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John,
How can your controller not have windup if it has integral? Since velocity algorithm controllers inherently integrate the Delta.output to produce an output, they inevitably wind up if there is an interruption of the feedback loop. This is not a property of the controller by itself but of the fact that the loop is interrupted and the controlled is attempting to do the impossible.
Try this with your system: Put the controller on automatic with the process variable on the setpoint. Now disconnect the output from the valve and slightly increase the setpoint. The controller will now go to full scale 100% (or 0%) as the controller tries to make the process variable catch up to the setpoint. That is windup, Part 1. After waiting a bit, reconnect the output to the valve again. It will slam wide open and the process variable will rise to the setpoint and continue upward to exceed it. That is windup, Part 2. Until enough positive deviation accumulates in the integrator to undo all the accumulated negative derivative, the vale will not start to close. Eventually it will do that and all will be well again.
One way to prevent this is to disconnect all integral if external logic disconnects the output. This is often done by putting the controller in manual the moment the loop is broken. Another thing to do is to stop integrating when a limit is reached. You must realize, however, that you already accumulated some undesirable integral. That is, you've limited the windup but not eliminated it altogether.
Consider this: You are talking at a noisy party. As the noise level goes up, you start to speak louder and louder. (This is a positive feedback loop which can end up with everybody yelling. Then you have achieved saturation.) If suddenly everybody stops talking will you find you are the only one yelling in a quiet room. You have 'wound up'.
Have you ever seen a comedy sketch in which someone keeps tromping on a disconnected brake, or some similar, futile exercise. That is windup. Anot her example is terrorists who redouble their efforts despite not achieving their aim. If suddenly their wish is granted to them, they can't stop fighting. They've kind of gotten into the habit. They are wound up. People should shut up when no one is listening. (Does this apply to me? No. I haven't started writing in FULL UPPER CAP YET!!!!)
Walter.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Walter,
Yes, the limits, both min and max speed and rate of change, on Variable Frequency Drives can cause a form of windup. VFDs are increasingly used for manipulating flow. Many VFDs allow the user to set a maximum rate of change, a minimum speed, and a maximum speed. It is possible for the PID output to "get ahead" of the VFD controlled speed. This can cause cycling in situations where it would not exist without the speed change limit. The minimum and maximum speed is similar to other forms of override control where the PID output is limited.
I agree that the internal min and max output limits on the PID controller should be set to correspond to the limits on the VFD. That can be done on almost any controller.
I have had problems with the rate of change limit only one time. In that case we had a feedback from the VFD that gave the frequency (speed signal to the pump motor). I could connect that to the external feedback of the PID. That seemed to solve the problem.
Regards, John www.jashaw.com/pid

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I don't remember participating in a discussion on setpoint changes.
However, there are times that the operator should not make a large setpoint step change. However, with most control systems not the operator can make a setpoint change by somehow selecting the value, typing in a new value, and pressing enter. That's a big step change. In the old days he was forced to press an up or down button and hold it, slowing the setpoint change. This is one reason for the increasing use of derivative on process rather than error (and sometimes gain on process rather than error).
Most of the time its a matter of instructing the operator on the need for only slowly changing the setpoint if the loop is in automatic. Type in a small change, hit enter, wait, type in a small change, hit enter, wait... etc. You can guess how effective the instruction was a month later.
In at least one case I had to configure special logic to provide a ramped setpoint. The operator keyed in a new setpoint which was stored in a value, the logic ramped up the "real" setpoint of the pid algorithm.
John

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
The two of you seem to be missing my point. A motion controller does not instantanly move the setpoint to the desired position. The motion controller takes care of ramping the SP from one value to another. It would seem to me that finer process control systems would have the same feature. The user puts in the desired SP, this is may be a step jump from the users point of view, but the control system computes and actually ramps the SP from one value to another at a optimal rate. There should be a user SP and a controller SP.
There has been very little or no mention what to do with the bias. How can you control a process without a bias function? Ok, you can, but the integrator will wind up. Integrator wind up should not occur. We use integrator windup as a measure of how far off our model ( feed forward/bias gains ) are. When the bias is setup right, the interrator term stay close to zero.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I went back to Peter and Walter's post from Mar. 14, 2000 to better understand the discussion (thanks to Google Groups). http://groups.google.com/groups?q=group:sci.engr.control+author:Driedger&hl=en&lr=&ie=UTF-8&oe=UTF-8&as_drrb=b&as_mind &as_minm=3&as_miny 00&as_maxd&as_maxm=3&as_maxy 00&selm8CF0578.2AB7CFFE%40cadvision.com&rnum=4&filter=0
Motion control differs from Process Control more by what's important than by the technical aspects. It is quite common in process control for operators to enter a new set point, press the enter key, and have a step change. However, in some loops that creates a problem. I don't know if any DCS offers a pre-built solution where the "operator set point" is saved and used as an end point for a ramp of the "real set point". If there are none, it is because the number of applications and amount of user demand is less than for the other very many features offered in DCS PID blocks that are not found in PLCs.
One common solution, which is a option found in at least some process control systems is to apply the gain and derivative only to the process, not to the error. A step change in the set point will not result in a step change in the output but rather a gradual change in the output based on the reset time (usually longer in such situations). This will have the effect of ramping the process to its desired value. Sometimes operators will switch a loop into manual, change the output, and switch back to auto if they do not like a rapid change in the output.
On some occasions I have added logic to implement an "operator set point" and a "real set point" that was ramped until it equaled the operator set point.

On an always closed loop, properly calibrated (including output limits), well tuned process loop it won't occur. However, often in control loops, as discussed in the previous posts, the output does not directly control the valve. Something else (a min speed VFD limit, an override loop, a secondary flow loop that will not deliver the required flow, etc.) prevents a change in the PID output from causing the process to change. Then we have windup. Techniques, including external feedback (or reset feedback), are used to correct it.

There normally is not bias on a PI controller. On a P only controller there is bias (or manual reset).
John

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Noise shouldn't should affect the integrator too much as the integrator is similar to a low pass filter. Delay or dead time will cause the integrator to wind up because the system will appear to not respond to the control signal for a period of time. See Smith Predictor. Now your simple PI controllers isn't so simple.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.