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 max outputlim =max; end

if 0

Reply to
lucy borrelli
Loading thread data ...

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

UE = max - outputtemp;

Reply to
g9u5dd43_nospam

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.

Reply to
Walter Driedger

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.

Reply to
Walter Driedger

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

Reply to
Peter Nachtwey

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.

a

information

Reply to
Walter Driedger

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

formatting link

Reply to
John Shaw

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.

Reply to
lucy borrelli

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

Reply to
John Shaw

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

Reply to
Peter Nachtwey

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

measurement of

you a

Reply to
Herman Family

I went back to Peter and Walter's post from Mar. 14, 2000 to better understand the discussion (thanks to Google Groups).

formatting link
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.

Reply to
John Shaw

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.

Reply to
Walter Driedger

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.