Problems with PID loops

[Lancie1]

There are many successful processes controlled with simple stand-alone PID controllers

Because we got along with horses and buggies does not mean that we had to keep using those when the automobile was available. Some people preferred horses and still use them today (I have many Amish friends and love to visit their homes).

 

[daba]

Because we got along with horses and buggies does not mean that we had to keep using those when the automobile was available. Some people preferred horses and still use them today (I have many Amish friends and love to visit their homes).

Are you implying that PID control via PLCs is better than using stand-alone PID controllers ?

 

[Lancie1]

No-no. I am saying that having access to all PID parameters is better than not. If you don't need to use them, then you don't have to, but if ever you do, you can. It is a nice choice to have.

 

[dcooper33]

Daba,
I am inclined to agree that in most cases I have seen stand-alone controllers outperform PLC PID's.
That being said, I agree with Lancie that there is no sense in not using a tool just because you used to get by without it.
I have not personally seen anyone else's code that used the Integral Sum value, but I have used it in a couple of applications. What happens to the CV if the I gain is changed (auto or manual)? You may get a nasty bump to the CV and then have to wait for the oscillations to die down to see if your new gain gave you better control, UNLESS, you multiply the current I sum by the ratio of Old Ki/New Ki and write that value to the I sum.
Another way I use it is when I have a process that needs modest gains for SP change tracking to avoid overshoot, but more aggressive gains for disturbance rejection. I run a timer when the SP is within a very small error range, to indicate process stability. When the timer is done, zero the I sum, change to the aggressive gains, then write the current CV to the .BIAS parameter. This way, the bias is holding the process at SP, and the PID is only dealing with disturbances.
Yes, it is more work, and not always worth it, but my point is that if the tools are in the bag, sometimes they can be very useful, especially if a more sophisticated method like cascade control is not feasible.

In fact, any stand-alone controller that advertises "bumpless transfer" has to, by definition, manipulate the I sum on the transfer back to auto mode.

That control loop was one of the very, very, best I have ever witnessed, and the guy deserves a mention Sadly I forget his name, he worked for Eurotherm.

I've seen enough well (and badly) tuned loops to know that there definitely is as much art as there is science to properly tuning a loop. I have immense respect for guys who make things work beautifully with the tools at their disposal. But don't you think this same guy would have used any information about the process and the PID controlling it that he could get his hands on if it provided more accurate control?

Punt?

Well played, sir, well played.

 

[plc.ucd]

Yellow Line - Prime pumps on/off HMI puhbutton
Reddish - integral accumulator for the milk flow PID loop
Blue - Milk Flowrate

Sorry it took me so long to post the trend. I am noticing that during the prime function which forces the loop into SWM, the integral accumulator is rising and causing spikes in the CV, which is resulting in the flowrate spikes. I am wondering if there is a way to eliminate these spikes. I tried using the PV tracking feature do drive the the error/integral acc to zero. Do you guys have any suggestions. After the flow has stabilized I can really dial in the flowrates.

 

[Lancie1]

Do you guys have any suggestions.

I think Bmacattach summed it up well.

Daba,
Another way I use it is when I have a process that needs modest gains for SP change tracking to avoid overshoot, but more aggressive gains for disturbance rejection. I run a timer when the SP is within a very small error range, to indicate process stability. When the timer is done, zero the I sum, change to the aggressive gains, then write the current CV to the .BIAS parameter. This way, the bias is holding the process at SP, and the PID is only dealing with disturbances.

 

[Peter Nachtwey]

Oh, no!!!!
If the system is tuned up right the gains shouldn't need to change unless the plant itself changes.

In fact, any stand-alone controller that advertises "bumpless transfer" has to, by definition, manipulate the I sum on the transfer back to auto mode.

A PID should not accumulate the sum of errors. It should accumulate the sum of errors x the integrator gain. It makes a BIG difference in the ease of implementation and use.

 

[Lancie1]

It should accumulate the sum of errors x the integrator gain.

I think the gain is applied later. Besides, if the PID is restarted, the new sum of errors (0) X integrator gain = 0, which can cause a finely-tuned process to get upset.

 

[Peter Nachtwey]

