PID Help

ben

Member
Join Date
Jun 2002
Posts
37
I have been reading the other PID post at this time with great interest.

We are controlling a furnace which we need to maintain a temperature.(mA signal in). We vary the oil (mA out) to alter the temp. The furnace is subject to huge changes in temperature as the heat is removed. The old PID coped with this quite well.

I have a PID using Control Logix 5000 in ladder. I have reduced the P and I to very small quantities P=0.1 I=0.01 D=0 however I then get a much reduced response as predicted by Peter N. At least the process is running though! I have tried larger values of P upto=0.6 and this results in ossilations. Any larger figures and we get full scale out on the controller output! Scary.
My loop update time is one second. (I notice that I cannot change this on-line?)
I get a large overshoot on start up and over a period of time the ossilations iron them selves out to almost satisfactory conditions. Still not as good as the old controller though....Is this progress?

My problem is that the output only starts to reduce when the setpoint is reached, which then results in some overshoot? We need a tighter control and when the setpoint is approached the output backs off, if you see what I mean.

If anyone could give me some input I would be greatful. Should I increase my loop time?

Oh before you ask, we have removed a panel mounted 20yr old PID controller so we only have the settings from this to go off.

Thanks

Ben
 
The reason you are getting overshot is that you have no derivative value entered. Typically, PI control is used for flow, and full PID is used for temperature applications.

Are you using dependent or independent configuration?
What is the process lag time? (time from CV change to 63% PV change)
What is the process dead time? (time from CV change to PV change)
What is the process gain? (total PV change divided by CV change)
Do you know for sure that there is no hysteresis in the control valve? In other words, that it isn't sticky?

You CAN change the loop update time in run mode. What makes you think that you can't?

I use some simple rules of thumb for processes that are not too complicated, and sometimes more complex methods if there are response issues, variable loads, etc. etc. I usually use the simple method first, and in most cases that works without too much re-tuning.

Let us know what some of your variables are.
 
Yo, Ben,

Let me guess - you have 1.00 second entered inside the PID for the “loop update time” setting. But - I’m going out on a limb here - the PID rung is unconditional. In other words, you have no way of telling the PID how often to execute - other than how often the PID rung actually gets scanned.

If this is your situation, then try this. Set up a timer. Have its done bit come on once each second. Use this done bit to condition the PID rung. See if that doesn’t help. It probably will - but it may not. If it doesn’t help, then you’ll have to work on how often the ladder file is being scheduled for scanning.

Notice: I’m not telling you to “slow down” the PID. Just to schedule it so that the period between successive executions matches the loop update time inside the PID math equation. Basic idea: Read the “paycheck” analogy in the other thread and post any specific questions you might have.

Note: To all. This probably confuses SLC people more than others. In that platform, you CAN put your PID on an unconditional rung - and then select the “Timed Mode = TIMED” setting. The PID will then automatically be scheduled at whatever time you have entered for “Loop Update”. But Ben is not working with an SLC. He has to schedule his PID’s operation externally - by using something along the lines of a timer done bit.
 
Ron Beaufort said:
In that platform [SLC], you CAN put your PID on an unconditional rung - and then select the “Timed Mode = TIMED” setting.

Isn't it that "you MUST put your PID on an uncondtional rung...."

From the AB knowledgebase (Doc G15748)
"Ideally the rung condition should be unconditional. If the rung condition is toggled, the RATE and RESET terms are zeroed out. This is typically undesirable. "


Again that's for SLCs, not ControlLogix
 
From your description, and that you're replacing a stand-alone controller, I'm guessing that you are using the ISA (dependent gains) algorithm. In that case, your "small" I value of 0.01 has a huge effect. The units are minutes per repeat. 0.01 minute = 600 msec. This means that the output is bumped every 600 msec by an amount determined by error and controller gain (P value).

