Cascading

Sparky

Member
Join Date
Jan 2003
Location
Twin Falls, ID
Posts
64
I'm having a problem with two PID's that seam to work, both together (resulting in a massive over shot) and against each other (resulting in an inability to reach set point). I remember hearing something about cascading. Where two PIDs could work inter related. Here is some bkgrnd on the PIDs:
1. Controls pressure via a control dampener for an outlet fan. Set point -.5 inH2O out let fan is not on a drive and is on 100%
2. Controls temperature via a gas burner fed by a fan on a VSD.
The fan is controlled in manual, no PID yet, until I can stabilize the temp/pressure.
Since temp and pressure correlate with each other it is very difficult to stabilize either variable.

Any info on how to cascade PIDs or any thing else, would be great.
Any questions of spacifics just ask.
 
Yo, Sparky,

No offense intended - but are you sure that these loops are cascaded - or are you in the “grasping at straws” stage? (been there- done that) Usually when we say that two loops are cascaded, we mean that the output (CV or Control Variable) of one loop is being sent back (by the logic of the program) to the setpoint of the other loop. If I’m reading your post correctly I don’t see that happening. I’m short on time - but we’ll all be able to help you better if you’ll post again and give us a list of the actual addresses that you’re using on your PID instructions.

Suggestion: If these loops are NOT cascaded - then don’t try to go there. Most programmers regard cascaded loops as much harder to set up and to tune than independent loops. I’m just guessing here, but I think that you’re simply confusing the fact that your loops are “interrelated” (which is a physical aspect of the system itself) - and the word “cascaded” (which is a programming method). Does that sound reasonable? Sorry I can’t give you more help - but we’re going to need some specific answers first.

Something to watch out for: What do you have your "loop update times" set for? And what are you using to control how often the PID's actually get executed? (Timer done bit? STI?) These are usually the things that get missed the first time around - and the system will generally "go nuts" until they're fixed. Note to everyone: He's using PLC-5 hardware and not an SLC system. The PID's have quite different configuration requirements in the two platforms.

Finally, is this thing safe to experiment with? Or dangerous beyond belief?
 
Last edited:
Cascaded loops are used where the output (controlled variable) of one loop is the setpoint for a second loop.

Your first example would be fairly straightforward, with one loop with the process variable system pressure and the controlled variable damper opening.

The second control system could be casecaded. One loop would use temperature as the process variable, with the temperature setpoint manually entered, and air flow as the controlled variable. This air flow would be the setpoint for the second loop, and this second loop would have air flow as the process variable and fan speed as the controlled variable.

In order for cascaded loops to work properly there must be a physical cause/effect interaction in the process between the two loops. For example, if I built an automitive cruise control using two loops, the first with engine temperature as the process variable and outputting engine speed as the setpoint to a second loop, with the second loop measuring engine speed and controlling accelerator position, I would get very peculiar results. There is certainly a relationship between ground speed, engine speed, and engine temperature, but it isn't a cause/effect direct relationship. If I used drive shaft speed as the controlled variable ouputting engine speed as a setpoint to a second loop, and then have the second loop control engine speed by controlling accelerator position, I may get a system that works.

Part of your problem may be that there isn't a direct or simple correlation between temperature and fan pressure in your system. That depends on your physical system's configuration. The temperature probably (I am gusessing here!) varies with air flow. You may be substituting pressure for air flow in your control, but bear in mind that for a given restriction the flow varies as the square of the pressure. That may account for some of your instability (I am guessing here too!)

As our good buddy Terry points out, knowing bits and bytes isn't enough. You have to understand the process before you can control it.
 
Last edited:
not cascaded

Ron in response they are not cascaded, I knew this I wanted to cascade them. But with your repley Maybe I dont. I could experiment a little but if the vacuume is to great I run the risk of imploding a 2 million dollar stainless steal chamber and my career. i'm going to try to include a picture to better understand the process.
 
what is this thing anyway?

Sparky,

Is this thing a brand new piece of equipment? Or an existing machine being fitted with new controls? More importantly: Has the overall design ever been proven on other pieces of similar equipment?

