what is "I" in pid ?

Hello Ron,

I have tried to post the .rsp file but it is still to large even zipped. Can I email you the file? PM me with your email address and I will send it to you.

As for the trend I do have one set up already. I am using wonderware for my HMI screens. I have on there a trend of my actual and averaged draft reading. I will get a picture of the trend for you to show you how it looks right now. I will try to get this posted soon.

Now on to the update time. You are correct, there is no trigger on the pid block. Needing a trigger (on a PLC-5 system), is something that I just learned by reading these posts. I guess the guy that set these up before me didnt know that you needed triggers either. All of my pids on my system were set up without triggers. This is something that I need to change.

For the update time, reset time, and derivative values, are these all in seconds or milliseconds?? I thought that I read a post saying that these were in ms. Maybe I had it confused with a different type of system.
For the proportional gain and the integral/reset settings. I think theses setting are way off. After reading your post on how the integral setting works I asked myself the same question as you. How is this even working? It is very slow reacting (actually too slow)but it does for the most part work. Im think you are right that it has alot to do with the update time and not having a trigger on the pid.

I would like to get this fan reacting alot faster that it is right now but I cannot have it overshooting the sp or oscillating around the setpoint. This would cause instabillity on the flame in the kiln. I guess that is why I was asking about the derivative, and how it works. Even if I would not need this value on this particular pid I would still really apriciate you describing it to me.

This particular pid loop I have been working on and trying to fix for a long time. Thank you again for all the help on this.

Hello Ron,

Looks like I took to long on my last post cause it put me down as a guest. Anyways here is the draft trend that you asked me about. The draft that we are looking at is the "hood pressure inst". It is in the yellow, the average that I am doing is in green.

Thanks, Joel

Greetings Joel,

I have tried to post the .rsp file but it is still to large even zipped. Can I email you the file? PM me with your email address and I will send it to you.

Click to expand...

let me check with my boss ... he allows (actually encourages) me to hang out on the forum ... but he does NOT allow me to post my e-mail, phone number, etc. ... but I’ll ask him this afternoon ... maybe he’ll make an exception just this once ...

I will get a picture of the trend ... posted soon.

Click to expand...

excellent ... that should help a lot ...

Now on to the update time. You are correct, there is no trigger on the pid block. Needing a trigger (on a PLC-5 system), is something that I just learned by reading these posts.

Click to expand...

just a tip for future reference when working with PID on the PLC-5 platform ... with the “N-type” (integer) PID control block, the PID will not function without some type of “trigger” event to “toggle” the rung status between true and false ... so it’s hard to leave out the “trigger” with those systems ... but with the newer “PD-type” control block (like your system is using) the PID WILL execute each time the rung is scanned – even without the “toggling” action ... the guys who make the most mistakes with this are the ones who have more experience with the SLC-500 systems ... in those the PID rung should always be unconditional ... specifically, the “trigger” action is “built-in” to the PID ... guys that are familiar with that type of setup are quite prone to leaving their PID rungs unconditional when they move over to the PLC-5 platform ...

I guess the guy that set these up before me didnt know that you needed triggers either. All of my pids on my system were set up without triggers. This is something that I need to change.

Click to expand...

trust me, this is NOT a rare occurrence ... I’d estimate that at least 50% of the PIDs that I’ve seen being used in the field have been set up incorrectly ... the correlation between the “trigger” and the “Update Time” setting is one extremely common issue ... I’ve got a strong feeling that at least 90% of the guys who complain about the “perils and pitfalls” of PID control never gave the poor thing a fighting chance ... if you don’t set it up right, how can you expect it to work? ...

For the update time, reset time, and derivative values, are these all in seconds or milliseconds??

Click to expand...

look carefully at the PID configuration screen which you posted above ... the units are clearly shown right next to the entry fields ...

the “Update Time” is in seconds ... (example: an entry of “100” means that the PID’s internal math calculations will be based on an external “trigger” event which is expected to occur every “100 seconds”) ...

