AB PLC5 PIDs

Join Date
Apr 2004
Location
Vernon, BC
Posts
133
I just returned from a site where I replaced a 5/30 Series C, Rev H with a 5/40 Series E, Rev B and had problems with the results of the PID instructions used in the ladder. The PV value returned by the PIDs would be lower than expected when using the 5/40. I manually compacted the data tables and used the 5/30 and everything is fine. Looking at the AB knowledge base, there is no mention of changes to the PID instruction operation exept for some zero crosing and bias tieback stuff. Has anyone else experienced differences in how instructions operate from series to series?
 
You may have to call techsupport to look over FW revision history:
Your 5/40 ser E definately has not latest firmware and this firmware may be older that ser C rev H.
In any case PID should work exactly same way.
Take a look at the program to make sure PID is triggered by a timer and preset is exactly equal to the loop update time.
 
Greetings Derek,

if you'd like to post your code, we'd be glad to take a look at it ... but ... I really don't think that anything will show up ...

if all else fails, here's a suggestion for testing purposes ...

clear out EVERYTHING in the first PLC except for the PID rung ... instead of using a timer to "trigger" the PID, use a bit that you can manually toggle off and on ... manually enter a "test" value for the PV ... trigger the PID and record any data that you find suspicious ...

now do the same experiment with the next PLC ... if the PIDs are set up exactly the same (PV, SP, tuning, etc.), then you should get exactly the same data from each one ...

basic idea: the PID is a math function ... if you put a certain number in, then you should get a certain number out ... if two PIDs are set up exactly the same, then putting the same number into both should result in getting the same number out of both ...

I'm betting that the PID "apples-to-apples" test I suggested above will show that the two processors give exactly the same results ... once that fact has been nailed down, then you can start looking at things like scaling, etc. ... of course if the results are different from one processor to the next, then who knows where this will end up? ...
 
Thanks Ron, but it is not my code.

The funny thing is that the 12 PID instructions are triggered from the results of a BSL. The bit will get to a PID every .45 seconds, but the update times are set from 1 to 4 seconds. The logic works as the customer expects in the 5/30 but not in the 5/40.

To move the logic from one to the other I upload, save, change controller properties and download into other PLC so all settings should be the same. In fact, to recover from the problem I took the online logic from the 5/40 changed the controller back to 5/30 and downloaded it and the results were as the customer expected.

I cannot test further as this facility is in operation.
 
sounds like we may never really know for certain, but here’s my best “wild guess” about what happened ...

suppose that one of the processors had a faster scan time than the other ... if the PIDs are not accurately triggered on a well-regulated time schedule (as Contr_Conn mentioned) then the results of the PIDs could conceivably be different from one system to the other ...

I’m not sure that I fully understand what you mean by:

the 12 PID instructions are triggered from the results of a BSL. The bit will get to a PID every .45 seconds, but the update times are set from 1 to 4 seconds.

that approach sounds highly unorthodox ... again, it’s just a wild guess, but I’d bet my pocket change that one of the processors was scanning the program faster than the other ... please let us know if you get any more information about this problem ... it sounds very interesting ...
 
As far as I know the trigger rate must exactly match loop update time.
If this is not true than PID will never do calculations correctly, but within the same program will give you consistently incorrect results and error can be compensated by tuning. It is my guess that ser E does calculations faster, so errorneious result is more visible.

To prevent this error PIDE in ControlLogix automatically adjusts loop update time based on the periodic task rate.

Technically if timing is set correctly gains will depend on the process only and should be same.
 
Last edited:
I am aware that the trigger rate should match the configured rate and was surprised with the method used to trigger the PIDs. Basically there was one timer that pushed a bit through a bit shifter and the PIDs were triggered from progressive bits in the shifter. It may be that the PIDs never operated properly as the customer is only comparing what the results were before the 5/40 to what they are with the 5/40. I will check the offline files and see what the reported scan times were. Thanks for your comments.
 
I will check the offline files and see what the reported scan times were
This is not a scan time influence, it is a internal microprocessor speed and how fast it does internal PID calculations. Scan time should be faster with ser E anyway, but has nothing to do with PID calculations.
 
scan time’s possible effect on PID performance ...

Greetings to all,

in various posts above, Contr_Conn said (in part):

Take a look at the program to make sure PID is triggered by a timer and preset is exactly equal to the loop update time.

As far as I know the trigger rate must exactly match loop update time.
If this is not true than PID will never do calculations correctly, but within the same program will give you consistently incorrect results and error can be compensated by tuning. Technically if timing is set correctly gains will depend on the process only and should be same.