My suggestions to get you headed in the right direction:
  • set the update rate to be faster than the max rate of change of the PV
  • ensure that the PID is executed at the same rate
  • set the integral & derivative terms to zero (disabled)
  • place a fixed bias on the the CV of 50% (.BIAS in your PID tag)
  • set the P gain to 1
The above should be very sluggish and require significant error to change the CV. Increase the P gain until you get close to the characteristics you desire.
I have found this setup to be perfectly adequate for many temperature applications. Use output limiting to prevent melt-down on startup if necessary.
If you decide to add integral, remove the fixed output bias. The function of the integral term is to provide automatically adjusted output bias in order to minimise the steady state error that you would otherwise have with proportional-only control.
 
If you want your system to work...

Dennisb is right about using the D term.

I don't agree with what Gerry said about the BIAS. The BIAS is one of the most overlooked term and not using it properly is a BIG handicap.

If I were tuning Ben's system, I would watch it operate and notice the relationship between CV and PV. From this I would build a look up table or formula of CV as a function of PV. This is my system model. The is easy using MathCad. I then would use the SP to index into this table to get an estimate of what the CV will be. This estimated CV value is used as the BIAS. My guess for the BIAS should get with 5 percent ( my mathcad models get much closer if the system is linear ) of the correct value of the actual CV for that SP. I then would let the PID do the final 5% that takes care of changes in load and non-linearities. Notice that if the BIAS term is now doing most of the work (95%) and will respond very quickly and the PID terms can be kept quite low so that it will not oscillate. This will also reduce the error by 95%.

Finally, one must be very careful when changing the SP in step jumps from one value to the other. The PID shoud use the PV for both the proportional and the differential terms if the SP makes step jumps in values. If your PID will not allow othe use of the PV for both the proportional and the differential terms then don't let the SP make step jumps. To get around this one should gently ramp the SP from the current to the final value in a similar way as a motion control would ramp from one position to another. This ramp can be done using a simple expontial ramp where

SP = Final SP * T / ( t + T ) + SP * t / ( t * T )

where t is the sample period and T is the time constant of the system.
Remember that it take 5 time constants for the PV to get with %1 of the SP.

If the system has a dead time then the SP must also be delayed by using a fifo that can delay the SP by the dead time.

The problem with PIDs is that they are only a part of the answer for doing proper control. A proper system model setting the BIAS and delaying the SP by the dead time will make a BIG difference.

If you read between the lines you will see that I am a big believer in openloop system models. NOT PIDs.

Why?

The CV comes from 4 terms: P I D and Bias.
The P I and D terms all require error to contribute to the CV.
The BIAS term does not. If I want a system that minimizes the |SP-PV| then I must make my model better so that is can exactly predict the CV for any PV. This is impossible, but I can come close and in the process, greatly increase response and accuracy.

When the user changes the SP from one value to the other do you really think the system can change its PV instantly? This is clearly impossible so why do it? Ramp the SP at rates no faster than the PV can change so the integrator does not wind up.

Now you all can be heros.
 
I stand corrected

Reply to Allen's post #4 - you're absolutely right, I should have said "you MUST put your PID on an unconditional rung" when using an SLC controller. When I was writing that part, I was thinking: " ... with the PLC you CAN'T - but with the SLC you CAN". I agree - it would have been much more precise if I had chosen the word "must" instead. As written, the statement affirms that "you CAN" - which, in English, rather implies "but you don't necessarily HAVE to". Well, if you don't, then when the processor scans the rung as false, the integral and derivative contributions to the Control Variable will "zero" out. Off the top of my head, I can't come up with any application where that would be desirable.

Thanks for keeping me honest.
 
Hi Ben,

Here is some sample code i learn't on rslogix course for pid sampling.

sampling Time > 100ms

-------|/|--------------Ton

-------| |--------------Btr

-------| |--------------Pid
Ton.Dn

-------| |--------------Btw


Sampling Time < 100 ms use STI

-------| |--------------Btr

-------| |--------------Pid

-------| |--------------Btw

The second rung should give you better sampling readings updating you output (P) quicker.

