Faster response in PID RDLogix 500

realolman

Member
Join Date
Mar 2009
Location
here
Posts
584
I have been trying to "tune" a PID loop ( several actually) with little success.
I think the physical system may have insurmountable issues, BUT...

It seems to me that the Control value does not begin to react until the process value is so close to the setpoint that it is already too late. I would like to see the control variable begin to change as soon as the process variable begins to change.

I have empirically changed and watched the system while changing the proportion, the integral, and the derivative. I can get a marginal improvement but nothing definitive.

what things might cause the control variable to begin to change before the process variable gets so close to setpoint. Proportional and integral seem to cause the change to be larger but don't seem to start it sooner.

Also I don't understand exactly what the integral and derivative settings mean . the larger the number means what? ...a larger amount of time? ...and the loop rate?

I have been reading a number of things but they don't seem to be easily relatable to the allen bradley PID and I can't find any good material for the allen bradley.

I am not understanding the "help" too well.

thanks for your help
 
Last edited:
The derivative is what you are looking at to "anticipate" into the future. There are hoards of information covering this on this site. Look in particular at some threads Ron Beufort created on the topic.
 
yes, I have already tried to answer most of the questions that you've just asked right here on the forum ... but you'll probably find it much easier to access the information by downloading it from my website - in handy PDF form ... just click the link under my signature (below) and go to the Sample Lessons and Video page ... scroll down past the videos and you'll find:

"What Is P?"
"What Is I?"
"What Is D?"

these were written from a non-engineering viewpoint to explain the concepts that you've mentioned ...

then ...