all of this is technically correct and is good sound advice ... but then in post #8, Contr_Conn went on to say (in part):

This is not a scan time influence ...

Scan time ... has nothing to do with PID calculations.

unfortunately this is incorrect ... specifically, if the PID is not correctly programmed, then the program scan time CAN indeed influence the PID’s operation ...

now let me begin by saying that if taken in the ongoing context of the current thread, then Contr_Conn’s statement might certainly be acceptably on target ... specifically, IF all of the sound advice he had already given in his previous posts had been followed, then the “scan time” effect might well be considered a “non-issue” ... but that’s a big “if” ... I have a strong suspicion that the program that Derek has been working on does NOT incorporate Contr_Conn’s excellent advice ... still if Contr_Conn did have this “ongoing context” in mind when he made that troublesome statement, then I hereby apologize for having misinterpreted what he actually meant to say ...

and so now on to discussing how the program scan time actually CAN affect the PID tuning after all ...

preview of the following discussion: the PID’s Integral action and its Derivative action are both mathematically related to time ... if the PID is not correctly executed on an accurately timed schedule, then the output of the PID will be skewed from the “expected” results ... while it is not recommended practice, it is POSSIBLE to alter the PID’s tuning to “compensate” for the inaccurately timed execution and thus obtain satisfactory control of the process ... BUT ... if the timed execution is INCONSISTENT, then the PID will, in effect, become “detuned” whenever the execution rate becomes either significantly faster or significantly slower ... I suspect that Derek’s problem is being caused by this “scan-time-related-detuning” effect ...

the discussion below focuses entirely on the PID’s Integral action ... if anyone wants to also explore the Derivative action, please post your request ... it might take a few days for me to respond but I’ll try to answer your questions as soon as I can ...

the figure below shows an experimental test of a PID in an Allen-Bradley PLC-5/20E ... the PID was programmed using an N-type (integer) control block ... the standard “ISA” or “Dependent Gains” equation was selected ... the PID rung was placed in an STI (Selectable Timed Interrupt) routine as detailed on pages 14-30 and 14-31 of the PLC-5 Instruction Set Reference Manual

... using this STI programming method allows us to easily and accurately change the PID’s execution (or “trigger”) rate by simply altering the STI setpoint ... this way we can simulate the effects that a “faster” or “slower” scan time would have on the PID’s output ...

the values for “STI” given in the figure below are in units of “seconds” ... the values for “LUT” (Loop Update Time) given in the figure below are also in units of “seconds” ... the values for Ti (Integral Time) given in the figure below are in units of “minutes per repeat” ... the X-axis of the graph is 10 minutes long ... a grid line is displayed at each 2-minute interval ...

[attachment]

the test begins at “0” minutes with the process in a condition of “steady-state" control ...

from point “A” to point “B” the PV is accurately tracking the SP at 20% ... since the PV is “on target” the Error is 0% ...

from point “F” to point “G” the PID is driving the CV at a constant 5% ... since the Error is 0% there is no change in the CV due to Integral action ...

from point “B” to point “C” the SP is suddenly increased from 20% to 40% ... this generates a new Error of 20% ...

from point “C” the SP is kept at 40% all the way to point “D” ... from point “B” the PV is kept at 20% all the way to point “E” ... the constant SP and the constant PV result in a constant Error of 20% throughout the duration of the test ... in a real-world system the PV would be expected to change as the test proceeds ... by holding the PV constant throughout our test, we can concentrate on how the PID’s Integral action responds to differences in tuning and in scan time ...

from point “G” to point “H” the CV responds to the sudden new 20% Error with a 10% rise due to the Proportional action ... (E*Kc so 20*0.50 = 10) ...

from 2 minutes to 4 minutes the Integral action has ramped the CV to a 20% increase from point “H” to point “I” ... the Ti setting of 1.00 minute/repeat gives 2 repeats of the Proportional action after 2 minutes ... thus 2*10=20 ... note that the STI “trigger” time of 0.50 seconds is exactly equal to the PID’s “Loop Update Time” of 0.50 seconds ... specifically, the PID is being executed on an accurately timed schedule ... this test period represents “normal” operation ...

from 4 minutes to 6 minutes the Integral action has ramped the CV to a 10% increase from point “I” to point “J” ... the unchanged Ti setting of 1.00 minute/repeat SHOULD HAVE given 2 repeats of the Proportional action after 2 minutes ... thus 2*10=20 ... BUT ... note that the new STI “trigger” time of 1.00 second is double the PID’s “Loop Update Time” of 0.50 seconds ... specifically, the PID is being executed only half as often during this test period as during the last 2 minutes ... more specifically, the loop tuning has been ALTERED by the inaccurately timed execution of the PID ...