the “Reset Time” (the Integral setting) is in “minutes per repeat” ... (example: a entry of “400” means that the PID’s Integral action will require “400 minutes” in order to “repeat” the response obtained from the Proportional action) ...

the “Derivative Rate” (the Derivative setting) is in minutes ... I’ll discuss what this means in my upcoming post on the Derivative action ... stay tuned ...

For the proportional gain and the integral/reset settings. I think theses setting are way off. After reading your post on how the integral setting works I asked myself the same question as you. How is this even working?

Click to expand...

it works because the Integral setting is being COMPENSATED for (at least to some degree) by the “much-too-frequent” triggering of your unconditional PID rung ... basic analogy: I’m only going to pay you $1.00 per hour (rather than the $10.00 per hour that you’re expecting) – but don’t worry about it ... I’ll pay you for “400 hours of work” this week instead of the “40 hours” which you actually put in ... you still get the expected $400 paycheck ... but it’s a weird way to keep the books isn’t it? ... (this has “Enron” written all over it) ...

I would like to get this fan reacting alot faster that it is right now but I cannot have it overshooting the sp or oscillating around the setpoint. This would cause instabillity on the flame in the kiln.

Click to expand...

we’ll do what we can ... but one of the first steps is to straighten out the issues in your PID setups ...

I guess that is why I was asking about the derivative, and how it works. Even if I would not need this value on this particular pid I would still really apriciate you describing it to me.

Click to expand...

I’ll do my best to describe it just as soon as I can find the time to do it justice ... in the meantime, my advice is that adding in some Derivative to your system would only make matters MUCH worse until those PID setup issues are corrected ... even then, your process might not be a good candidate for Derivative action ... some processes (particularly ones which have a “noisy” input) simply “go nuts” when Derivative is applied ... let’s take a good luck at that trend you’re going to post and see if that gives us any indications of what to expect down the road ...

This particular pid loop I have been working on and trying to fix for a long time. Thank you again for all the help on this.

Click to expand...

and I thank you - for the opportunity to be of service ...

PS edit ... I see that you’ve made another post while I was pulling this together ... I’ll try to open it right after lunch ...

plus a hint: try writing your future posts (especially the long ones) in Microsoft Word, etc. ... then “Select All” and “Paste” the text into the forum’s “reply” box ... it’s usually easier to work with Word (especially if you’re used to it) and you can use the spell checker feature too ...

Greetings Joel,

I’ve just had time to take a quick look at the trend you posted ... I have a question for you ... does this trend show the PID’s output (CV) and if so, which trace is it? ...

I’m betting that your answer is going to be “no” ... if so, is there any chance that you could set up a new trend in RSLogix5? ... that would give us a lot more flexibility as we go forward with this project ...

and incidentally, since your trend shows a significant amount of “jitter” on the draft signal, it’s beginning to look like adding some Derivative into this stew might not be such a good idea ... that’s just a first impression ... we’ll see as we go along ...

Hey Ron,

No the trend does not show the cv. I will get a trend made up with the cv, and the draft on it.

Also is it a good thing to run a pid off of the average of a number? By doing this wont the fan always be playing catch up because of the few seconds behind the average is? Just a thought that I had....

Greetings Joel,

I got the .RSP file that you e-mailed and was able to open it with no problems ... it is as we suspected ... your PIDs have many “issues” ... if you want to continue, we’ll keep right on working on this problem step by step ... the trend that you’re going to post soon should help a lot ... suggestion: make sure that the trend (or at least one trend of a set) shows the fan’s PV response to a “fixed” CV ... specifically, put the PID in the manual mode and force it to put out a completely stable (unchanging) output ... then graph the response ... that will tell us whether all of the noise that we’re seeing on your input is coming from plain old everyday “signal” noise ... or whether some of the noise is the result of your PID’s erratic control of the output ... best possible news: the STABLE output will give us a STABLE input ... but if the input is still erratic in spite of a completely STABLE output, then the “signal noise” issue might have to be dealt with before we try to tune the PID loop ...

