Slow PID Loops

J E

Member
Join Date
Jan 2007
Location
Louisiana
Posts
53
Most of the PID loops I have encountered have been extremely slow, and I run into issues. The same issues are coming up with the one I am working on now:

If I use a regular PID loop without any I or D the setpoint is never reached, which is understandable. But when I attempt to add I, there is always extreme overshoot. Even if I use only a very small amount of I, it still causes the overshoot because it spends such a long time winding up that by the time the setpoint is reached, the control variable is way too high.

The current system I am working on is basically a mill with a level transducer. Product is always leaving the mill at a semi-constant rate. The PID loop controls the infeed rate to the mill. The loop is supposed to maintain a desiered level. If the level gets to high, then obviously the infeed must slow down for some amount of time, but then it must increase back to a normal rate when the level gets back to the setpoint. The PID loop doesn't really accomplish this, it just continually overshoots and undershoots.

The PLC is a contrologix FWIW.

Thoughts?
 
What form of PID is used in your software?
There are different forms. You need to check this in documentation.
For example, if it is the following form:
Gpid = Kp+Ki/s+Kds
then small Ki means small integar component.
But if the following form is used:
Gpid = Kp(1 + 1/(Tis) + Tds), then, small Ti time constant means larg integrative component. In the last form, integral gain is actually Kp/Ti, while proportional gain is Kp.
You need to pay attention on the form.
 
What form of PID is used in your software?
There are different forms. You need to check this in documentation.
For example, if it is the following form:
Gpid = Kp+Ki/s+Kds
then small Ki means small integar component.
But if the following form is used:
Gpid = Kp(1 + 1/(Tis) + Tds), then, small Ti time constant means larg integrative component. In the last form, integral gain is actually Kp/Ti, while proportional gain is Kp.
You need to pay attention on the form.

Pandiani is spot on, the first form is the "Independent" form, the second is the "Dependent" form. The PID setup will list this properly. If you don't know the difference between the two, or how the PID is setup you'll never get it tuned right.

Another possible issue, are you using the right loop? Direct Acting/Reverse Acting? That can cause problems. If the PID thinks an INCREASE in CV results to an INCREASE in PV...but your PV really DECREASES with an INCREASE in CV...you'll have problems.

How is the PID being triggered? Is it in a periodic task? Is it triggered at the same rate as the loop update rate? That can cause problems as well.
 
