PLC-5 to L81E PID Conversion

OkiePC

Lifetime Supporting Member
Join Date
Mar 2005
Location
ENE of Nowhere Oklahoma
Posts
11,762
I am working on a system that uses 7 PID blocks in a PLC-5 and converting it to run on a L81E.

The conversion is done with the exception of going through the PID loops with a fine toothed comb. The original logic did not properly trigger the PID instructions (except for one). They were on unconditional rungs and have the loop update time set at 0.2 seconds. The PLC-5 scan time ranged from 17 to 22 ms, so I have set up my new MAIN task to be a periodic with a 20ms periodic rate.

That *should* mean that the PID behavior in the new controller will be as similar as possible but I would really like to fix these loops so that they are programmed "by the book".

I am not sure if I should move the PID loops to a separate periodic task set for 200ms to match the update rate in their instructions, add some trigger timers set for 200ms, change the PID update rate to 20ms, or something else. I am sure that if I do any of those things, the gains will need to be recalculated.

I need to err on the side of caution, so if the safest thing to do is leave them programmed incorrectly, then that is what I'll do, then during commissioning, we'll bring the machinery up very slowly and cautiously and do as much testing and tuning as possible.

Any advice on this?

Thanks.
 
is the old PLC-5 system still in operation and controlling the system - and is the new ControlLogix system capable of reading Messages from the PLC-5 ???
 
I worked on a system with similar challenges a few years ago.

I chose your status-quo method: the PID instructions maintained their mis-matched Update Rate settings (remained 200 ms) and actual execution rates (20 ms).

The PIDs were moved to their own Periodic Task, so that I could change its execution rate later when we re-tuned the loops.

But in that system, I never got the chance. "They work ? Great, let's re-start production".

If I had the time, I would have done what Ron is proposing: install the Logix to read the process variables from the operating PLC-5 controller and compare the outputs, so you can test a re-tuned set of gains without actually changing the control of the process.
 
After posting to this thread, Facebook's advertising analysis software decided I needed a book titled "An Idiots Guide to the PID Algorithm".
 
Yes, the PLC-5 is still installed and running.

The new system is here in our office for setup and testing, and I have wrapped up the programming of it and the changes to the HMI. I have organized it much better and have the inputs and outputs in separate routines so that I can toggle a "simulate" bit and run simulation logic in place of the real I/O.

I can't easily model the actual behavior of the equipment, but have done so in a crude manner just to make sure I have all the right pieces mapped to the right HMI tags etc.

The old system is actually a pair of PLC-5/20s connected to each other with RIO. One has all the digital I/O and the other all the analog. It was a bit messy. The new system is the same way, two L81E CPUs, one all digital and one all analog. This is a boiler control system and we have to keep two processors to meet their requirements, otherwise, one Logix CPU could easily handle the quantity of code. My main task runs in under 0.2ms in each CPU (averages 0.120 ms).

The new system uses produced/consumed tags to replicate the tags that were connected through RIO. I spent a boatload of time tracing out all the moves and TODs and FRDs since the analog was all done with 12bit BCD cards. I kept the 0-4095 scaling at the analog inputs (for now) but switched to REAL numbers in the new system so that I can at least enhance the resolution without screwing up the behavior of the PID code any more than necessary.

The plan is to remove the old and install the new. I don't think there is an easy way to get them both set up and communicating.

As I look at the PID values, it appears that the gains may not be finely tuned. They all have a P gain of 0.1 or 0.2, the I gains vary, and no derivative in any of them. Several of the control values for some of them will be interacting with each other in the real world and some of the PID CV tags get processed through a "function generator" before being sent to their output points. The function generator was 3 subroutines with lookup tables to take the 0-4095 CV, scale it to a percent, run that through a "curve table" and then convert it back to a 0-4095 integer. I kept all that and the project migrator brought in all the values. I plotted those lookup tables in excel and graphed them to help me understand what they are intended to do. I think that the boiler technician who was involved in the original PLC-5 programing used these tables for combustion efficiency tuning for the most part. The original code was quite messy and there were a handful of outright mistakes that we have already taken care of in the running machine. The guy would convert a block from BCD to decimal with one FAL, then use CPT blocks with the original BCD address including a FRD in various places anyway. I think it was a case of two guys learning the PLC-5 during development and the 2nd guy ended up making it work without fully understanding the details of the one who did most of the code, so he butchered a lot of it.