Or am i talking Sh*%e.????????
 
"asynchronous" - I don't like the sound of that -

Greetings, garryt1,

It looks like some of your addressing text “came loose” on the rungs you posted - but I still think I’ve got the general ideas. May I offer a few thoughts on your top set of rungs? It seems that you’re trying to synchronize a chain of events for “PID sampling” in a PLC-5.

Basic idea: A timer keeps track of elapsed time - whenever the timer gets done, we use the timer’s Done bit to trigger three steps in sequence on the following rungs.

(1) execute a BTR (Block Transfer Read) to bring in new analog data from the field.

(2) execute a PID (Proportional, Integral, Derivative) to calculate a new “control” value.

(3) execute a BTW (Block Transfer Write) to send our new analog data out to the field.

You’re not the first to have been bitten by this - but there is a fundamental problem with your approach. The dirty word for today is “asynchronous” - which is used to describe the operation of the Block Transfer instructions in the PLC-5 processors. (You lucky SLC readers don’t have to worry about this issue for your analog signals.) It turns out that just “triggering” the Block Transfers with the timer’s done bit (as I think you’re showing in your top set of rungs) will NOT necessarily guarantee that your PID will always be operating on fresh “new” data from the field. Putting the rungs in this 1-2-3 order seems to be a good idea on the surface - but there’s a lot more to it than this. Let’s look at the Block Transfer Read for a minute. The same concepts apply to the Block Transfer Write also.

The sad truth is, when the processor scans the BTR with true logic, the actual execution of the BTR is not NECESSARILY going to happen BEFORE the scan continues on to the next rung. Think about this: We’re literally talking about TRANSFERRING a big BLOCK of data. Actually accomplishing that transfer of data might conceivably take up a considerable amount of time - time which would tend to slow down our processor as he tries to continue scanning the ladder logic program. And so - in the PLC-5 family - the processor puts this “request” for a transfer of a block of data into a “queue” or a “buffer” - or in other words, into a line-up of “communication-type” requests. These requests will then be accomplished as soon as practical by a “communications handler” inside the processor - but NOT necessarily before the scan moves on to the next rung.

So the big question is: Will the “new” data from the analog input module arrive at the Process Variable location in time? “In time” meaning, of course, BEFORE the PID “picks up” the value from the Process Variable location and starts to work his mathematical magic on it. And the sad truth is: “We simply don’t know for sure.” Now in a relatively short program with very few “communications” type operations going on, the approach you’ve shown will undoubtedly give satisfactory results. For most student exercises it’s ideal. On the other hand, once we’re out in the field and begin to burden our processor with more and more communication operations, then the “asynchronous” nature of the Block Transfers starts to rear its ugly head. The actual word “asynchronous” comes from the Greek and, by definition, carries the meaning “not sequenced together in accordance with time”. Which sort of nails down the basic idea that your top set of rungs might not work precisely as you’d been led to believe.

And incidentally, before I started writing this post, I did a search on this forum for the word “asynchronous” and didn’t find even one mention of it. If it’s there and I missed it, someone please post a link to its location. Surely this can’t be the first time this particular topic has come up? But back to our story ...

In reality - how bad is this asynchronous execution “problem” anyway? Well, the good news is, in practice you’d probably never even know that your PID wasn’t getting fresh “new” data before each execution anyway - not unless some picky nut like me comes along and points it out. Think about it - how long has it been since the last time the data came in? - usually it’s only a fraction of a second ago. So how big a change would we expect to see in the actual values of the input data? Answer: Not very much. So in actual practice, the fact that the PID’s input data is just a “little bit” stale - doesn’t usually adversely affect the operation of the system at all. “So what?” - if the PID is reading yesterday’s mail and he happens to be a fraction of a second behind the times? Who cares? Only people like me (who actually enjoy these types of details) - and once in awhile a technician with a long interval for his “trigger” timer - and who goes crazy just trying to figure out why his 1-2-3 “get data in - do PID - send data out” chain-of-events sequence acts sort of “fishy” once in a while.