if you're still having trouble, I suggest that you post your ENTIRE program file (RSS) so that we can take a look at it ... in many (most?) cases we find that the PID isn't programmed correctly in the first place – so tuning the loop is virtually impossible ... (I'm talking mostly about timing and scaling issues here) ...

also ...

instead of trying to TELL us how the loop is responding, I suggest that you SHOW us instead ... set up a trend in RSLogix500 – and "graph" your system's action through a couple of test runs ... post the results here on the forum and we'll all do our best to help you out ... (TIP: and PLEASE change the colors so that it's not a dark-blue trace on a black background) ...

good luck with your project ...
 
Last edited:
I have been reading Ron Beauford's papers on PID's and I have a couple questions.

They talk about the error being a percentage of the full scale. In a Micrologix PID what is the full scale if the Setpoint Max and Min are default values ?

In the system I am working on, the disturbances are large and need to be corrected within a second or two. Perhaps a PID is not the thing to do, as it seems that it reacts too slowly and too late no matter the P I or D settings. Is a PID suitable for large disturbances that need to be corrected quickly?

would the RG setting have any effect?
 
regarding your latest questions:

In a Micrologix PID what is the full scale if the Setpoint Max and Min are default values ?

take a look at page 271 in the following manual (excerpt attached below) ...

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1762-rm001_-en-p.pdf

I'm assuming (gosh, I hate that word) that you're using either a MicroLogix 1200 or 1500 – so that's the manual that I've linked ... PID is covered in Chapter 19 ...

anyway ...

in a MicroLogix PID, the full scale range of the input signal is ALWAYS from 0 to 16383 ... you can't change that ... specifically, I mean that the PID instruction ALWAYS "looks at the world" based on a yardstick which ranges in value between 0 to 16383 ...

now, yes, you CAN have the PID provide the operator with "scaled" values to work with (PV and SP) ...

BUT ...

the PID instruction itself (internally) ALWAYS regards its input signal as being measured against that 0 to 16383 yardstick ... and (most importantly) the PID always performs its calculations BASED ON that same 0 to 16383 view of the world outside ...

incidentally, this is where some people get into trouble – by "scaling" the PV (input) signal to some other range BEFORE the PV signal is fed into the PID ... oops! ... the PID still regards the PV as being between 0 to 16383 ... so for the programmer's intended signal of 100 (as in percent) for a full scale reading, to the PID the number 100 will actually look like a signal of 100 DIVIDED BY 16383 ... in other words, the PID (bless its little heart) "sees/regards/accepts" that "full scale" PV as an input signal of a puny little 0.61 percent ... more specifically, instead of seeing the programmer's intended 100 percent input – the PID thinks that the input signal is LESS THAN 1 PERCENT ... (so - talk about hard to tune) ...

In the system I am working on, the disturbances are large and need to be corrected within a second or two. Perhaps a PID is not the thing to do, as it seems that it reacts too slowly and too late no matter the P I or D settings.

question: to get down to brass tacks – could YOU (personally) control the system yourself? ...

here's the thought ... suppose that you take the PID out of the picture, and that you yourself have full manual control of the output ... suppose that you see the system starting to "react" by going too low ... suppose that you suddenly/instantly manually shoved the "pedal to the metal" ... would the system continue to go down? – or would the newly increased output "turn the system" around and head it in the right direction? ...

suppose that your answer is: "no, the system wouldn't/couldn't respond quickly enough – not even with a perfectly-timed full-throttle output" ... well, then ... that probably means that your system doesn't have enough horsepower to provide adequate control ... naturally we shouldn't blame the PID for that - but some people do ...

analogy: you couldn't make your Volkswagen give you better "take off" performance just by replacing the cruise control ... especially if you yourself couldn't achieve the performance you desired by slamming the "pedal to the metal" when the light turns green ...

Is a PID suitable for large disturbances that need to be corrected quickly?

now that depends ... we don't know nearly enough about your system to answer that question ... specifically, we don’t know anything about your "timing" – or about your "scaling" ... and we don't even know what physical process you're trying to control ...

would the RG setting have any effect?

probably not ... all that does is give you one additional decimal point of resolution in your entries for the Proportional and the Integral settings ...

aside:

most of this was written to answer (as best as possible) your specific questions ... we also need to remember that many other readers will come across this material in the future ... some of what I have written is meant to make the concepts easier for them to grasp – even without knowing anything at all about your particular system ... please don't be offended if you "already know" most of this ... some of it was written with other readers in mind ...

good luck with your project ...

.

pid_PV_scale.jpg
 
Last edited:
Often a PID will be run from a STI ladder for a standard process time. Have you checked how often your PID instruction is being called?
 
It would also be helpful if you Posted your PLC Program File (Zip it first), so we can have a look for any issues.

Stu....
 
It would be more helpful to post a trend and tell use what kind of plant is being controlled.
Plot the SP, PV and CV. Also, it would be good to save the trend or plot data as a CSV file.

Usually people can adjust the gains and time constants so the system will work even if there are errors on how the PID is setup. It may not be right but the PID will control well enough. If the PID will not control well enough after hours of tuning there is usually something tricky about the system or just plain wrong.

Ron asked some good questions that should be answered.
 
Describe your system in detail.

Exact PLC.

What is the CV? Physically how is that signal going to your system (the actual device, the output card used)?

What is PV? Physically how is that signal coming into the system (the actual device, the input card used)?

And by what I mean all the pertinent details (Load cell, encoder, potentiometer, 4-20ma? 0-10VDC? resolutions, conversion times, scaling, etc.)

What is the full range of your control expectation?


What percentage error of your control full scale can you tollerate? Or said differently, what is the "band" you are trying to settle out in within a couple seconds?

What kind of filters do you have on the feedback signals?

What kind of deadtime, backlash, hysteresis do you have in the system?
 
I don't mean to offend, but there is no way you would be able to decipher this thing if I posted it on this forum. you cannot see the physical system, there is so much about it that is spaghetti and (mistakes), they have tried to use multiple PIDs to compensate for different conditions that occur, It is in conjunction with a 43 screen Panel view project...If you could physically be here and see it, and have access to everything , it would take you a couple of days to figure out what inputs and outputs are for what, and where, and how many places the variables are being modified.... so there is no point in suggesting that I post it... I sincerely apologize if I am offensive , but this is not a simple project.... and it was not very well done or documented.

This site is the best resource anyone could have and I really appreciate all your help, but if you would be so kind as to answer the questions I ask (or don't if you don't want to... I know I am not entitled to anything from any of you and I am appreciative of anyone who is willing to help).

The questions I ask are what I want to know. I can't post the trends or the program files ... I don't think either one would tell you anything. I have been looking at them for a long time.

I truly do not mean to be offensive or un appreciative I do appreciate everything that everyone is saying, thank you thank you thank you :geek:and I mean that sincerely...but I am the one here with this mess. I want to know some things about the allen bradley PID operation in a Micrologix 1500 PLC. The help and the documentation is not particularly helpful IMO. If it were, I would be reading it right now. I have and I will read it again... In conjunction with Mr. Beauford's fine articles, some of it makes more sense than it did before.

I come here because you are the best help I know of. Being demanding of all this info from me is not what I need. I can't supply it, and it wouldn't do any good if I did. Anyone who has worked with Factory talk and multiple screens and being unfamiliar with, and blind to the physical system, should understand that that is just not practically useful.

I will be back when I formulate my questions and answers to the questions some of you asked, as this post is already too long.... I hope I didn't offend everyone and someone will still be willing to help. I just want to know what I want to know. I don't expect you to solve the whole problem for me.

again thank you.
 
No offense taken. Are questions and requests were just to try and help you out. As soon as you have some concrete question, ask away, and I am sure someone will do their best to help you.

Stu....
 
I don't mean to offend, but there is no way you would be able to decipher this thing if I posted it on this forum. you cannot see the physical system, there is so much about it that is spaghetti and (mistakes), they have tried to use multiple PIDs to compensate for different conditions that occur, It is in conjunction with a 43 screen Panel view project...If you could physically be here and see it, and have access to everything , it would take you a couple of days to figure out what inputs and outputs are for what, and where, and how many places the variables are being modified.... so there is no point in suggesting that I post it... I sincerely apologize if I am offensive , but this is not a simple project.... and it was not very well done or documented.

This site is the best resource anyone could have and I really appreciate all your help, but if you would be so kind as to answer the questions I ask (or don't if you don't want to... I know I am not entitled to anything from any of you and I am appreciative of anyone who is willing to help).

The questions I ask are what I want to know. I can't post the trends or the program files ... I don't think either one would tell you anything. I have been looking at them for a long time.

I truly do not mean to be offensive or un appreciative I do appreciate everything that everyone is saying, thank you thank you thank you :geek:and I mean that sincerely...but I am the one here with this mess. I want to know some things about the allen bradley PID operation in a Micrologix 1500 PLC. The help and the documentation is not particularly helpful IMO. If it were, I would be reading it right now. I have and I will read it again... In conjunction with Mr. Beauford's fine articles, some of it makes more sense than it did before.

I come here because you are the best help I know of. Being demanding of all this info from me is not what I need. I can't supply it, and it wouldn't do any good if I did. Anyone who has worked with Factory talk and multiple screens and being unfamiliar with, and blind to the physical system, should understand that that is just not practically useful.

I will be back when I formulate my questions and answers to the questions some of you asked, as this post is already too long.... I hope I didn't offend everyone and someone will still be willing to help. I just want to know what I want to know. I don't expect you to solve the whole problem for me.

again thank you.

Try not to take this the wrong way, but imagine you went to the doctor because of a nagging back pain. You tell the doctor that you have no idea what is causing the pain, and that nothing you do seems to give you any relief. You are out of ideas and need some help! So the doctor tells you, "Well, we don't have enough information to go on here. I'm going to have to get an X-ray before I can begin to help you out." To which you respond, "Sorry doc, my back is a mess, and looking at it, won't help you. Besides, I've already tried." Seem a little off to you?

It's ok if you are not able to post program files or trends, you are not obligated to do so, but you shouldn't take the requests personally. Ron has posted some good info for you to answer your specific question about % of scale. But to be able to begin to suggest what you need for a faster response, or to suggest gains for the system, someone would have to have these things. At least a better description of what the system is, and what it is trying to control may give some hint as to what may be the problem. It sounds like it may be a combination of a lot of things! It sounds like a lot of people have tried to "throw PIDs" at a system that was poorly designed in the first place.

Are you able to try running the system with the CV in manual, and observe PV response? If you can get the system stable in manual control, then "bump" the CV up a certain amount, then observe how much the PV changes, then you can get a rudimentary estimate of the process gain. For "moderate" tuning purposes, you can start with a P (Proportional) gain of (1/Kp) * ((PVmax-PVmin)/100) (Kp = Process Gain, or PV/CV). Now keep in mind that this is a VERY simplified version of a scientific way to arrive at a P gain, but it can get you started.

Now let's look at the I (Integral) gain. For a micrologix plc, the typical unit for the I gain is min/repeat. For practical purposes, this means how many minutes you want the PID instruction to take to "repeat" or double the effect of the P gains contribution to the CV if there is no change in error. So if you are using a typical reverse-acting error equation (E=SP-PV) and you are 20 degrees below SP, then your error = 20. If you have a P gain of 2.5, then the P gain will add 2.5*20 = 50% to your current CV. If you have an I gain of 2.0 min/repeat, then after 2 mins, if your error has remained at 20 degrees, then your P gain will still be contributing 50%, and your I gain will also be contributing 50% so you will be pushing full scale 100% CV.

Now knowing what to set your I gain to requires some empirical testing. This is where a trend comes in extremely handy. Remember the CV "bump" test that gave us Process Gain? Well we would also use this test to give us Process Time, which is basically the time (in minutes) that it takes the PV to complete 63.2% of the delta from the moment it begins to change. For simple tuning, you will set your I gain = Process Time. Bear in mind, none of this takes into account Deadtime, which from the trend, would be the amount of time elapsed between a CV bump and the moment that the PV begins to change. The greater your deadtime, the more the simple tuning described above falls apart, and the more complicated the gain equations become to compensate. For a more detailed explanation of this tuning process, check out www.controlguru.com.

All the tuning knowledge in the world won't help you, though, if your mechanical design is flawed. I wish you all the luck in the world with your project, and be sure to post back if you have more questions, or if you make any headway, let us know how it goes.

Cheers,
Dustin

🍻
 
Last edited:
The input (PV) to the PID is from a loadcell supporting a vibratory conveyor that inputs from ( I assume ) 0 to 16000+ I don't know exactly.
Some manipulation is done in logic to the output of the loadcell to zero it, and arrive at the PV that corresponds to the weight in pounds on the conveyor in thousandths. Eg. 3000 = 3 pounds on the conveyor 10000= 10 pounds material on the conveyor.
10 pounds is probably about the most material that can physically fit on the conveyor.

The vibratory conveyor (VC1) feeds a machine, and the desired weight on the conveyor is usually around 3 pounds, so the setpoint is usually somewhere in the neighborhood of 3000.

This VC1 (and others similar to it) is fed by another vibratory conveyor (FVC) that contains a slidegate (SG1) that is positioned pneumatically . Additionally, the speed of the feeding conveyor (FVC) is controlled by another PID that has under different conditions it's PV as the weight on the "fed" vibratory conveyor, OR a level sensor on the feeding conveyor. The desired position of the slidegate should be determined by the PID with the setpoint of 3000, but I am not certain that that is always the case.

There is a considerable amount of "logic" contained in this system that I am not convinced is logical.... at least not to me.

There are downstream instances of VC1 to be fed in addition to VC1; which also affect which PID is used to control the speed of FVC. Upstream instances of VC1 effect the amount of material on FVC, which I know is a problem. There are level sensors trying to accomodate that as well, by manipulating the speed of upstream instances of FVC.

This VC1 will empty itself in 10 seconds. so 3 pounds will be gone in 10 sec... in 5 s. the weight would go from 3 pounds to 1.5.
The idea is that the slidegate and FVC should replenish what leaves VC1 as it leaves and maintain a steady 3 pounds on the VC1. It seems like a simple concept... seems like I should be rich and good looking, too.

I know that the varying amount of material on the feeding conveyors is a problem. Like trying to control that theoretical gas oven when the incoming gas pressure is always varying. But it seems like the PID loops are always too slow to react.
I know there is physical lag in the slidegates and so on, but the output from the PIDs is too late in the trend plots, and sometimes doesn't even seem to me to be in the right direction.

I start out with the Integral and derivitive turned off. and work with the Proportional only. when I feel that I have done what I can with that, I add integral and try to get some reasonable response. finally I try some derivative. I keep track of these in a little table while watching the trends of the PV CV and conveyor speeds and slidegate positions. There doesn't seem to be any place that works, and it always seems that the PID is too slow to react, and often the CV continues to rise even though the PV is above set point... that one I don't get at all.


I wonder if someone would 'splain this to me, please:

from the MicroLogix manual
PLC 5 Gain Range (RG)
When set (1), the reset (TI) and gain range enhancement bit (RG) causes the reset
minute/repeat value and the gain multiplier (KC) to be divided by a factor of 10.
That means a reset multiplier of 0.01 and a gain multiplier of 0.01.
When clear (0), this bit allows the reset minutes/repeat value and the gain
multiplier value to be evaluated with a reset multiplier of 0.1 and a gain multiplier
of 0.1.
Example with the RG bit set: The reset term (TI) of 1 indicates that the integral value
of 0.01 minutes/repeat (0.6 seconds/repeat) is applied to the PID integral
algorithm. The gain value (KC) of 1 indicates that the error is multiplied by 0.01
and applied to the PID algorithm.
Example with the RG bit clear: The reset term (TI) of 1 indicates that the integral
value of 0.1 minutes/repeat (6.0 seconds/repeat) is applied to the PID integral
algorithm. The gain value (KC) of 1 indicates that the error is multiplied by 0.1 and
applied to the PID algorithm.


Would setting the RG bit make the CV change more rapidly over the same amount of time?
 
Last edited:
I wonder if someone would 'splain this to me, please:

I answered that one back in Post #5 ...

you asked: "would the RG setting have any effect?"

I answered: "probably not ... all that does is give you one additional decimal point of resolution in your entries for the Proportional and the Integral settings ... "

all that mumbo-jumbo that you found in the book just boils down to a fancy way of saying that you can enter "123" on the screen – and the software will convert that to EITHER:

12.3 ... OR to ...
1.23 ... depending on the setting of the RG bit ...

so - regarding your current question:

Would setting the RG bit make the CV change more rapidly over the same amount of time?

nope ... all it would allow you to do would be to enter the values for the Proportional and the Integral settings with one extra decimal place ... (pennies – instead of dimes) ... smart money says that's not going to be the solution to your "tuning" problem ...

based on the old adage that a picture is worth a thousand words, here's a quick screen shot that might help ...

.

RGBIT_2.PNG
 
Last edited:
That sounds like a crazy set-up to me. I don't see why you would have two control elements and two non-cascaded PID's to control the same load of material onto the VC1. Unless you are under some non-disclosure agreement, you really should post your program for us to take a look at.

Did you try a manual-mode CV change test? In other words, freeze the speed of the feed conveyor and freeze the slide-gate position, and then open the slide gate a fixed amount and trend the results. Trust me, you are going to have a REAL hard time getting results just hunting and pecking at gain values.
You may find you can get perfectly satisfactory results by only controlling either the slidegate or feed conveyor speed.

As for what you are saying about the CV being slow to react, and moving in the wrong direction, that sounds like Integral windup. Possibly caused by too much deadtime, or by too much integral action. Think of the integral action as memory. It is remembering being below the setpoint for a long time. This memory is so powerful that it washes out the "here and now" proportional action that is saying hey, I'm over the SP, slow-down, but the Integral "memory" is saying, yeah but we were low for so long, we don't need to slow down yet...

Try to simplify. Focus on one loop at a time, and put the other in manual. Do the CV tests, trend your data, do the math to get a good starting place for your gains (I would avoid Derivative for now). There's a reason these processes were developed. By and large, they work.
 

Similar Topics

I have a 24" plotter that we print out full scale backpanels and transfer all the holes to a backpanel for faster layout and build time. Does...
Replies
11
Views
1,626
Hello all, I have programmed a script in InTouch which will increment a value (lets say "tag1") from 0 to 10000 within a given interval. This...
Replies
18
Views
5,918
We have a trainer set up and I am trying to learn function block programming to reinforce my resume. In ladder I am pretty fast. I double click...
Replies
0
Views
2,075
I've got 7 Powerflex 700 drives running a varying number of motors on each drive. I have one drive that is consistently running higher speed than...
Replies
3
Views
1,892
Looking for some explanation... received this instruction (see attached) from a colleague regarding how slow our laptops were at opening...
Replies
25
Views
10,012
Back
Top Bottom