I think the gain is applied later. Besides, if the PID is restarted, the new sum of errors (0) X integrator gain = 0, which can cause a finely-tuned process to get upset.

I know many PLC PIDs apply the gain later. That is the problem. How does one limit the integrator if the units are in error*time when you really want to limit output.

One shouldn't reset the PID back to 0. If the PID is in manual mode and switched to auto then the SP should be set to the PV so there is no error. The integrator's contribution to the control output should be set to the current control output. Then there is no bump in the control output until the set point is changed.

 

[dcooper33]

A PID should not accumulate the sum of errors. It should accumulate the sum of errors x the integrator gain. It makes a BIG difference in the ease of implementation and use.

Sounds like you're talking about velocity vs. positional algorithms. In RS5k, the velocity PID is only offered in Function Blocks. The ladder version of the PID is only offered in positional form. Which form is better is debatable, and I think depends on the application. Probably a subject for another thread.

The integrator's contribution to the control output should be set to the current control output. Then there is no bump in the control output until the set point is changed.

Either way you're doing it, whether with a dynamic bias or with an integrator's contribution to eliminate steady-state error, the result is the same. Either way, whether you zero the integrator on transfer to auto, or set it to equal current output, you still are having to manipulate the I contribution.

I know many PLC PIDs apply the gain later. That is the problem. How does one limit the integrator if the units are in error*time when you really want to limit output.

Limit integration in the direction of CV saturation.
If CV=CVmax and Isum > Isum(n-1), then Isum = Isum(n-1)
If CV=CVmin and Isum < Isum(n-1), then Isum = Isum(n-1)
In other words, Anti-reset windup, which is built-in to the Logix ladder PID.

@plc.ucd

I can't make anything of your trend, it's too noisy. Try posting another trend of a SP change. Just trend the SP, PV, and CV. Use high contrast colors like red, blue, and green.
Also, if feasible, put the controller in manual, manipulate the CV until you are just below the normal setpoint and the PV is steady. Then "bump" the CV up a few points (enough to push the PV a little beyond the normal SP). After PV levels out again, return the CV to it's original value. Stop trend when PV levels out again. This trend would be the most helpful in suggesting gains. The graph should show steady-state PV before and after the CV bump and return.

 

[Peter Nachtwey]

BETTER, Dynamic integrator limiting

Error(n-1)=Error(n)
Error(n) = SP(n)-PV(n)
CVpd=Kp*Error(n)+(Kd/T)*(Error(n)-Error(n-1));
CVi(n)=CVi(n-1)+Ki*T*Error(n);
CVi(n)=max(min(Cvi,CVmax-CVpd),CVmin-CVpd);
CV(n)=CVi(n)+CVpd;

See
http://deltamotion.com/peter/Mathcad/Mathcad - t1p1 pid pi-d i-pd.pdf
Notice that the integrator gets set in the opposite direction of the step change and then winds up from there. There is no over shoot when the control output goes into saturation as you can see. I need to redo the pdf to get the scaling better.

Velocity mode is better if using the integrator. Actually I hate the term velocity mode because it has nothing to do with velocity. I prefer the term incremental PID. The incremental form of the PID allows one to change the gains on the fly and not have a step change in the control output.

 

[dcooper33]

Gains can be changed on the fly in positional mode, too. It's just more work to avoid nasty CV jumps, obviously. I agree that the velocity mode is much better suited to gain-changing, but the velocity form is not available on a lot of platforms.

I agree, the term "incremental" seems more accurate than "velocity"

I don't understand the first line of code:
Error = Error(n-1)
Is that only on a SP change?
Otherwise, very clean. This basically the same way that I wrote my PID equation on the micrologix simulator I use at home. I find it to perform better than the built in PID

 

[Peter Nachtwey]

It is good you didn't understand because I got it wrong

I don't understand the first line of code:
Error = Error(n-1)
Is that only on a SP change?

It should be

Error(n-1) = Error(n);

This is for calculating the rate of change for the derivative gain.

You can make the control output bump less by using an I-PD type of PID. I really like the incremental form of I-PD for all sort of things where the SP can change in steps or erratic ways. I-PD is good for responding to step changes, following analog signals from joysticks and also as the inner loop withe the SP to the inner loop is generated by the control output of the outer loop and usually is very noisy.