PID help needed

Could anyone recommend a good site dedicated to learning PID? Specifically AB SLC's would be nice but the fundamentals would work, I always get confused on the 3 funtions and their jobs in a loop

If you search the archives on this site you will find lots of info on PID, and a lot of it SLC specific.

Control Engineering Magazine has lots of articles on PID, including tuning and fundamentals.

http://www.controleng.com/

Well, which do you want - Basics in PID, or PID the Allen-Bradley way?

There's a book, PID Without the Math, By David St. Clare, that does an excellent job of explaining the principles. Here's a link:http://members.aol.com/pidcontrol/booklet.html

Now for my spin (I hope I've got this right):

The key to PID is the Error. That's just the difference between Where-you-are (Process Variable) and Where-you-want-to-be (Setpoint). This is either calculated as E=PV-SP or E=SP-PV depending on whether the response (say, valve position) should increase (open more) or decrease (close more) on a positive error.

In a PLC, the PID block is updated at a specific frequency. (In the AB - there are two ways of doing that, STI and Timed). Anyway, at an even time interval, the PID block wakes up and calculates the new Error. It also remembers the last Error that it had, and the Error before that (you'll see why below)

First, the Proportional part. If there was only a P term, then the equation would be simply:

<center>New_Output = Old_Output + P*(New_Error - Old_Error) </center>

That is, each time the PID block wakes up, it adjusts the output by an amount Proportional to the change in the error. Eventually, the system will overshoot, creating a negative error, the Output will be reduced, and it will oscillate as it settles in on the new "sweet spot" of the output.

The Proportional is sometimes called GAIN (as in how much has the system GAINed since last time)

Next for the Integral part. In most systems, the system may stablize at a particular output, but still leave an error. Or, the system may go into oscillation, overshooting (which causes a negative error, which in turn drops the output) and then undershooting (positive error => increased output), etc. Sometimes the oscillations dampen out. Sometimes not.

To prevent that, we take a look, not at the change in error, but at the absolute Error. If you are looking at a plot of Error over time, what you are interested in is the area under the curve for that last time period.

You are no doubt familiar with integration (calculating the area under the curve) when converting Flow Rate into a Totalized Quantity. The intergral term does the same thing. But we don't want all of it, just some fraction (the I, or K_I)
Adding that to the equation, we get:

<center>New_Output = Old_Output + P*(New_Error - Old_Error) + I*(New_Error * Update_Time) </center>

The integral term is also RESET because of those cases where the system has stablized (unchanging error) but is still short of the goal. The I term "Resets" the system to produce a zero error.

As you can see, it is possible, if the integral term were to get too big, that the New_Output would "wind up" being larger than 100% or less than 0%. The PID block allows calculated New_Output to be larger than 100% (it has to, since it may be desirable NOT to lower the CV at the begining of a negative error), but of course it only drives the CV to 100%. However, this can also cause big problems, and to solve it, you need "anti-reset windup".

To enable "anti-reset windup" in the SLC, you just set the Output Limits to 0 and 100%, and enable Output Limiting (the .OL bit). Then, no matter what the integral term says to do, New_Output won't be more than 100%.

Now for the Derivative. That's tougher to explain (meaning I'm not clear on it myself). But the basic idea is that as the error is changing rapidly, that means that the system needs to back off now, otherwise it will overshoot. So you look at the slope (or Derivative, if you remember your calculus) of the CHANGE in Error. The slope of a line is Rise/Run or

<center> {Y₂ - Y₁} / {X₂ X₁}</center>

But each point represents a change in Error, so this becomes

<center> {(New_Error - Old_Error) - (Old_Old_Error - Old_Error) } / {Time₁ - Time₂}</center>

or

<center> {New_Error - 2* Old_Error + Old_Old_Error} / {Update_Time}</center>

The Derivative is also called RATE because it is examining the Rate at which the Error is changing.

I'm not going to roll that part into the PID equation, just to say that that whole mess gets multiplied by D and added to the end.

<hr>

Now, that's the easy theory. Implementation gets tricky, because each PLC/DCS manufacturer does it differently. Some have the P term multiplied by the whole thing (so that doubling P doubles the effect of I as well). Others use K_I= 1/I (and you'll know this because the units will be in seconds per reset (or think of it as seconds between each reset) instead of resets per second (which my description has). Others don't use seconds, but minutes, which throws things off, too. Some allow you to do all the above, not on error, but the raw PV (why? dunno - I've had it explained to me, but I'm no expert).

Now to the SLC, for a specific. I think you can see why it's important that the PID block not have any conditions on the branch. If it does, and those cause the PID block to be "disabled", then all those numbers stored in it, for what should be the "last" value/error are wrong, and so when the PID finally does "wake up", it's looking at bad data and produces bad results. To turn off a PID, set the Auto/Manual bit (bit 1 of word 0 of the control block), and then the PID is in manual, and it knows it's not driving anymore. But the info is still being updated.

You can also see how critical the Update Time number is. I can't tell you how many times I've seen it set to 0.01 sec (faster than PLC scan). The SLC doesn't care (or at least, doesn't bother timing) what the time between updates really is, it just checks to see if the elapsed timer has expired, and updates the data if it has. That's why in one post on the old forum I said that it doesn't matter. And it doesn't. But the PID block will be updating faster than perhaps it should. You want the update time to be about 1/4 of that P-only oscilation I mentioned earlier. This should be the first tuning parameter set. If it's wrong, all the others will be wrong, too.