and incidentally ... one (trivial) thing that I want to mention ... in post #27 you said:

I am running RSLogix 5 version 3.21, and have an AB 5/20 processor.

Click to expand...

take a look under “Controller Properties” ... you actually have a (larger) PLC-5/40 processor – not a PLC-5/20 ... I think that the confusion might be coming from your processor’s assigned “name” which is set for “PLC20” ... this was probably done by the original programmer in reference to the PLC’s “node address” on the DH+ network ... this is set for node number “20” on your processor ... this minor discrepancy will probably have no effect on the issues that we’re working on, but it does point out how the details of the system can sometimes get lost in the shuffle while working through a forum like this ... even an excellent forum such as Phil’s ...

I’ll try to nail down the rather complicated “averaging” that your system uses for the fan PID’s input signal ... looking forward to the trends ...

be careful what you ask for ...

Greetings Joel,

it's been awhile since we've heard from you ... maybe (hopefully) you've already sorted out all of your PID problems ... I just wanted to let you know that the information you requested on the PID's Derivative action is now available in a new thread: What is D in PID? ... since it turned out to be such a long subject to cover, I took the liberty of starting a new thread for it ...

note that even though your system uses the newer PD-type control blocks, I decided to use the older N-type (integer) control blocks for the examples ... this will make the information more applicable to other readers who use the SLC and MicroLogix platforms ... in spite of the different control blocks, you should have little or no trouble following the examples ... but if you have questions, I'll be glad to try to answer them ...

Excelent!

Explanation about how the PID works is very good. it helps me a lot.

thanks

you're welcome ... it's nice to know that something I wrote 11 years ago is still being helpful ...

welcome to the forum - and good luck with your project ...

warning! ... please remember that we’re basing this discussion on an Allen-Bradley controller using the “ISA” or “Dependent Gains” equation ... the “bigger-number-means-less-action” and “smaller-number-means-more-action” rule that we just nailed down is BACKWARDS if you use the “AB” or “Independent Gains” type of equation ... further, the Integral units in that equation are based on “repeats per minute” rather than “minutes per repeat” ... if you need help with this issue, please post again ... believe it or not, I’m trying to keep this current discussion as simple as possible ...

Click to expand...

Just making sure I understand, cause I use mostly Modicon PIDs that use repeats/min.

If I wanted to duplicate you're picture example, I would need to use .5 repeats/min in order to duplicate the "2" line and a .25 value to duplicate the "4" line......Correct?

Ken Moore said:

Whenever I try to explain PID loops to the maintenance guys, I tell them this.

P= how far off am I
I= how long have I been here
D= how fast am I going


For some reason that seems to work best with them.


Ken

Click to expand...

I am also going to steal this.
I usually just end up telling them proportional is the easiest/safest to adjust, integral is slightly more complicated, and derivative will really make things crazy in a hurry.

rankhornjp said:

Just making sure I understand, cause I use mostly Modicon PIDs that use repeats/min.

If I wanted to duplicate you're picture example, I would need to use .5 repeats/min in order to duplicate the "2" line and a .25 value to duplicate the "4" line......Correct?

Click to expand...

??

Good thread, I'm sure I read this years ago and wanted to contribute. The examples are from a thread I created years ago, and the data is pretty good so I am using it for the example.

My original thread is here.

Here is a chart of my proocess, this was a heating process. Lets focus the step change occurring at 9:50 AM. Note the YELLOW line is the setpoint, the Purple is the process value and the blue is the controller output.


http://postimage.org/