So in actual practice, most programmers just set up their BTR’s and BTW’s to execute “as often as possible” and get on with their lives. Still there ARE ways to sequence these types of things - but it’s a lot more involved than the “timer done bit” approach in your post. In case you or anyone else desires more information about this topic, see Chapter 15 in:

the PLC-5 Instruction Set Reference Manual

This book gives quite a few programming examples which might help you actually “sequence” your Block Transfers - and “buffer” your analog input and output data - if you feel the irresistible urge to do so.

Sorry - but the “timer done” bit approach in your top set of rungs is not really a “fail-safe” sequencing technique - but I’ll agree - it is a relatively popular one and a LOT of programmers use it successfully in the field. Thanks for the opportunity to bring this topic up for discussion.

Incidentally, using the STI approach as in your second example brings up additional issues. You may find information on this topic in:

the PLC-5 User’s Manual

A good place to start reading is on Adobe page 239 of 350.
 
Info as req:

Pid Equation- Independant
Control Action- SP-PV
Derivitave off-PV
Loop update time 1.0s (I have found can change this value. Why I couldn't before?? I don't know?)

CV Hi 100%
CV Lo 0%
Deadband 0.0%

We are now running off a P of 5, I of zero, and a D of zero. With not bad results! Its still not right though.

Thanks for the help I will try some of your suggestions and keep you posted.

Ben
 
PID help

Now I notice that my bais is set at 50%. Would this explain why the controller was working in a sort of fashion at P=5 and I/D set to zero?

Ben
 
Sounds like you followed my suggestion.

The 50% starting point for the bias is simply a guess at how much burner output is required to maintain temperature at normal loading. It also assumes that the burner is not grossly under or over sized for the job.

With proportional-only control, you must have an error in order to produce a control output. As we both know, zero output from the burner will not maintain temperature, hence the bias. With this setup, increasing the P gain directly affects the error sensitivity of the system and you can easily calculate how much error will drive the output up or down by 50% which, when combined with the bias, gives 0-100% output.