The PID values may have been diddled with in the beginning (circa 1995 according to one drawing), but for at least the last 6 years, none have been adjusted (I have multiple backup copies from the customer). My co-worker who knows the equipment like the back of his hand is going to be helping me with this, and he knows what to watch for when we get ready to put this thing into operation. His PLC skills are not as deep as mine, so I gotta give us a solid foundation in knowledge when the time comes. I think we are scheduled for late July to do the actual commissioning and we can take as much time as needed to install and test before bringing it back to production.

EDIT: The idea of running both CPUs side by side to compare PID behaviors is brilliant, and I will see if we can find some floor space to make that happen. It would certainly be worthwhile. They do have a Logix gateway tied into the DH+ network that I might be able to spin off some comms with. The DH+ network has 8 nodes, scattered RSView32 tags to 4 of them and is already slow, but if we can hijack some of its remaining bandwidth temporarily, it might pay dividends.
 
Last edited:
Matter of fact, their gateway rack has CPU in it I could probably use. I think it was sold to them as a boiler optimization package that never worked and is just sitting there doing little to nothing. They have three boilers and a 4th PLC-5 running "balance of plant" auxiliary equipment. Their gateway machine was an attempt to tweak the adjustments normally made by operators on all three boilers to save energy, but made things bounce around too much and didn't pay off like they'd hoped, so they have its control bits disabled for the last year or so.

If I just stick bits and pieces of my code into it for trial purposes then I don't have to come up with a way to hang the shiny new gear on a wall somewhere and patch in. All I should need are the analog input values which are already there in one 16 word block I can read with one MSG instruction and map to my new logic data tags.
 
It's more of a pamphlet (27 pages, PDF) than a book, but I'm adding it to my bookshelf of simplified control theory that I share with our junior engineers.
 
I'm swamped these days - so no time to explain in detail ... but the general idea is to have the CLX read the same PV signal that the PLC-5 is seeing - then run that through your "best guess" of the way you want the new PID in your CLX to be set up ...

then use the CLX to trend the CV output signals from both the old and the new PIDs on the same graph ... this way you don't have to "model" your system at all - you're using the "real-deal" as you work on the tuning ...

now do whatever you want to do with the new PID setup - trying to duplicate its response to superimpose the CV output signals ... note that the CV from the new CLX system doesn't really "control" anything (yet) - it's just a "dummy" input to the trend so that you can compare the response of the new system to the response of the old signal ...

with a certain amount of patience/time/etc. you should be able to have the new CLX controller ready to plug-and-play into the system - and (hopefully) have the PID tuning right back to where it was before you made any changes ...

EDIT: The idea of running both CPUs side by side to compare PID behaviors is brilliant,

thank you ... I recommended it somewhere before on the forum - but can't find the thread right now ... I'm betting that Ken remembers the idea - since he seemed to know where I was heading with my first two questions ...

good luck with your project ... wish I had more time to play ...
 
Last edited:
I'm swamped these days - so no time to explain in detail ... but the general idea is to have the CLX read the same PV signal that the PLC-5 is seeing - then run that through your "best guess" of the way you want the new PID in your CLX to be set up ...

then use the CLX to trend the CV output signals from both the old and the new PIDs on the same graph ... this way you don't have to "model" your system at all - you're using the "real-deal" as you work on the tuning ...