Well, I think that this is enough to get you started. Thanks for the opportunity to put this down - I actually learned something in preparing this.

Feel free to ask anything else about the care and feeding of SLC PID blocks.

PID without maths... well... almost!

You are in a shower. You turn the water on and its...COLD

First human reflex is to turn the dial way onto the HOT side...

This is the difference between the temp. that you want and the temp that you have... its P
The farther apart... or the greater the error then the greater the intensity of the action...

Remember, you're under the falling water...

So here you start feeling the warmth of the hot water coming in... OUCH! Its way to hot...

You turn the dial way to the cold side... But now it's way to cold...

You are oscillating. P will make your system oscillate if it's alone...

So its to cold... your not going to turn that dial way to the hot side... Are you? No way BJ. You will increase it little by little. But how often will you do this? You know the pipes are a few feet long, so you do it every 10 seconds... So you in fact are doing a repeat of youre little step every 10 seconds... these steps getting smaller has the tepm. closes to your desired temperature...

This is I

I disapears when the error disapears... smart man you are!

So you are taking a shower, happy camper... but then,

Honey... I'm starting the dishwasher !!!!

For better and for worst, your the one who said yes. Remember?

What can you do.

Has you feel the water temps abruptly sinking into the deep polar zone, You turn the dial way up the HOT side. To the limit.
You know the pressure drop from this machine starting up is only temporairy. You know you must get that dial of the max hot spot soon.

So you turn it gradually toward the spot it was a few momments ago. You almost did not feel that cold water coming in and neither did you have to much hot water... What a guy! You've just added D to your temperature control system. You are a thrue PID man.

Usually we never use D in a temperature control system unless has you've just seen... ther is a variation of systems input, the load or the power.

Allen, the differentiator is this:

New_Output = Old_Output + (D/Update_Time)*(New_Error - 2*Old_Error + Older_error )

Allen's theory of PID control is certainly different from anything I have ever read or experienced.

My 'spin':
First of all, decide if you want forward or reverse acting - which means do you want the output to increase or decrease if the PV exceeds the SP. You determine this by selecting the error calculation as either PV-SP or SP-PV.

With AB PLC's/SLC's you get a choice of two equations for the control - dependent or independent gains. Independent may appear simpler initially, but dependent is my recommendation as this is what most instrument techs are familiar with from working with stand-alone controllers.