from 6 minutes to 8 minutes the Integral action has ramped the CV to a 20% increase from point “J” to point “K” ... here the Ti setting has been altered to “compensate” for the inaccurately timed execution of the PID ... the new Ti setting of 0.50 minute/repeat SHOULD give 1 repeat of the Proportional action after 2 minutes ... thus 1*10=10 ... BUT ... note that the STI “trigger” time of 1.00 seconds is still double the PID’s “Loop Update Time” of 0.50 seconds ... specifically, the PID is still being executed only half as often as it should be ... more specifically, note that the 20% rise from point “J” to point “K” is exactly equal to the 20% rise from point “H” to point “I” ... DESPITE the change in the Ti setting from 1.00 minute/repeat to 0.50 minutes/repeat ...

from 8 minutes to 10 minutes the Integral action has ramped the CV to a 40% increase from point “K” to point “L” ... note that the new STI “trigger” time of 0.50 seconds is now exactly equal to the PID’s “Loop Update Time” of 0.50 seconds ... specifically, the PID is once again being correctly executed on an accurately timed schedule ... and so the Ti setting of 0.50 minutes/repeat gives the expected 4 repeats of the Proportional action after 2 minutes ... thus 4*10=40 ... also note that the 40% rise from point “K” to point “L” is double the 20% rise from point “J” to point “K” ... DESPITE the identical Ti settings of 0.50 minutes/repeat between the two test periods ...

the main point of all of this is that the response of the PID’s Integral action CAN indeed be influenced by the processor’s scan time ...

specifically, if we execute the PID at a “slower” rate, then the Integral action will be DECREASED ... on the other hand, if we execute the PID at a “faster” rate, then the Integral action will be INCREASED ...

discussion continued in next post ...

timetest.jpg
 
discussion continued from last post ...

going further, although it is NOT recommended, it is possible to “compensate” for a PID which is being executed on an inaccurately controlled schedule ... we can do this by altering the Ti setting to counteract either a “too fast” or a “too slow” execution rate ... we can do this (and this is the most important part) AS LONG AS the execution rate remains CONSISTENT ... the biggest area of concern would be that an “adequately” tuned system might suddenly become “detuned” if the PID’s execution (scan) rate became changed for any reason ... common things that might change the execution rate include: (1) either adding or deleting significant amounts of code from the ladder logic program; and (2) changing to a new PLC processor with a significantly faster or slower scan time ... from a purely practical standpoint, the thing to keep in mind is that any PIDs in such a poorly structured program will require “retuning” each and every time that the processor’s scan time becomes significantly altered ...

all of the foregoing having been said, this PID “scan time” issue would NOT be a concern IF (that’s a big “if”) the programmer has set up the PID correctly in the first place ... specifically, if the PID rung has been correctly programmed to execute based on an accurately timed schedule, then the processor’s scan time will not affect the PID tuning ... more specifically, IF (that’s another big “if”) the PID rung is CORRECTLY programmed then an increase or a decrease in the processor’s scan time will NOT affect the PID loop tuning ...

as I said in the beginning, this PID “timing” topic has come up on the forum before ... hopefully I’ve put enough detail into the discussion above so that anyone who is interested can easily recognize the issues involved ...

summing up ... the PID’s Integral action and its Derivative action are both mathematically related to time ... if the PID is not correctly executed on an accurately timed schedule, then the output of the PID will be skewed from the “expected” results ... while it is not recommended practice, it is POSSIBLE to alter the PID’s tuning to “compensate” for the inaccurately timed execution and thus obtain satisfactory control of the process ... BUT ... if the timed execution is INCONSISTENT, then the PID will, in effect, become “detuned” whenever the execution rate becomes either significantly faster or significantly slower ...

continuing on ... sometimes with concepts like this a simple analogy helps ... suppose that the PID is an accountant who figures the company payroll ... Bubba the operator is supposed to be paid $6.00 per hour for a 40-hour workweek - for a total paycheck of $240.00 ... but somehow the accountant gets his schedule mixed up and cuts a 40-hour paycheck for Bubba TWICE a week ... this is the effect that we’d see by “triggering” the PID twice as fast as expected ... (specifically, the Integral action changes twice as fast as our “Ti” tuning value requires) ... now the “smart thing” to do would be to put the payroll accountant back on a proper schedule ... BUT ... we COULD “compensate” for the incorrect schedule by cutting Bubba’s pay in half – to $3.00 per hour ... at the end of each week, Bubba would still have his correct total of $240.00 ... but this sure sounds like a weird way to keep the books doesn’t it? ...