If the furnace loading is fairly consistent, then fixed bias may be all you need (don't be shy about tweaking that 50% figure up or down to suit).

If loading varies, you'll want to look at adding integral action to the control. I recommend using the dependent gains algorithm since this is what most instrument tech's understand and it also emulates the operation of analogue controllers. The object of the integral term is to reduce the steady-state error inherent in the proportional-only setup by applying "reset" to the output. This "reset" is affected by the size of the error, the P gain, and the "reset" time (minutes/repeat), and should replace the need for a fixed bias. It is, effectively, an automatically adjusted bias.

So, you say the results were "not bad" and it's working "after a fashion". What symptoms are being exhibited?
 
so how about that "timing" issue?

Ben,

I may well be barking up the wrong tree - but did you take care of the PID's "execution scheduling" issues which I mentioned in my post #3? I notice that so far you're only using Proportional control - and that you've added some Bias. Note that NEITHER of these two components will be affected by how often the PID gets executed. On the other hand, the Integral ...

If the PID is being executed on an "each and every scan" schedule, then the Integral action will be GREATLY increased. If this "execution scheduling" issue is your problem, then you would see the following results: As soon as you add "just a little bit" of Integral, then the Control Variable will "run away" and QUICKLY go to the full on position. Does that sound familiar?

Now I'm perfectly willing to admit that "execution scheduling" MIGHT NOT have anything to do with your problem. But you still haven't posted anything which would allow us to rule it out as the possible (probable?) culprit. Keep in mind that using a timer done bit as a "trigger" is not the only method available to control the "execution scheduling" - but SOMETHING'S got to take care of this issue if you want to make use of the Integral and Derivative actions. Simply put: The Integral and Derivative actions are (by definition) highly dependent upon timing.

Finally,

(1) ONCE the timing issues are taken care of -

(2) AND you select the correct equation (Independent Gains or Dependent Gains) to match the "old controller's" action (just a guess from where I sit - but probably Dependent Gains is correct)

(3) AND assuming that nothing in the system hardware (valves, sensors, etc.) - has been changed

(4) THEN you should be able to simply plug in the "old controller's" tuning values and end up very close (if not exactly) where you were before you started with the ControlLogix upgrade.

But if the "execution scheduling" IS still an issue then you're going to have an extremely hard (if not impossible) task in tuning the PID. So how about that timer thing I mentioned in post #3? Did you already have it? - or did you add it? - or is something else taking care of your PID "execution schedule"? - and if it's something else, what is it, and are you sure that you have it set for once per second - to match your PID’s “loop update time” setting?
 
Thanks Gerry I will try changing the gain to dependant tomorrow and see what happens.

The symptoms that I am getting are: The PID output is copying the process value very accurately. Almost like you could put a mirror on the trend and it would show a true reflection. It is inverse. The process value is somewhat under the controller setpoint 10C to 20C (However we can live with this for the moment.) I would have expected the PV to cross the setpoint through normal running? As the PID tries to maintain the setpoint. Am I making sense? Perhaps as you say I will try increasing my bias to get the PV nearer to the SP. I will try this also and let you know.

Ron,

I think the timing issues are ok
I will try dependant gains
The valves are the same

So the plan is.....

Use dependant gains.
Put the bias to zero.
Increase the P and I steadily....what about the D then?
 
stuck record - stuck record - stuck record

Ben,

You said that you “think” that the timing issues are OK - and quite probably they are. But would you like a simple test to absolutely confirm that they are? Place a branch right under the PID - do NOT add a new rung - just a branch. On that branch place an ADD instruction.

Set up “Source A” to be a new DINT location (example: count_executions)

Set up “Source B” to be the constant value 1

Set up “Destination” to be the same DINT location that you used for “Source A” (example: count_executions)

[attachment]

Basically, this is just a counter. Since it’s located right in parallel with the PID, then every time that the PID gets executed - then the value of count_executions will go up by one.

If your PID timing issues are truly OK, then what you should see is the value of count_executions increase by 1 every second - just like a seconds reading on a digital clock - and it should keep perfect time. This "add 1 per second increase" should match the 1.0 second value that you posted for your "Loop Update Time" entry.

If your PID timing issues are NOT OK, then what you will see is the value of count_executions increase at some OTHER rate. My gut instinct is that count_executions is going to “run like a striped ape” - and increase much faster than your mortal eye can follow.

I’d really like to see you run this test, Ben. I really and truly would. Then I could quit worrying about those silly timing issues. I’m probably wrong - but I just can’t seem to get them out of my mind. Please run the test, Ben. Please. If you’ll just run this one little test for me, I promise - I won’t ever nag you about the timing issues again. I promise.

Final note: I’ve seen this happen to guys in the field - several times. If this IS your problem - then it needs to be fixed BEFORE you try to tune the loop. Think of it as a “calibration” thing - it’s VERY important or I wouldn’t keep bringing it up.

ben pid.jpg
 
Last edited:

Similar Topics

Hello all, I have an issue with a PID block in RsLogix 5000. The parameters are P: 3.25 I: 0.11 D: 0.01 The Set Point is 71 psi This loop...
Replies
63
Views
14,664
hey guys - I'm a novice PLC enthusiast, so this may be a simple one. I'm running a PID on a Micrologix 1200 PLC and I want to change the Gain for...
Replies
18
Views
4,216
I need a little help with a project I have been thinking about. We have a belt line that is fed by a gravity door (pretty much a hydraulic...
Replies
14
Views
2,682
Hi all, I have a request from client as follows, There's one PID for Control valve which would be controlling on basis of temperature. One...
Replies
1
Views
1,502
Hi, I am trying to automatically regulate a process ( liquid ) in a tube using an ultrasonic sensor, differential level meter, control valve...
Replies
3
Views
3,073
Back
Top Bottom