Lets zoom in on this:
[url=http://postimage.org/]
http://postimage.org/[/URL]

Integration is a part of Calculus, and I'm surprised nobody has really just talked about the goal of integration. So I'll attempt to provide a background on integration from a Calculus stand point. Now, I'm not going to perform any Calculus, just better explain the concepts. I think it helps to understand the origins so you can better apply it to the real world.

Integration is really just the 'area under the curve'. It's an area calculation, just as if you were to calculate the area of a rectangle using the formula A = w x h. A formula exists to find the 'area under the curve' however it's not obvious because we don't have a nicely defined function. Regardless, just remember integration = 'area under the curve'. The next image demonstrates this. I've added endpoints to illustrate what I am interested in. T0 and T1. Now, this must happen over a period of TIME because I don't have a formula for this curve. There is history behind it, we are looking at what occurred in the past to help correct what will happen in the future. For some period of TIME, I want to calculate the area under the curve from T0 to T1, I've highlighted this in Brown:

http://postimage.org/

Well, over that period of time, it's clear that I have an area > 0. So this indicates that we are not at setpoint over that period. If the calculated result was equal to 0, then over that period of time we must have been at setpoint. So the goal of the 'I' in a PID loop is to SQUASH this area, if there is a calculated area, it needs to be squashed to 0 in order to get to setpoint.

As our PID loop processes, we see another 'area under the curve' we can look at. Now we are looking at T1 to T2. Without any math, we can make the observation that infact, the process is trying to squash the 'area under the curve'. Clearly there is less area, but we are still > than 0 so we are not at setpoint (forgive me, the area under the black line to the curve should be brown as well...MSPaint!) BUT, it seems our tuning values are working for this process:

http://postimage.org/

Looking at T2 to T3, it's squashing the area further, and it should be clear by the picture that eventually it's squashed to 0 and we have good control:

http://postimage.org/

So the 'I' term = SQUASH the 'area under the curve'.

I won't go into it too deep, but the 'D' is also a calculus function, the Derivative is the 'instantaneous rate of change'. By understanding the rate of change, we can start to predict the future. If we are at a high rate of change, and really close to our setpoint, well it will lead to an overshoot. So the 'D' will try to influence the CV by reducing this rate of change as it gets close to setpoint, like seeing a stop sign in the distance. You know you're approaching very fast, but you need to stop the car by applying brakes at some point, and mentally you are judging the distance and your current speed to determine when and how much to apply the brakes because you know at some point in the future you have to apply the breaks.

Here is an example, I have 2 points and you can see that at the instant of either of those 2 points, I drew a tangent line to the curve. The slope of this line is the rate of change. In this example, I am not using the 'D' term at all. I'm only using 'PI' to achieve my setpoint. Because I have a high rate of change as I approach the setpoint, I have an obvious over-shoot. So using the 'D' term, I could try to give the control some predictability and attempt to reduce this overshoot as it approaches the setpoint. By trying to reduce the rate of change as it approaches the setpoint, it should lead to a smaller over-shoot. Introducing the 'D' term can make things tricky in tuning, so I stay away from it unless the process really really needs tight control. Most of my process don't need this.

http://postimage.org/

Obviously there is more detail, which others have already covered but that is how I explain it to maintenance staff, and new engineers. I relate it to calculus concepts and I just draw a chart similar to this and point out the 'P', the current error from setpoint to a point on the curve, the 'I' as the area under the curve, and the 'D' as rate of change. Having this visual really clicks for most people, and even if they don't understand the calculus behind it, they have a baseline reference for trusting the concept.

Why does your control signal initial change in the wrong direction? It makes the PV initially go the wrong way?
You say you aren't using the derivative but it looks like what is called "the derivative kick"

Peter Nachtwey said:

Why does your control signal initial change in the wrong direction? It makes the PV initially go the wrong way?
You say you aren't using the derivative but it looks like what is called "the derivative kick"

Click to expand...

This was an exercise from 7 years ago now, I don't remember the characteristics of system and and no longer have the code. It was also my first attempt at correcting poor PID loop control logic in a ControlLogix. I wouldn't be surprised if there was something residual in the PID configuration that would cause that and I just missed it at the time due to being a rookie. The OEM clearly didn't know how to write PID logic correctly.

At the time you approved

Peter Nachtwey said:

Paully's5.0, you have done extremely well for a first attempt.

Click to expand...