Big question: Where in your system do you take care of the gas/air ratio? Common sense (such as I have) would lead me to believe that you’re not working on a “2 million dollar” combustion chamber without a lot more controls than are shown on your drawing.

I’m certainly no expert in this area but I’ll go ahead and give you my views until the right guys show up. First of all - the process of burning gas (efficiently, cleanly, safely) requires a specific mix of gas and air - in other words a “gas-to-air” ratio. The specific ratio required varies with the type of gas and also with the temperature of the mixture - along with other lesser issues. This helps explain why you have to use more “choke” for a gasoline engine when it’s cold - the gas/air mixture must be “richer” - and less choke when it warms up - and requires a “leaner” mixture. Anyway, if the gas/air mixture is too rich - then either the stuff won’t burn at all - or if it does burn, it will burn inefficiently and with a lot of soot and waste. If the gas/air mixture is too lean - then either the stuff won’t burn at all - or if it does burn, it will burn erratically and inefficiently. In other words, there is a relatively small range of values for the gas/air ratio which will give acceptable results.

The point I’m building up to is this: If PID #1 is controlling the chamber pressure by regulating the air flow through the system - and PID #2 is controlling the temperature by regulating the amount of gas fed into the system - then who’s taking care of the gas/air ratio to make sure the combustion is safe, clean, and efficient? What am I missing here? There’s got to be more to it than this.

Again, has this overall design ever been proven on other pieces of similar equipment? Oh - and incidentally - it sure looks dangerous from where I sit.
 
I assume you are burning natural gas, and operating "lean" - more air than the stoichiometric ratio would indicate is required. I further assume you have a flame detector or other means of dectecting loss of flame so you can cut off the gas. Your system is then something like a residential gas fueled furnace.

A couple of process related comments. Your loops are more or less independent - temperature controls gas flow. Your second loop, damper position is also independent. However, you need to limit your damper closing to make sure you never have less air than combustion requires, since you don't want to vent unburned fuel or CO.

I'm not sure why you want a second fan, since air in must equal air out - a simple mass balance you see. If it was my system I'd get rid of a fan.

I'm not sure why you want to control pressure, unless it is a process specific requirement. I am guesing you are trying to substitute pressure measurement for flow measurement, and it won't work.

Now, although your loops are "more or less" independent, there is some physical interaction, and this is what is giving you a problem. As you change damper position the friction loss in the system changes, making your pressure change, and your air flow changes, and because of the dilution effect of the inlet air your temperature will change too. This also applies to dryer internal pressure changes. And because one fan, presumably centrifugal, has the dryer on the suction side the air flow will change with temperature - centrifugal fan performance is density dependent.