now do whatever you want to do with the new PID setup - trying to duplicate its response to superimpose the CV output signals ... note that the CV from the new CLX system doesn't really "control" anything (yet) - it's just a "dummy" input to the trend so that you can compare the response of the new system to the response of the old signal ...

with a certain amount of patience/time/etc. you should be able to plug the new CLX controller into the system - and (hopefully) be right back to where you were before you made any changes ...

Outstanding. I will definitely push to do it this way. If I can install new equipment with cleaned up logic that is programmed properly, going forward we have a much better chance of fine tuning to improve the system performance.

Thanks Ron and Ken!
 
Here are a couple suggestions that may help to more quickly get similar performance between the active and test controllers:
. The loop update period/scan time inconsistency will affect integral and derivative components. Since there is no derivative, you should only be concerned with integral gain. The effect will depend on which PID equation is selected.
. Make sure to use the same PID equation ISA/dependent or AB/independent. See Mr. Beaufort's and other comments here: http://www.plctalk.net/qanda/showthread.php?t=18123 for a good explanation.
. If it is independent gains, you will need to multiply the current Ki by 10 to compensate for scanning the loop 10 times slower. If the PID equation is ISA/dependent, then divide Ti by 10.
. The Proportional gain will not need to be compensated for due to scan time change. However, it is dependent on input scaling. It is very important that the error calculation, in percent, is consistent between the two systems. This relies on the PV engineering unit min/max generating the same percent error on both systems. Since the PLC-5 analog is 12-bit, everything tends to be scaled against 0 - 4095. Make sure the new engineering span and input span combination produce the same result as those in the PLC-5 (ref: .MAXS, .MINS, .MAXI, .MINI)
. Double check the translation made the correct loop "direction" selection -- specifically that error (SP - PV) or (PV - SP) is the same on both.
. Post-loop computations on the CV will need to take into account the implicit 0 - 4095 scaling from 0 - 100% PID output. The logix translation should have done this, but the converted PID output going into these computation(s) will need to accept 0 - 4095 if they are using CV as input.
. There could be an impact from the slower loop update time 200 ms vs ~20 ms, but probably not with an application like boiler control. The analog inputs may not have been updating that fast on the original system anyway. However, when implementing the side by side test, your messaging strategy should not get too slow on updating the input to the test system. Ideally you would get updates every 200 ms (the new loop update) if network conditions allow for that period.
. The DH+message path through a gateway has been discussed in other threads.
 
Thanks for posting those considerations, with respect to the gains and why they are affected by the different execution rates and update time settings, as well as the dependent/independent and error and action polarity.


Fantastic insight !
 
Here are a couple suggestions that may help to more quickly get similar performance between the active and test controllers:
. The loop update period/scan time inconsistency will affect integral and derivative components. Since there is no derivative, you should only be concerned with integral gain. The effect will depend on which PID equation is selected.
. Make sure to use the same PID equation ISA/dependent or AB/independent. See Mr. Beaufort's and other comments here: http://www.plctalk.net/qanda/showthread.php?t=18123 for a good explanation.
. If it is independent gains, you will need to multiply the current Ki by 10 to compensate for scanning the loop 10 times slower. If the PID equation is ISA/dependent, then divide Ti by 10.

Good info, thanks. All the PID blocks use independent gains, and have the update time set for 0.2 seconds. However, they are being processed at about 20ms (with one exception), so if I change the loop update time in the new system to match my periodic rate of 20ms (0.02 seconds) then I should need to divide the I gain by ten to get the nearest performance, right?

The Proportional gain will not need to be compensated for due to scan time change. However, it is dependent on input scaling. It is very important that the error calculation, in percent, is consistent between the two systems. This relies on the PV engineering unit min/max generating the same percent error on both systems. Since the PLC-5 analog is 12-bit, everything tends to be scaled against 0 - 4095. Make sure the new engineering span and input span combination produce the same result as those in the PLC-5 (ref: .MAXS, .MINS, .MAXI, .MINI).