now for the case at hand ... since I haven’t seen the code that Derek has been working on, I obviously can’t be certain that this “PID scan time” issue is actually the cause of his problem ... BUT ... I have seen things like this happen before ... based on my previous experience and on what Derek has posted, I highly suspect that his PIDs are NOT being executed on a “correctly” programmed time schedule ... further, I highly suspect that when he changed from one PLC processor to another, the program scan rate became either significantly faster or significantly slower ... if taken together, those two suspicions would (in my opinion) account for a “cause and effect” relationship that could adequately explain the problem that Derek has reported ... if it turns out that this “timing issue” is NOT causing the problem, then I for one would certainly like to know what IS causing it ... hopefully Derek will let us all know if any new information becomes available ...

finally ... if anyone is interested in a “nuts-and-bolts” discussion of how to go about “correctly” setting up the PID for an accurately timed execution schedule, please post and ask ... it might be several days before I get a chance to respond but I’ll to try to answer your questions as soon as I can ...
 
Wow, Excellent post Ron, this is one of the best posts I've seen!

I should give up earlier, my PID expertize is way way lower.

Any way I just want to respond to one comment:
When I said that PID does not depend on the scan time I meant "correctly programmed PID triggered at the same rate as loop update time". It can't be just a faster scan time issue.

I have seen a lot of working programms with incorrect trigger action compensated by gains.

That's why I really like PIDE in ControlLogix - it will automatically set loop update time based on the trigger rate.
 
Last edited:
Changing the tuning to compensate for variations is the timing is NOT the way to compensate. First it is best if the data for the PID and the execution of the PID is synchronous and the timing intervals are correct.

The effective gain for the I term is

Code:
     Kc*T
Ki = -----
      Ti

It would be best to recalculate Ki based on the current value of T, the time between the PID updates. The ONLY way I can see to do this is to change the loop update time in the PID block to the time since the last time the PID was executed. This will keep one from needing the change the gains. This will also compensate both the integral and the differential terms. I have wondered why Rockwell has never made this automatic until the CLX PIDE. It seems like an endless source of error. As Contr_conn pointed out. It looks like Rockwell finally got it right. This is why there are time stamps in the PIDE.
 
Greetings Contr_Conn,

from your post #11:
When I said that PID does not depend on the scan time I meant "correctly programmed PID triggered at the same rate as loop update time".

that’s precisely what I had hoped to hear you say ... now we’re on exactly the same page ... incidentally, after I read the statement in your post #8 and typed up my comments, I then went back and carefully reread all of the previous posts in this thread before I posted my response ... that’s when I realized that in the context of the current discussion, your statement could make sense ... it’s just that “standing alone” it comes across as being incorrect and misleading ...

you also said:
I have seen a lot of working programms with incorrect trigger action compensated by gains.

I’ve seen a lot like that too ... and of course they CAN be adequately tuned in spite of the timing issues ... but the “compensated” Integral and Derivative (time related) settings are usually some VERY strange numbers ...

and while we're on this subject, I personally find it rather interesting that most of the guys who complain about the inaccuracy of “auto-tune” programs and manual tuning systems such as Ziegler-Nichols, etc. usually seem to be the same ones who habitually set up their PIDs with these types of timing problems ... they never even give the “standard” tuning methods a fighting chance to work because of their own unorthodox PID setups ...

Peter Nachtwey said:
Changing the tuning to compensate for variations is the timing is NOT the way to compensate. First it is best if the data for the PID and the execution of the PID is synchronous and the timing intervals are correct.

I have absolutely no argument on that point, Peter ... we are in 100% agreement ... and I tried to make precisely the same point in the first few words of my post #10 ... specifically, one should NOT “mess up” the PID’s “trigger” timing and then “compensate” for the mess by fudging with the Integral and the Derivative settings ... but ... some people habitually do exactly that ...

I’ve sometimes heard them refer to their unorthodox timing adjustments as “speeding up” or “slowing down” the PID ... to these guys, the PID’s “Loop Update Time” entry is just another setting to be tinkered with and adjusted up or down while tuning the loop ... when they finally DO get the loop adequately tuned, they usually stand back and proudly say something like: “see there, I told you it would work this way” ... and from my perspective, it’s awfully hard to argue with success – even when the success is based on ****amamie timing and tuning values from the twilight-zone ...
 
Thanks for all your replies.

It gets stranger..

The PIDs are actually triggered every 8 seconds and are configured for 1 or 4 seconds. The program has 10 ladder files that are called as MCPs. These ladders call STXs with JSRs. The PIDs are in 4 of the ladders.