I think you have an inherently un-stable system, but without knowing some of the specifics I won't say for sure. I don't like doing this, but I strongly reccomend you get an engineer familiar with air flows invlolved, and another (or the same guy if you're lucky) familiar with controls, and do some more basic engineering on the system.
 
good questions

ok The air/gas mix is controled by an independant system that automatically adjusts air for the gas demand. I also made some changes to the bit map image to shed some light on the process. My bigest problem is that when the dampener opens to increase vacuume the air flow out is increased and cools the temp. then when vacuume is reached the dampener closes in acordance to the pid settings, usually bringing the temp way high because the gas valve adjusted because of the temp drop. Oh and it is about six years old going through valve and control upgrades.

I really hope this clears up some things.
 
a little more detail

ok the system is a dryer a big one.
the chamber must maintain a negative pressure in order to dry the whey product.
one fan sends the Hot (burner heated air into the chmber) the other Fan sucking out produces the required vacuum.
if vacuum is not maintained then it blows powder out the other end instead of alowing gravity to pull the dryed powder down.
 
Sparky,

I’ve got to leave in a few minutes - but I’m sure that you’ll get some excellent advice overnight. Just a few more things that might make it easier for all concerned. Forgive me if I’m wrong, but I’m going to guess that you’re relatively new at implementing PID - and at loop tuning.

As I asked before: What do you have your "loop update times" set for? And what are you using to control how often the PID's actually get executed? (Timer done bit? STI?) These are usually the things that get missed the first time around - and the system will generally "go nuts" until they're fixed.

Basic idea: You have to tell the PID instruction (the box on the rung) when to execute - usually this is done with something like a timer done bit. You also have to tell the PID equation (the little accountant man inside the PID box) how often you’re going to be executing the PID. The two values (let’s just guess one-half second for each) should match. Why? Let’s just suppose that you (incorrectly) execute the PID every single time that the rung gets scanned. That’s really too often. Plus - even worse - the elapsed time between successive scans might vary considerably from scan to scan. Now think about the little accountant man inside the PID box. Every time the PID gets executed, the accountant calculates a new value for the output - and he’s basing that calculation on what you entered for the “loop update time” when you set up the inside of the PID. But if the PID is executing much more rapidly than that - well, then the little PID accountant will crank up the CV like there’s no tomorrow. So all of your tuning values will be screwy.

Analogy: I tell my office accountant that he’s supposed to calculate weekly paychecks for my employees. But then somehow I mess up and every single day, I tell him to calculate the paychecks - calculate the paychecks - calculate the paychecks - every single day. Now each employee starts getting 40 hours worth of pay - every single day. Just look at how the values “go nuts”. A lot of PID beginners don’t realize the relationship between the loop update time entered on the PID setup screen - and the time between successive executions of the PID rung. So they end up trying to compensate by using weird tuning values. Back to our analogy. I could (and should) fix my payroll problems by “executing” the PID accountant once a week. But I could (although I shouldn’t) also compensate for the “too frequent” execution by simply cranking back on the hourly pay rate for each employee. For example: Instead of paying Bubba $10 per hour - I could divide that rate by 5 (the number of executions per week) and tell the accountant to pay Bubba $2 per hour. So Bubba still gets a “weekly” paycheck every day - but now the paycheck is for $2 * 40 hours = $80. Five of those per week and Bubba gets the correct weekly amount of $400. But I’d sure call that some screwy accounting. Crazy? You bet. But that’s how a LOT of PID loops are set up out there in the field. Want to play hardball? Suppose the processor’s scan time is sometimes longer - and then sometimes shorter - because of different logic conditions. Look at how the PID’s output can jump around now. No wonder a lot of programmers are reluctant to use these PID things.

So anyway - let us know how you’re telling the PID “when” to execute - that is: the conditions on the rung, etc. That one issue can make a big difference in how well the thing can eventually control your system.

Also, it would be a very good idea to post your PID rungs so that we can take a look at them - inside and out. That’s not too difficult. Here’s an example:

XIO T4:0/DN PID PD9:0 N7:54 0 N7:75 1 0 0 17224 5243 16270 10486 16284 15729 16298 0 0 0 17402 0 0 0 0 0 0 0 0 0 0 0 16128 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 61440 17791 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Just keep double-clicking your PID rung number (example: 0012) until you shift into “text” edit mode. Then right-click and COPY all (I repeat ALL) of the text - and paste it into your next post. Anybody with RSLogix5 can then pick up the text - double-click an empty rung number - and paste the text onto the empty rung. That should duplicate your PID with all of its internal settings.

One more thing - give us some numbers to play with. Like how many seconds/minutes does it take from one event to the next? Example: The damper opens for about ten seconds - then it closes down. The temperature has risen by about 200 degrees during that period. Etc.

Offline for tonight - good luck.
 
Ron has got you on the right track. Assuming you hae copied the old logic, that apparently worked, and implemented it in your PLC, the fundamental system should be OK. As Ron says, tuning is probably too agressive - reacts to fast and too much. You have an inherently tricky system, with the two loops fighting each other. You alos have a problem with process transport lags - it takes time for the physical system to catch up with changing controlled variables. Your flow and pressure loop probably reacts more rapidly than the temperature loop.

Try slowing down the loops, as Ron says. Another trick I use is to have faster update times on one loop than on the other so that the second system can catch up after a change is made. In your case you may want to have the pressure update three or four times faster than temperature. You can also, in most PID loops, put a a tolerance on the measure variable that inhibits changes within that tolerance zone. Try using a broad tolerance to start with to get stability, and then tighten up.
 
Ron your assumtions as to being new to pid tuning is correct. This has been a working system for a while. It has always been a little unstable during start up and shut down but now with the new "efficient" gas valve stability takes about four hours after start up to be reached. The managers what that time cut down. Thanks to your information I have at least a direction to head I really aprieciate it.

Thanks Guys 🍻


PID #2 Gas valve
XIO T228:1/DN TON T228:1 0.01 100 27
XIC T228:1/DN PID N229:30 N201:9 0 N56:30 72 0 188 200 10 1 0 302 32 0 63 100 0 20 183 5 63 19814 60485 1 54454 63892 188 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

PID #5 Chamber Pressure
XIO T228:4/DN TON T228:4 0.01 100 37
XIC T228:4/DN PID N229:120 N201:6 0 N203:43 40 0 1843 100 10 1 0 64936 400 0 0 100 0 5 65496 65526 73 19853 3146 65492 1346 187 1843 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
So how do you slow down an analog PID guys?

The goal of a PID designer is to make the digital PID control as smoothly and with as little phase shift as a and infinite update rate analog PID.

A properly written PID uses the update rate to scale the integrator and differentiator gains so PID works amlost the same whether updating every 10 or every 20 milliseconds. Obviously the 10 millisecond PID update will work better due to lower phase delay, more PV samples, and better integration of error.

If other the PLC5 doesn't scale the Ki and Kd gains by PID update time then Ron and Tom are right. Otherwise.....

The real problem is the DELAY or DEAT TIME ( WHERE IS THE DEAD TIME PARAMETER? ) between changes in the PV after the CV changes. This is often the problem is common in a process where there is a distance between where the PV sensors are and where the CV actuator or hear is. To control these types of systems you must reduce the PID gains so the system doesn't saturate, especcally the integrator gain. This is really what Ron and Tom were trying to say. The problem with this is that response will be poor. If the SP changes often you must do more. One must use the PID offset or BIAS and a delay queue for the SPs which is outside the realm of PID 101.

This is NOT the type of system that rookies can tune properly. As state above, you must understand all the interactions or have a model of your system.

Ron and Tom, why is it that I never see 'slowing down' the PID as a solution in my control books, in PID manuals etc.

Sparky, find a expert in process PID controls. They are the ones that will not 'slow down' your PID.
 
Peter, I don't know why you don't see "slow down" in your books. I use "slow down" in two senses. First, it is a euphamism for reduced gain or less aggresive tuning. Not theoretically correct nomenclature, but it serves to communicate the concept, which is the objective.

Second I use it to actually mean "slow down" as in actually increase the time between loop updates. Agian, this anathema to theoreticions, and certainly isn't an elegant solution. However, if you have a very slow response system with a lot of process deadtime, it works. I don't care if isn't elegant, and I don't care if there are alternate techniques that will produce the same result. I do care if it works, because that is what buys the groceries.

Now, in my opinion, this temperature control loop is a lousy application for PID because of the long deadtime and high process capacity. I would use floating control, but I don't have the time or inclination to re-engineer Sparky's system. And lest you say that floating control isn't an elegant solution, in Process Instruments and Controls Handbook, 3rd Edition for slow processes they recommend multiposition time proportioning control on a slow load change, two position or two position with differential gap for fast load changes.

Peter, it is obvious from you many posts that you are much better at tuning PID than I will ever be. I am much better than most engineers, and infinitely better than a rookie or a typical operator. And I still hate tuning PID loops. And that is why I have often expressed the opinion that PID is a flawed control algorithm - the tuning is too abstract. The above referenced handbook has ten different tuning techniques, from Ziegler Nichols on up (or down)!
 
Peter,

No offense taken - but I never suggested "slowing down" the PID. In my opinion, the only time that that approach MIGHT be called for would be if a very long scan time was becoming an issue and we needed to "unburden" the processor. Specifically, why force the PID to calculate a new output several times each second - for something like a large heat loop which might only change temperature by one degree in 5 minutes? In that case, we might certainly want to “slow down” the PID by programming its "trigger" to fire at a much reduced rate. (Note to beginners: the extensive math involved in a PID instruction makes for a time-intensive load on the processor's scan time.) I’ll admit that some of that verbiage about the “loop update time” might have been confusing - but there was nothing there which was intended to advocate “slowing down [the execution of] the PID”. But I apologize if it seemed that way.

Anyway, if you’ve had time to look at Sparky’s PID rungs - you’ve probably noticed that they are (as I suspected) not “set up right” with respect to the “loop update times”. Specifically, each of his PID’s is set up with a timer done bit as a trigger (which in-and-of-itself is OK). These bits are set to fire once each second (which might be too slow). But when we look inside PID #2 (for the gas valve - control block at N229:30) we find that the loop update time is set for 0.20 seconds. The other PID #5 (for the chamber pressure - control block at N229:120) is set for a loop update time of 0.05 seconds. Neither of those loop update time settings is “correct”. Ideally, the trigger (or PID execution) time should match the loop update time on the setup screen. That’s what all of that rambling about the “paycheck” analogy in post #10 was about. Most beginners get this setting wrong. Sparky did too.

Side note to one and all: Yes, I know that it CAN be made to work this way - but the tuning values are all screwy. Before you try to “correct” me on this, please read the “paycheck” analogy in my previous post #10. And I’ve just knocked out about three more pages of “why and why not” for anyone who cares enough to ask for it.

Other things for Sparky to consider:

You’re only executing your PID’s once per second. You didn’t really answer my questions about the time between events on your system - so I have no way of guessing. Do you think that once per second is often enough? Hint: Changing the “loop update time” setting inside the PID will NOT make the PID execute faster or slower. The actual execution gets scheduled by the “trigger” - in your case, the timer done bit. Highly suggested: Whatever you set the trigger timer for, make the setting for the “loop update time” the same. Then do all of your loop tuning by adjusting the values for Kp, Ki, and Kd.

Also, you’re set up to use the AB or “Independent Gains” equation. If you want MORE integral action, then you need to INCREASE the setting for Ki. This is backwards from the ISA or “Dependent Gains” equation. There you have to DECREASE the setting (it’s called “Ti”)to get MORE integral action.

How often is your BTR (Block Transfer Read) executing to bring in your input data? If it’s not fast enough, then nothing you do with the PID will give you adequate control.

The same thing goes for your BTW’s (Block Transfer Writes) which take the PID’s output signals to the analog output cards. How rapidly are you executing them?

Do you know that the analog input signals - your Process Variables - located at N201:9 and N201:6 - need to be raw and unscaled for the best operation? In other words, they need to range in value from 0 to 4095.

I also notice that you are using an extremely small amount of derivative action. Suggestion: If you’re not sure of how to apply it, it’s best to simply turn this off. (Notice to one and all: I did not say anything bad about derivative action - it is GOOD stuff if you know how to use it. But for someone who’s just getting started and has his back against the wall, it’s better to simplify things by taking the derivative action out of the picture.)

In PID #2 (gas valve) you have the Derivative Input set for Error - for most systems you’ll get better results with this set for PV - as you have it in PID #5 (chamber pressure).

In your PID #5 for the chamber pressure - you have Setpoint Scaling turned off - yet you still have values entered for Max Scaled Input and Min Scaled Input. That looks real fishy.

In your other PID #2 for the gas valve - you have Setpoint Scaling turned on. What do the units 302 and 32 represent? Temperature? In Centigrade?

Good luck -
 

Similar Topics

Good Evening , I have a Conveyor system that requires Speed Cascading from one conveyor to another. Meaning that if one conveyor speed is...
Replies
10
Views
2,543
Happy Holidays Folks! I am working on a robot cell and as we are adding PLC control to the system, I have some questions about implementing an...
Replies
6
Views
4,668
I'm new to PLC. Have little knowledge of VFDs. I've 5 nos of Delta M series VFDs and all are connected to motors running the conveyor belts...
Replies
3
Views
2,837
Hello. I am a student doing an independent study on PLCs. I am using a Allen Bradley SLC 5/02. What I am trying to accomplish is to step a simple...
Replies
7
Views
4,197
I am wondering if its a good idea to cascade pid loops. For example If I want to control two variables Current and Voltage. If i can feed output...
Replies
4
Views
2,743
Back
Top Bottom