The proportional term acts on error. With no I or D terms the output will simply be P-gain times error. Note that if there is no error, there is no output. Therefore, the best you can hope for with straight proportional control is a steady state error. To achieve a steady state error within tolerable limits, you will probably need to add a fixed offset to the output.

If you need to reduce the error to zero (or near) then add integral gain or reset to the loop. This integrates the error over time and adds to the output at the reset interval specified. This 'nudges' the PV closer to the SP. The output of the integral term (reset value) takes the place of any fixed offset.

The derivative term works on the rate of change of either the PV or the error to give output change in anticipation of where the process is moving in order to limit the deviation from SP that might occur.


My experience is with fairly simple level and temperature controls and most of these can be controlled satisfactorily with proportional and a fixed offset. A minority require P & I. I have never had to work with loops requiring derivative gain. From what I have read, derivative gain is rarely required or used, and can easily introduce instability.

If you look through the old forum, you'll come across a lengthy disagreement between Allen and myself regarding the loop update time parameter in the SLC. My position was based on a tech note applying to PLC5's that I read years ago and I assumed the SLC would be similar. I must investigate that. That thread also includes some useful insights and equations from Peter. Worth looking for.

Gerry:

I looked at that old post you mention. Here's the LINK

Peter's equations in that post match what I was saying exaclty (and which Peter finished up for me in his post here. He may have also prevented an extra "divided by Update_Time" in the D portion, for which I thank him.).

But I'm not sure that you and I disagree as much as you think.

Forward/Reverse Acting - Yep, same as I said.

Proportional act on Error - Sorta. CHANGE in Output acts on CHANGE in Error. I think you agree with this because you say:

Therefore, the best you can hope for with straight proportional control is a steady state error.

Click to expand...

So if the error doesn't change, the CV won't change. This is different from what you were saying (paraphrasing) "If the error goes to zero, the CV goes to zero"