I did keep the same scaling but switched to real numbers (0.0 to 4095.0). The PLC-5 did not use CV scaling, so the conversion put zeros into the new PID blocks for CV Max and Min, but testing found and fixed that. Keeping the scaling the same should make the transition easier for me and for the techs and operators that are used to those ranges. I did add an AOI to "CLAMP" the analog inputs to hold the resulting PV tags to this range since the PLC-5 did that by default when set up for 4 to 20mA and 12 bit, but the 1756-IF16 doesn't by default and I wanted to have separate new tags driven by them that allow the full range the card is capable of so that I can display them on the HMI in milliamps for commissioning and calibration checks.

Double check the translation made the correct loop "direction" selection -- specifically that error (SP - PV) or (PV - SP) is the same on both.
. Post-loop computations on the CV will need to take into account the implicit 0 - 4095 scaling from 0 - 100% PID output. The logix translation should have done this, but the converted PID output going into these computation(s) will need to accept 0 - 4095 if they are using CV as input.
. There could be an impact from the slower loop update time 200 ms vs ~20 ms, but probably not with an application like boiler control. The analog inputs may not have been updating that fast on the original system anyway. However, when implementing the side by side test, your messaging strategy should not get too slow on updating the input to the test system. Ideally you would get updates every 200 ms (the new loop update) if network conditions allow for that period.
. The DH+message path through a gateway has been discussed in other threads.

It appears the conversion got everything right as far as equation selection, direction, PV tracking, etc. Since the PLC-5 wasn't using CV limiting, those numbers got translated as zeros for CV Scaling Max and Min in the conversion, but I caught that and fixed it. A couple of the programs do manipulate the output limits and those all appear to be correct too.

Good points about the MSG rates, The original code used a self repeating timer to fire off a BTR every 200ms to read the analog card and run one subroutine containing one PID block. The other PID blocks run every scan (~20ms). They are all independent equations. I have no idea why he did that, I suspect it was an oversight ... a blunder in my mind...

So I think I can run a MSG to read those tags every 200ms, 20ms might be a challenge. I might have to compromise on something in between, but understanding the results and what scale factors I need to apply to the I gain if I change it for the real conversion is key info.
 
Good info, thanks. All the PID blocks use independent gains, and have the update time set for 0.2 seconds. However, they are being processed at about 20ms (with one exception), so if I change the loop update time in the new system to match my periodic rate of 20ms (0.02 seconds) then I should need to divide the I gain by ten to get the nearest performance, right?

With independent gains, and the new loop update time specified correctly, I would actually multiply integral gain, Ki, by 10.

This is my thinking: in the PLC-5 the loop was being told update time was 0.2 seconds. So when it was integrating (summing) error it was multiplying error by that 200 ms interval before adding it. But, you were actually doing this 10 times faster at the 20 ms scan rate. This is basically equivalent to a 10x increase in integral gain. After correcting the loop update time setting you will need to move this "artificial" 10x factor into the gain itself, to get the same response. This is regardless of the actual update time (within reason), so long as it is correctly specified in the PID block.
 

Similar Topics

I am using Allen Bradley PLC 1756-L81E and EIP module 1756-EN2TR for Ethernet/IP communication. My communication works fine but in Get-Attribute...
Replies
2
Views
164
I have been doing some research on data highway and data highway plus, and have contacted Allen Bradley for information regarding communication...
Replies
10
Views
2,797
Hello, I have an automation direct d2 262 plc and C-more HMI EA9T6CL-R. I need to prepare a program, scheduled to be performed on a future date. I...
Replies
1
Views
31
Hello, I'm trying to delve a little into rs-485 communications for a couple projects of mine. Until now I've been using a delta vfd and a delta...
Replies
2
Views
47
Greetings All, I recently decided to start freelancing in Controls and Automation part time, most of my experience has been with Rockwell...
Replies
2
Views
95
Back
Top Bottom