can you zip and post your complete .ACD file? ... (make sure it's not "trade secret" or "proprietary" stuff) ... we'll be glad to take a look at it for you ...

Paully's5.0 has mentioned a VERY common error ... specifically, the PID must be "triggered" into operation at a certain rate ... many people mistakenly set it up to execute on each and every scan of the program ... in that case, the operation will usually be quite similar to what you described ...
 
Ron, just to be sure I fully understand "PID must be "triggered" into operation at a certain rate ... many people mistakenly set it up to execute on each and every scan of the program".

I have experience with Siemens equipment. There, one needs to take care that PID is processed inside regular cycles (cyclical OBs) and that very same cycle time must be entered correctly as an input parameter to PID block. You want to say that PID on other equipment must be executed on every second or third cycle ?!?

Can you elaborate this more?

Thanks
 
I probably shouldn't post it since it was written by an in house programmer. We have been contracted as local support to basically finish startup and continue to maintain it.

The loop is set to independent mode. The controlling action is in the right direction.

The PID loop is in the continuous task, and the rung is set to go true and trigger the instruction on a timer (every 100ms). It also triggers every time the timestamp on the analog input card changes. Also, the "loop update time" on the instruction is set to .1 seconds. I'm not sure why it was set up this way.

The system iteslf has a 3 minute lag before the feed even gets to the mill. Then, from what I understand, the system sometimes takes around 30 minutes or more to completely respond to the change in feed rate and settle at a different level.
 
It also triggers every time the timestamp on the analog input card changes.

that "ALSO" part COULD/MIGHT be contributing to your problem ... but naturally we can't tell for sure without seeing more of your system ...

we FULLY understand that you can't post your program ...
 
Greetings Pandiani ...

the tricky part is that Allen-Bradley (for better or for worse) allows several different ways of setting up the PID – and there can be considerable differences between the various PLC platforms ... for example: SLC-500 systems can be much different from PLC-5 and ControlLogix systems, etc. ... even further: the PLC-5 allows the use of Integer-type control blocks and also PD-type control blocks ... the differences in the "timing" functions of these two types of control blocks may require different setups ...

in the long run, I think that what you're going to find out is that the Allen-Bradley CAN/MIGHT be almost identical to what you've outlined for Siemens – but then again, it COULD be different ... (yes, that needs explaining) ...

let's proceed – staying primarily with the original poster's ControlLogix platform ...

from your post:

I have experience with Siemens equipment. There, one needs to take care that PID is processed inside regular cycles (cyclical OBs) and that very same cycle time must be entered correctly as an input parameter to PID block.

this is the easy part ... Allen-Bradley WILL allow that same type of operation ... in that case, we would put an UNCONDITIONAL (no XIC, XIO, etc.) PID rung into a "routine" (usually a ladder-type file) that would be executed on a carefully timed schedule ... this "scheduled execution" would usually be done by placing the ladder into a "Periodic Task" ... the "period" (the "timing") of the task would be set to execute the ladder file once during each pass through that particular part of the program ...

nailing this down: the PID would be executed EACH and EVERY pass that the processor goes through that particular part of the program – BUT – the processor will only pass through that particular part of the program on a carefully controlled (timed) schedule ...

I think that's exactly the same function that you're talking about with the Siemens "cyclical OBs" ... (note that I have ZERO experience with Siemens) ... and in this Allen-Bradley arrangement, the "Loop Update Time" parameter located INSIDE the PID block, SHOULD be set to match the PID's actual execution rate ... specifically, for the same amount of time as the setting of the Periodic Task ...

so far, I think that we're on the same track with both Siemens and Allen-Bradley – at least in using that ONE type of programming approach ... now let's look at another common way of setting up the PID ... the figure attached below shows the use of a "trigger timer" which will turn on its Done bit for one scan each 500 milliseconds ... the ON status of that Done bit is then used to "fire" the PID and cause it to execute ... as I said, this is another very common way of setting up a PID in a ControlLogix system ...

using this "timer triggered" approach we would NOT (or SHOULD not) place the PID rung in a "Periodic Task" ... instead we should place it in a "Continuous Task" that the processor will run through as often as possible ... using this approach, the setting of the timer determines how often the PID will be triggered ... and in this arrangement, the "Loop Update Time" parameter located INSIDE the PID block, SHOULD be set to match the PID's actual execution rate ... specifically, for the same amount of time as the setting of the timer ...

so far, I think that we're OK with how these TWO approaches SHOULD BE set up in an Allen-Bradley ControlLogix system ... (note that there are other ways to do it besides these two MOST COMMON methods) ...

now let's look at one thing that very commonly goes "wrong" in setting these up ...

suppose that the programmer uses an UNCONDITIONAL rung for the PID – but rather than being set up for execution in a Periodic Task, that PID rung is mistakenly placed in a Continuous Task instead ... oops! ...

in that case, the PID will be executed MUCH more frequently than it should be ... and so the "time critical" components (Integral and Derivative) will be "skewed" ... even worse, if the processor's scan time eventually becomes significantly longer – or shorter – then the PID could effectively become "detuned" as a result ...

specific point: the PID is being physically executed at SOME (possibly varying) period ... the PID's internal Loop Update Time setting does NOT match the physical execution period ... therefore the Integral and the Derivative components are not what they really need to be for optimum control ...

I covered this effect in the following post some time ago ...

http://www.plctalk.net/qanda/showthread.php?p=73610&postcount=10

I know from reading your other posts, that you're certainly beyond needing the "Bubba's paycheck" analogy that I used there – but it might be helpful to other readers of this thread so I've linked it above ... (if you're not familiar with Allen-Bradley, the STI (Selectable Timed Interrupt) feature is very much like the "Periodic Task" that I discussed above) ...

You want to say that PID on other equipment must be executed on every second or third cycle ?!?

no, I'm sorry but you've misread my comments ... I apologize for not making myself more clear ... let me say it another way (again focusing primarily on the ControlLogix platform) ...

for optimum control, the PID must be executed on a consistently TIMED basis ... that "consistently timed basis" may be provided in one of several ways ... one way is to use an unconditional rung in a "Periodic Task" ... another way is to use a timer's Done bit to condition the PID rung and thus "trigger" the PID into executing on a "consistently timed basis" ...

the key point that I've allowed you to misinterpret is that the "triggering" MUST be determined by TIME – not by how many scan cycles have occurred ... specifically: "time" - yes ... "counts" - no ...

hopefully I've made myself more clear ... please don't hesitate to post again if I haven't ...

pid_trigger.JPG
 
Last edited:
Ron,
that is very good and clear explanation. Thank you for that. Now, everything is cleared.
My very first experience with Siemens S7 PID block in student days was to place it into OB1(continuous block). Integral and derivative part didn't make any sense. I used "if all else fails read the manual" approach and learn this the hard way.
I knew that PID must be executed on a regular time base, just wanted to be sure and see example how this is done on Allen-Bradley.

Thanks again!
 
The system iteslf has a 3 minute lag before the feed even gets to the mill. Then, from what I understand, the system sometimes takes around 30 minutes or more to completely respond to the change in feed rate and settle at a different level.

From what you have said about the PID, things seem to be setup properly. You may need to check the scaling parameters within the PID and the analog scaling associated with the IO as well to ensure no problems exist there.

Can you force the system speed at all? If so how do you do it? Does the PID loop go into manual mode when you do this?

I'm failing to understand your system completely, is it just a conveyor that fills a hopper? I don't understand where the lag is comming from? Ahh................what are the Accel/Decel times in the VFD?

Your understanding that it takes 30 min to respond....is that by your observation or by what you've been told?

Personally I would setup a trend of your SP, PV and CV and watch the response of CV and PV to a change in the SP. Post some screen shots of that trend, and note the PID tuning values for each.
 
No Offence to Paully, but I don't agree the PID is setup properly. Having a trigger timer is good, but I am not sure about having the second trigger, how would you match the PID Update Time? It is critical that these match.

If there is a 3 minute delay before any change is seen at the Mill, perhaps even longer, having a 100 ms update time would cause all kinds of problems with I and D portion of the output. Ron can speak with much more authority on this than I, so hopefully he will comment, and post the links to his "What is PID" posts.

Ideally, your PID Input Data would update much faster than your PID Update Time. I have systems where the I only get an new measured value every 30 seconds. What would be the point of triggering the PID every 100 ms? Nothing will have changed. Even a small Integral value would cause the output to overshoot badly.
IMHO, your Input Data has to update a minumum of twice as often as your PID Update Time. Even more often would be better.

Stu.....
 
No Offence to Paully, but I don't agree the PID is setup properly. Having a trigger timer is good, but I am not sure about having the second trigger, how would you match the PID Update Time? It is critical that these match.

No offense taken:D, I didn't make myself clear on that point, Ron had mentioned it could cause issues and I didn't enforce a second stance on that. The other fundamentals should be ok, not necessarily "ideal".

As far as matching the trigger time to the update time I agree that this is critical, but that can be achieved with a simple move of the trigger timer preset/period task preset directly into the loop update of the PID. In the OP's example they are hardcoded to match, again not "ideal" but for the sake of troubleshooting should be ok.

My intention was to determine if other factors outside the PID could be inflencing the system response, such as an extremely long accel/deccl setting in a VFD. I'm interested in knowing where this 3min lag is coming from.
 
Last edited:
This sounds like a dead time problem

It is always good to check the PID but I think the main problem is the dead time. No one has asked about the conveyor and how the infeed is controlled. Is the infeed controlled by controlling the speed of the conveyor or the density of the product on the conveyor. This makes a BIG difference. It sounds like the infeed controlls the density of material and the conveyor moves at a constant rate.
 
No offense taken:D, I didn't make myself clear on that point, Ron had mentioned it could cause issues and I didn't enforce a second stance on that. The other fundamentals should be ok, not necessarily "ideal".

As far as matching the trigger time to the update time I agree that this is critical, but that can be achieved with a simple move of the trigger timer preset/period task preset directly into the loop update of the PID. In the OP's example they are hardcoded to match, again not "ideal" but for the sake of troubleshooting should be ok.

My intention was to determine if other factors outside the PID could be inflencing the system response, such as an extremely long accel/deccl setting in a VFD. I'm interested in knowing where this 3min lag is coming from.

I am glad we are on the same page.:site: I do something similar with the Trigger Timer, except I multiply the PID Update Time by 1000, and move it into the Trigger Timer Preset. I find it more convenient to change it in the PID Setup Dialogue. Both achieve the same result.

I agree on the 3 minute lag and outside factors, it is hard to know with the limited details. How about it JE, can you give us more specifics about the delivery system, and why there is a 3 minute to 30 minute lag?

Stu.......
 
Last edited:
Hey guys, thanks for all the responses!

Yes, the conveyor runs at a constant speed. There is a rotary feeder that controls the amount of product per unit time (I guess you could call that density) that is fed onto the conveyor and eventually into the mill. The speed of this feeder is the control variable in the PID loop.

The 3 minute lag is what I've been told, that apparently how long the product takes to get from the feeder through the conveyor system to the mill.

The 30 minute time refers to the amount of time the mill can take to get to the proper level. For example, say the pressure is 12 inches of water and the desired setpoint is changed from 12 to 15. To accomplish this change in manual operation, they would normally increase the feed rate (say from 25% to 40%). Then once the desired level of 15 is reached, the speed must be decreased again.

I plan to try this loop again today, taking out the extra trigger so that the loop runs at a constant time. And I will probably try and increase the loop update interval considerably. I want to make sure I am understanding this correctly though. If I make my PID rung go true every x seconds, I also have to change the "loop update time" parameter in my PID setup to match that interval?
 

Similar Topics

Hi all, I'm working on a wastewater plant with oxidation ditch aerators. The aerators are on VFDs and the operators want the dissolved oxygen in...
Replies
45
Views
17,412
Hello, I have a issue with tuning a slow acting PID loop using AB PIDE instruction. The system is designed to cool a tank after it heats up...
Replies
141
Views
102,059
Hello all, I have set up a PID loop which works fine except it is a bit slow during the startup. I wish that it would reach near the setpoint...
Replies
1
Views
1,801
Hi friends I have a L24ER-QBFC1B in a Level Control that you can see in the picture. Tank1 is the process tank. Level sensor is the process...
Replies
4
Views
3,025
Hey guys, I have a Controllogix and I am tying to control a PID loop for Chlorine (CL2). The trouble is the mixing point is 15 minutes away from...
Replies
16
Views
6,716
Back
Top Bottom