Integral 'nudges' the PV closer to the SP. Yes - I just say is as 'nudges' the "Error to zero". Same thing. "Integrates over time" is simply Error time Update_Time. As for the internal working of the PID block, my guess is (and I have to guess, since AB isn't clear), that if the update time longer than several scans, that the PID block does the same totalization calcualtions that we use for accumulated flow, rather than doing it all at once at the end of the Update_Time.

Derivative works in anticipation - Yes again. You and Pierre said it better. And because it anticipates, it can misinterpret a "hiccup" for a major change, and cause problems.

As for the Update Time, the math I posted shows how the PID equation uses the time value entered. If you have a tuned loop, and then you go and double the Update Time, you need to half the Integral term (or Double it, if the units are in Seconds per Repeat instead of Repeats per Minute), and double the Derviative term. Doubling the Update time will have the CV generated by PID block change less frequently (provided that the number entered is greater than the scan time).

As for the Dependent/Independent thing - I think (but I'd have to check my notes, and they're at work (along with St. Clare's book) that what I was talking about when I said that some PLCs implement the equation as multiplying K_P times everything, instead of just the change in Error part (only I didn't say it that way). If the Integral part is Independent of P, then it may be easier to tune in the first place: Tune for P, then fine tune for I. But if it's Dependent (or E*T is mulptiplied by P and I, instead of just I), then it may be easier to retune, as changing the P makes the loop 'faster' or 'slower' because it affects all three terms.

Ultimately it doesn't matter, as long as you know what's going on. (To which no doubt Terry would chime in with "That's why you should roll your own")

It's really not that hard - it's just no one ever seems to explain it like this (although St. Clare comes close - and goes into lots about "How to Tune", which is great stuff).

PIDSIM.ZIP and Pickled PID

Here is a link to an old DOS program that allows on to setup a system and then tune it. I tried to attach it but it was just a little to big.

http://www.simtel.net/pub/dl/50406.html

The http://clabberhead.com had an OK simulator for temperature tuning.

Just for completeness I will pickle the PID.

Thefore when the PID terms are combined:

y = y(n-1) + (Kp*T)*(e-e(n-1) + Ki*e + (Kd/T)*(e-2*e(n-1)+e(n-2))

Where y are outputs.
e are the errors
Kx are the different PID gains
T is the update time.

Collecting on the error terms yields

y = y(n-1) + e*(Ki*T+Kp+Kd/T) + e(n-1)*(-Kp-2*Kd/T)+e(n-2)*Kd/T

because the gains don't change from sample to sample it is best to simplify further.

k = (Ki*T+Kp+Kd/T)
k(n-1) = (-Kp-2*Kd/T)
k(n-2) = Kd/T

the result is:

y = y(n-1) + e*k + e(n-1)*K(n-1)+e(n-2)*k(n-2)

WOW, a PID with 3 mulitplies and 3 adds! Who said this had to be difficult and confusing?

THE ABOVE PID is for systems with fast updates and don't allow step jumps in the Set Point or Target.

For fast updating systems that allow step jumps use this

y = y(n-1) + Ki*T*e - Kp*(c-c(n-1) - (Kd/T)*(c-2*c(n-1)+c(n-2))

NOTICE THAN ONLY THE INTEGRAL TERM DEPENDS ON ERROR.

c is the ACTUAL or Process variable.


Some allow you to do all the above, not on error, but the raw PV


You can see that the second form of the PID will handle step changes in the target or set point better with less chance of saturating the output y. Because the second for only cares about the set point or actual, which is a feed back, this second for is sometines refered to as I-PD.

So where does this I-PD formula come from? I will derive just the propotional term

This is a simple proportion term.

y = Kp * e

This is the previous proportional term

y(n-1) = Kp * e(n-1)

Now subtract the second formula from the first formula and you get

y - y(n-1) = Kp * e - Kp * e(n-1)

Add y(n-1) to both sides

y = y(n-1) + Kp * e - Kp * e(n-1)

Now collect on Kp

y = y(n-1) + Kp*(e-e(n-1))

The above formula for proportional gain is what Allen presented. Now on to the I-PD form

e = r - c

e is error
r is target or SP
c is actual or PV

Therefore the above equation is

y = y(n-1) + Kp*( (r-c) - (r(n-1)-c(n-1) )

NOW HERE IS THE KEY POINT. The I-PD form should ONLY be used when the set point or target is not ramped from on value to the next. Process people change set points with step jumps. Motion people smoothly ramp the set point from one spot to another. If one is making step jumps the one can assume that

r = r(n-1)

Rearranging the above and collecting the r and c terms

y = y(n-1) + Kp*( r-r(n-1) - c+c(n-1) )

Since r is assumed to be equaul to r(n-1) then

y = y(n-1) + Kp*(-c+c(n-1))

Now fix the signs by moving the minus sign in front of the Kp

y = y(n-1) - Kp*(c-c(n-1))

Since there is no set point or target term one can make step jumps all day and the P term of the I-PD will not cause big swings because it only cares about the feed back ( SP or target )

So here it is. Pickled PID.

I did some investigating

I've discovered that there are some subtle differences between the PLC5 & SLC versions of the PID instruction. My experience is with the PLC5 version and I should know better than to make assumptions.

First, the SLC doesn't offer a choice of equation - it uses the dependent gains (also called ISA) equation.

If I could figure out how to include a chunk from a pdf file the following might be clearer, but here goes: (read "{" as an integral sign)

The equation is:

Output = Kc[(E) + 1/Ti{(E)/dt + Td - d(PV)/dt] + bias

Kc = controller gain (unitless)
1/Ti = reset term (minutes per repeat)
Td = rate term (minutes)

The above is from the SLC instruction set reference. It indicates to me that without an integral or derivative term, the output is simply gain * error. Not old output + gain * delta-error. That has always been my understanding and experience.

Also, only the SLC5/03 and above offer a choice of error or PV for the derivative term.

On to loop update:

Another difference - the SLC version has a setting called 'Mode' that is not in the PLC5. If mode is set to 'timed', then the instruction operates independently as Allen described in the old thread. If mode is set to 'STI', then it only calculates when scanned, which is what I was describing. Even in timed mode you can experience the problems I was talking about:

Loop Update Time Too Fast TF (word 0, bit 06) is set by the PID algorithm
if the loop update time you have specified cannot be achieved by the given
program (because of scan time limitations).
If this bit is set, try to correct the problem by updating your PID loop at a slower
rate or move the PID instruction to an STI interrupt routine. Reset and rate
gains will be in error if the instruction operates with this bit set.

Click to expand...

Which is why, in the first line of my first reply, I said:

Well, which do you want - Basics in PID, or PID the Allen-Bradley way?

Click to expand...

.

And why I also said that I hoped that I had it right. I'm not sure how Rockwell implemented PID. Each manufacturer is different in their approach, so this is not just a failing on Rockwell's part (although one could wish for more form an industry leader)

To see what I'm talking about, see the following link:
PID Equation Collection

This also applies to Peter's math. What Peter has done is shown how the PID should work. The link shows how the vendor's have implemented it. Almost every vendor does it differently!

Unfortuanately, I don't have any SLCs to play with, so I can't do some empirical testing, thrending PV, SP, Error, Change in Error, and CV. If you do, Gerry, let me know what you see. With P-only, I don't think I've seen CV=0 on Error=0, but I could be wrong. It's a simple enough test:

1. Create a program where there is no real Analog input, so you can set it to whatever number you want, say 50% of full range (=2048 for a 0-4095 in a PLC-5; 8192 for a SLC's 0-16383 range).
2. Configure a PID block for P-only.
3. Set a setpoint to produce a non-zero CV.
4. Change SP=PV (Error=0). If the CV stays, I'm right.
5. If the CV goes to zero, Gerry's right.

Wait.
That won't work.
Because the Error will have changed in one scan, the P portion will also change, and drive the CV back to where it was before (=0). This would explain what Gerry observes. There's got to be a way to design a test to show who's right. Ideas, anyone?

<hr>

Oddly enough, no matter how it works, theres a few simple programming techniques that Scott Laubach could use.

I scale all analog inputs for use by the HMI, and I soft-code the scaling factors, so I can change it easily when the sensor-type changes, or calibrate it in the field. On some systems, I'll write a calibration routine to compute the numbers, or just expose them to the user via the HMI so that they can calibrate them. Easy enough in the SLC, using the SCP instruction.

        +------------ SCP ------+   

        | Input:          I:1.0 |

--------+ Input Min:      N32:0 |  

        | Input Max:      N32:1 |

        | Scaled Min:     F33:0 |

        | Scaled Max:     F33:1 |

        | Scaled Output:  F31:0 |

        +-----------------------+

The Values N32:0 and N32:1 will depend on what kind of module is used, and in some cases, how it is configured. Typically they are 3277 and 16384 respectively, but sometimes 4000 and 20000, or 0 and 16383.

To get the analog into the PID block, I'll rescale it, just to be sure that it's scaled 0 to 16383, since that's what the SLC PID block requires.

        +------------ SCP ------+   

        | Input:          I:1.0 |

--------+ Input Min:      N32:0 |  

        | Input Max:      N32:1 |

        | Scaled Min:         0 |

        | Scaled Max:     16383 |

        | Scaled Output: N34:23 |

        +-----------------------+

Note the reuse of the Raw Input Scaling Addresses.
(Yes, some 1747 modules allow you to scale the input "for use in PID", that is 0-16383, other's don't.)

The setpoint also has to be scaled to go into the PID. I have the setpoint be generated by the HMI (or PLC program) in engineering units (F40:1), but then make sure it's scaled properly into the PID block, I do this:

        +------------ SCP ------+   

        | Input:          F40:1 |

--------+ Input Min:      F33:0 |  

        | Input Max:      F33:1 |

        | Scaled Min:     N34:8 |

        | Scaled Max:     N34:7 |

        | Scaled Output:  N34:2 |

        +-----------------------+

Note the reuse of the Scaled Range addresses.

Very important point, here. The Values in N34:7 & :8 (which will be words 7 & 8 of the PID block), are the Setpoint Max and Setpoint Min parameters. When if the values in those are set the same to those in F33:1 and F33:0 (respectively), the above instruction is little more than a Move from a float into the setpoint register. Also, when set like this, the PV and SP read in engineering units when viewing the PID block in RSLogix.

But that scaling also affects the Error calculation, which is also in the scaled units. So if your range is 0 to 75 PSIG, you will not get very fine control.

Instead, you could set Smin and Smax to 0 and 7500, and your loop will be easier to handle. Or you can set them to 0 and 16383, which will give you the highest resolution of error, but you loose the advantage of engineering units.

Having the setpoint scaling this way allows you to play with Smax and Smin, without worrying about the effect on the setpoint. Also, the SLC will Fault if the setpoint is out-of-range of Smin/Smax. This code ensures that as long as it's within the scaled range (F33), it won't fault the SLC. (I usually include error checking too, but I'm not going to show that here today)

Finally, the PID

        +-------------- PID -------+   

        | Control Block:    N34:0  |

--------+ Process Variable  N34:23 |  

        | Control Variable  N34:24 |

        +--------------------------+

Nothing special there.

More PID

Just to make the confusion complete.......

The PID algorithm:

PID = Kp*e + Ki*{edt + Kd*de/dt (read "{" as an integral sign and e=error)

The PID controller can be viewed as a function of the past (I), the present (P) and the predicted future (D).

How this analog expression is made discrete may vary.

Here is one version:

P-term: The P controller is a pure gain (no dynamics) of value Kp. -> P = Kp * e

If no error, no output. With a steady system you get a steady state error. (a "trick" often used is useing a internal setpoint that is higher than the real setpoint...)


I-term: Integration or the total of all areas: Ki* (T*e(0) + T*e(1) + .. T*e) = KiT*[e (read "[" as a Sum sign)

An other often used I-term instead of I = KiT*[e, is "I = Output(n-1) + KiT*e". The Output(n-1) is the sum of all earlier area (e*T) and e*T is the new added to the sum.


D-term: Useing Euler Method an approximate for de/dt can be: ( e - e(n-1) )/T. -> D = Kd/T*(e-e(n-1))


PID discrete: y = Kp*e + yi(n-1) + KiT*e + Kd/T*(e-e(n-1))

If you look at the expression you see that making Ki zero doesn't remove the yi(n-1)!! So some if-then must
also be included...

There are a lots of different algorithms. Also with disturbance compensation. (Pierre's: "Honey... I'm starting the dishwasher !!!!" is disturbance to the system..)

If someone open a door to a oven, one can react before the drop in temperature is measured e.g.


Just my 2 kroner...

regards
Karl Egil Liaset

Gerry:

I just re-re-read Peter's post, and we're both right.

Peter Nachtwey said:

I will derive just the propotional term

This is a simple proportion term.

y = Kp * e

This is the previous proportional term

y(n-1) = Kp * e(n-1)

Now subtract the second formula from the first formula and you get

y - y(n-1) = Kp * e - Kp * e(n-1)

Click to expand...

So, it is exactly as you said: Output is proportional to Error. And it's exactly as I said: Change in Output is proprotional to Change in Error. (If A=B, then Delta(A) = Delta(B) - Calculus 101, third week)

I think I've figured out the experiment:

• Do as above.
• Put the PID in Manual.
• Set the output to 35% (make sure to write to both the .OUT, and the CV address in the PID block (N34:24, in my example above. It may require programming to force the CV).
• Set SP=PV (error=0).
• When you put the PID back in Auto, Error will be zero, and so the CV shouldn't change (stay at 35%).

Peter:

Peter Nachtwey said:

Process people change set points with step jumps. Motion people smoothly ramp the set point from one spot to another.

Click to expand...

As a process person, I used to just change setpoints, but a few exothermic reactions taught me otherwise. Now, I not only ramp setpoint changes, I do asymtotic ramps (think a quarter of a sine wave) on those reactions. It turns out that the sharp bend of a linear setpoint ramp causes too much overshoot, so I 'ease" up on the approach of the setpoint. When tuned right, no overshoot at all.

I had a bit of trouble following your deriation at one point, because you changed nomenclature somewhat. If you had said...

Collecting on the error terms yields

y = y(n-1) + e*(Ki*T+Kp+Kd/T) + e(n-1)*(-Kp-2*Kd/T)+e(n-2)*Kd/T

because the tuning constants don't change from sample to sample it is best to simplify further.

A = (Ki*T+Kp+Kd/T)
B = (-Kp-2*Kd/T)
C = Kd/T

the result is:

y = y(n-1) + e*A + e(n-1)*B + e(n-2)*C

Click to expand...

...I think it would have been clearer. Using K(n-1) is confusing when mixed with e(n-1). The latter is a time-based sample, the former is a constant. IMHO

Can you explain what you meant by:

THE ABOVE PID is for systems with fast updates and don't allow step jumps in the Set Point or Target

Click to expand...

Why only fast updates, and not slow? Why can't you jump-step setpoint, instead of ramp?

No, I've never played with Bias/Feed Forward, at least not seriously. From what I've seen, "all it does" is add/subract the bias to/from the Output. Unless this is ramped, this looks like it could be as bad or worse than setpoint-stepping - the output goes from 0 to X in zero time, rather than slowly, like a normal PID.

All the "unhelpful help" say thing like "This value is often used to control a process with transportation lag." But there's no code examples for "Best Practices" programming. As I've said, I'm no expert - I'm just feeling my way along.

Care to post some pseudo code for how (and more importantly where) one should use Bias/Feed Forward?

Which is why, in the first line of my first reply, I said:
quote:Well, which do you want - Basics in PID, or PID the Allen-Bradley way? .

And why I also said that I hoped that I had it right. I'm not sure how Rockwell implemented PID. Each manufacturer is different in their approach, so this is not just a failing on Rockwell's part (although one could wish for more form an industry leader)

To see what I'm talking about, see the following link:
PID Equation Collection

This also applies to Peter's math. What Peter has done is shown how the PID should work. The link shows how the vendor's have implemented it. Almost every vendor does it differently!

Click to expand...

I took a look at the collection and there are basically two equations listed:

1) Dependent gains (aka ISA) - this is meant to emulate a traditional analogue instrument controller and appears to be most common. As I said previously, this is what most instrument techs relate to.

2) Independent gains - this, I believe, is only implemented in computer-based systems. In the PLC5, this is called the AB equation, but I doubt they are the originators.

The only differences in vendor versions of these two basic equations are in the scaling of the gain parameters.

Care to post some pseudo code for how (and more importantly where) one should use Bias/Feed Forward?

Click to expand...

Sorry, no code - however:

Bias: I have used this in conjunction with proportional-only control in simple level and temperature systems with good success. For example, controlling inflow to a tank with variable outflow to maintain a level setpoint. Using P-only, without bias results in low gain and large error. Adding bias to the output, say 50%, enables higher gain and smaller error. This is a kind of 'seat of the pants' solution to level control that I adopted in the days before I had actual PID instructions to play with, but it still works with them and is VERY easy to tune. The text-book approach would be to use PI control with the integral (reset) term replacing the bias.

Feedforward: Never had the opportunity but - envisage a tunnel oven with a transit time of, say 15 minutes, that you want to heat product to a specific temperature at exit. If product entering has been sitting around in the factory and is at ambient, then monitoring the exit temperature (feedback) will give good control. However, if a pallet-load of product is brought in from outside on a cold winter day and fed in, by the time the product exits it's too late to correct but the controller reacts none the less and if the infeed has reverted to ambient-temp product then they come out over-temp. By monitoring the infeed temp and feeding it forward (via a suitable lag or delay network) the disturbance can be compensated for.