The SP of the PIDs affected are set in one of the STXs. When PV is to be controlled, the SP is set to PV and the STX takes the difference between the goal and the setpoint and either adds or subtracts 1/10th of it to the SP every minute.

The last and max scan times for the 5/30 and 5/40 are nearly the same (last = 30, max = 100).
 
yes, stranger indeed ...

Greetings Derek,

this program sounds needlessly complicated ... but ... if it WORKS to the customer’s satisfaction, then you would probably be unwise to jump into the deep end of the pool and “fix” it ...

in the interest of staying on the same page, let’s nail down a few specific issues right now ...

(a) the program works satisfactorily when run on the PLC-5/30 processor ... true or false? ...

(b) the program does NOT work satisfactorily when run on the PLC-5/40 processor? ... true or false? ...

(c) the PLC-5/30 processor will eventually have to be replaced with the PLC-5/40 processor ... true or false? ...

beyond those critical questions, here are a few more ...

what type of control blocks are being used for the PIDs? ... N-type (integer) or PD-type (newer PID file) ...

what equation (“ISA/Dependent Gains” or “AB/Independent Gains”) are you using? ...

what are the PID’s tuning values (Proportional, Integral, and Derivative) currently set for? ...

beside the “SP ramping” routine that you described, what else is programmed in those STX files? ... basically I’m just asking is there a LOT of other stuff? ... or just SOME extra stuff? ... or very LITTLE extra stuff? ... or NO extra stuff? ... reason for asking: if “ramping the SP” is ALL that the STX does, then it MIGHT (only MIGHT) be a good idea to convert that STX code into “plain old” ladder logic and remove some of the program’s complexity ...

you said:
The SP of the PIDs affected are set in one of the STXs.

does that mean that SOME of the PIDs in this program work ok even with the PLC-5/40 but that OTHER PIDs do not? ... if this is true then this could be a significant bit of knowledge for troubleshooting purposes ... earlier you said that there are 12 PIDs in this program ... I’ll assume (gosh I hate that word) for a moment that SOME of these PIDs always work ok ... but that SOME of the others only work with the PLC-3/30 ... if that assumption is correct, then are there any “common issues” between those that work and those that don’t? ... (for example: all of the “flow” PIDs work ok but all of the “temperature” PIDs do not) ...

in post #4 you said:
The bit will get to a PID every .45 seconds, but the update times are set from 1 to 4 seconds.

then in post #14 you said:
The PIDs are actually triggered every 8 seconds and are configured for 1 or 4 seconds.

I’ll assume that this latest “trigger” time is based on more research ... regardless of which number is correct, here is a “basic idea” troubleshooting trick which might help you nail down whether the “PID trigger timing” is indeed the root cause of your problem ...

add a branch under the “problem” PID ... put an ADD instruction on the branch ... (example: use something (previously UNused) like F8:0 for Source A ... use the number “1” for Source B ... reuse F8:0 for the Destination) ... if you put the branch in correctly, then the “add 1” math will occur each time the PID gets executed ... now run the test for a reasonably long period of time and watch the Destination of the ADD ... the basic idea is to watch for a consistently timed execution of the PID ... if the results are inconsistent over a period of time, then the PID is going to be virtually impossible to tune ... comparing the results of this type of test from the PLC-5/30 to the PLC-5/40 should help you nail down just what type of “timing problem” (if any) that you’re up against ...

you said:
When PV is to be controlled, the SP is set to PV and the STX takes the difference between the goal and the setpoint and either adds or subtracts 1/10th of it to the SP every minute.

by “when PV is to be controlled” I assume that you meant “when the PID is put into the AUTOMATIC control mode” ... is this correct? ... the “SP ramping” action that you described should not be a problem ... but just so that we all understand each other, are you saying that it takes 10 minutes for the SP to ramp up to the desired “target” or “goal” once the PID is placed in the “automatic” mode? ...

finally ... it looks like you are NOT going to be able to post the code ... but is it possible to post a screen shot of a “problem” trend and one of an “ok” trend so that we can see what we’re up against? ...
 

Similar Topics

Hey all, I'm pretty new to PLC programming and am on a team doing a PLC5 to Studio5000 conversion. After doing the built in conversion, I've...
Replies
6
Views
2,483
I am using the following formula and I am getting error, Invalid Expression - too many closing parenthesis. when i copy the formula to notepad or...
Replies
4
Views
132
Preface: Kinda long, so I made section titles Intro: I just want to see if anyone here has seen anything similar. A PLC5-40 series C enhanced...
Replies
3
Views
339
Hi, can anyone help me get a pdf file for this RSP files. They are from a PLC5. Thanks
Replies
1
Views
367
Back
Top Bottom