Rslogix5000 PID CV Low Limit adjusting

Hello,

I have a program that monitors pressure in a manifold discharge pipe. Pressure in the pipe should be less then 7.5 PSI. If the pressure is greater then 7.5 psi for 10 seconds, a 5% increase is added to the CV low limit for the air header valves. This effectively increases my CV by 5%. The problem is that this logic has a one shot, and 5 % may not always be enough to get that discharge pressure below 7.5. At less then 7 PSI for 10 seconds the original CV low limit value is placed back into the PID parameter. The pressure transmitter is not the PV for my PID that controls the air header valves. But it's monitored for safety.

A request has been made to continue to add 5 % increments until the pressure drops below 7.5 PSI. Because after this initial increase if it does not drop below 7.5 PSI it will not increase 5% again.

My first thought is to reset the timer that triggers the ONS and ADD statements.

Second, if the Pressure transmitter fails high I do not want to keep triggering the add statement that adds 5 % to the CV low limit. I was thinking of allowing the CV low limit a max of 95% in a GRT MOV clamp as a safety because I do not know what what happen to the PID if the low limit parameter exceeded the high limit that is set at 100% in some kind of weird situation . This is very a rare occasion when the system pressure goes above 7.5 usually if a DO probe fails..

Can anyone give me clarity on the output low limit? Would this be considered railing?

If the pressure increased to the point where my low limit clamped at 95% the valves are in auto so my air handler valves would be opened at 100 % anyway.

Thanks.

I would not use the "CV Low Limit" for this, I would think the .BIAS value ( feedforward) would be a better choice.

You would need to take it out slowly after it's done it's job. Add it in then slowly subtract it out.

I'm sure others will comment on your method.

Feedforward or Output Biasing
You can feedforward a disturbance from the system by feeding the .BIAS value
into the PID instruction’s feedforward/bias value.
The feedforward value represents a disturbance fed into the PID instruction
before the disturbance has a chance to change the process variable.
Feedforward is often used to control processes with a transportation lag. For
example, a feedforward value representing “cold water poured into a warm
mix” could boost the output value faster than waiting for the process variable
to change as a result of the mixing.
A bias value is typically used when no integral control is used. In this case, the
bias value can be adjusted to maintain the output in the range required to keep
the PV near the setpoint.

Click to expand...

Since pressure is not your PV, but an external safety limit, you may consider putting the loop into software manual when your safety limit is exceeded, and then manipulate the CV directly via changes to the set output until it gets back into the acceptable control range. Once safely in range, you can then revert back to auto control on the PID. This SWM "override control" is really another loop, though it sounds like a fixed step of the CV over time to return to safe-zone control is acceptable.

Mispeld said:

Since pressure is not your PV, but an external safety limit, you may consider putting the loop into software manual when your safety limit is exceeded, and then manipulate the CV directly via changes to the set output until it gets back into the acceptable control range. Once safely in range, you can then revert back to auto control on the PID. This SWM "override control" is really another loop, though it sounds like a fixed step of the CV over time to return to safe-zone control is acceptable.

Click to expand...

I agree with this method. Because the other way, is that you are really arbitrarily enforcing a manual valve position...Your PID is just going to clamp to your CV low limit. The problem there is if you have an integral coefficient in the tuning, once the CV gets clamped, and the error continues to build, you may experience windup in the PID math, and once you're back into a safe range, take exceedingly long to unwind the error.

Thanks for the replies,

Mickey, I edited my original post to indicate my PV is not the PIT transmitter but a safety limit.

Pressure has gone above 7.5 PSI roughly 31 times in about 2 years based on a CTU so it is not a common occurrence.

At PSI 9 PSI the air compressor inlet guide vanes will lock into position and at 10 PSI they will start to close until the differential pressure is less than 10 PSI.

The air handlers use 3 PIDs that use DO Dissolved Oxygen Probes probes.

One of the air handlers always runs in Local 100 percent

The PACS use the Same DO probes to regulate blower speed.

I have attached a PDF screen shot of what I was thinking of doing. Have not implemented the changes to the existing program.

Changes to the existing program include the timer XIO DN bit to reset the timer Rung 1. The three (NEW) rungs to clamp the Min CV rungs 3, 4 and 5.

Mispeld / robertmee,

Once the PID locks in to the Low limit it no longer reacts to the calculates error correct?

The PACS use the same DO probes to regulate Blower speed. So I would think an increase in my DO reading because of the step increase of the Air handler should also have a adjustment in blower speed if the air handlers open suddenly.

So by windup I guess that would mean the PID would react to the error of the increased air flow to the DO probes and probably run at the minimum CVs while the excess pressure is released into the aeration tank.

The 2 PID controllers for the Air handlers do have a integral gain of 2.5 and 1.8.

So after pressure would drop below 7 PSI the original values of 35 % and 15 % would be loaded back to the two air handler PID controllers

Usually in Auto the two air handler PID controllers run at about 39% and 17% CV.

Thanks again for the replies,

I will look into all suggestions.

p_logix said:

Thanks for the replies,
Once the PID locks in to the Low limit it no longer reacts to the calculates error correct?

Click to expand...

This is correct, in that when the loop is in SWM it will hold the output (CV) at the last value written to the loop's SO tag. It does not calculate error, which was partly the intention because it avoids winding up the loop from the "artificial" CV limit.

From the context of the original note, it sounded like the strategy is to "back off" the CV when exceeding the pressure limit. Going to manual is one option.

The downside of going to manual is a some complexity going back to auto. Presumably your PV and SP will start to deviate while the loop is clamped due to the pressure limit. You will have to decide whether to assign the SP equal to PV when taking out of SWM (for bumpless) or attempt to resume control with possibly a big bump. Depending on what is responsible for the pressure problem, the latter could result in oscillating between manual and auto with undesirable action on your PV.

Mispeld said:

This is correct, in that when the loop is in SWM it will hold the output (CV) at the last value written to the loop's SO tag. It does not calculate error, which was partly the intention because it avoids winding up the loop from the "artificial" CV limit.

From the context of the original note, it sounded like the strategy is to "back off" the CV when exceeding the pressure limit. Going to manual is one option.

The downside of going to manual is a some complexity going back to auto. Presumably your PV and SP will start to deviate while the loop is clamped due to the pressure limit. You will have to decide whether to assign the SP equal to PV when taking out of SWM (for bumpless) or attempt to resume control with possibly a big bump. Depending on what is responsible for the pressure problem, the latter could result in oscillating between manual and auto with undesirable action on your PV.

Click to expand...

Just to clarify, if you leave the loop in Auto and the output clamps to the CV, it will continue to windup if you have an integral coefficient. That's because the math is a function of error over time, and since the error is still there, it will still accumulate. That's why we were suggesting putting the loop into manual. If you are running a pure P loop (Gain only), then it won't be a problem.

robertmee said:

Just to clarify, if you leave the loop in Auto and the output clamps to the CV, it will continue to windup if you have an integral coefficient. That's because the math is a function of error over time, and since the error is still there, it will still accumulate. That's why we were suggesting putting the loop into manual. If you are running a pure P loop (Gain only), then it won't be a problem.

Click to expand...

Please read an except from the manual, about wind-up and bumpless transfer.

Mickey said:

Please read an except from the manual, about wind-up and bumpless transfer.

Click to expand...

Mickey, I have read that before, about clamping the windup at CV, but in my experience on hundreds of PID's in Logix, it's not true. I've had processes where the Min/Max are set to 0 and 100%. Valve opens to 100 quickly trying to drive CV to setpoint and the temperature never gets to setpoint (these are on hot oil loops...could be the supply loop is cold). I can guarantee that there is windup, because once the temperature finally exceeds SP, the output doesn't drop...for a LONG time. If I change the Integral to 0 (eliminating it), CV immediately starts to drop as expected due to the Gain. I've always attributed it to windup, regardless of what the manual says. If you can clarify what's going on, or correct my understanding, I'm all ears And note, this isn't integral accumulator during the time from X to 100. Usually takes less than 20 seconds to do so. But it can take 20 minutes to unwind, if I leave the integral alone.

PS....I've never understood this passage: "The accumulated integral term remains frozen until the CV output drops below its maximum limit or rises above its minimum limit."

Once the CV reaches 100, and the integral is locked at whatever value it is, then it's saying the only way to get CV back below 100 is by the gain. Well, what if the gain is less than the accumulated integral. It's never going to drop below 100.

I've always attributed it to windup, regardless of what the manual says. If you can clarify what's going on, or correct my understanding, I'm all ears

Click to expand...

Hopefully the AB and PID gurus will jump in and have their say.

PS....I've never understood this passage: "The accumulated integral term remains frozen until the CV output drops below its maximum limit or rises above its minimum limit."

Click to expand...

To me that's anti-reset wind-up.

1. PID vs PIDE.
It is important to distinguish that you are using the PID instruction, not the PIDE.
I have included a link to the manual, it is on page 6 1756-RM003 - Rockwell Automation

2. MINO vs MINCV.
MINCV, which you are using, is like a conversion to engineering units. If you were to raise your MINCV to 50%, your controller gains will be twice what they were.
MINO is the value before the engineering conversion. Changing this value will not change your CV, unless your CV is below min. It will also not effect your controller gains.

3. Anti reset windup.
It has been discussed that if your output travels beyond the MINCV, that your integral term will continue to integrate. This is not the case with the PID instruction as it has anti reset windup built into it.

4. Bias term.
This adds a fixed percent to your output. The problem is when you go to take it away. The other problem is that your controller can simply override the bias over time.

5. My suggestion.
Implement a maximum select, which sets your final value to the maximum of your PID CV or your previous CV value + 10%/10s * sample period
I can't see how to do this other than setting MINO to CV + sample period.
When you are safe again, you can either set MINO back to zero, or slowly bring it back to zero by doing MINO = MINO +recovery rate(%/s)*sample period

Robertmee, I will run some tests on the anti reset windup when I get back in on Monday. I have always been a fan of the incremental form of the PID algorithm used in the PIDE instruction.

AustralIan said:

Robertmee, I will run some tests on the anti reset windup when I get back in on Monday. I have always been a fan of the incremental form of the PID algorithm used in the PIDE instruction.

Click to expand...

That'd be great! I've struggled with this phenomenon over the years, and had read the same document over and over that Mickey linked. But I've literally done hundreds of temperature control loops and have witnessed this non anti-windup first hand. I'll be the first to wish you show me the error of my ways. I have nothing to gain by not learning something new.

Mickey said:

" The accumulated integral term remains frozen until the CV output drops below its maximum limit or rises above its minimum limit."

To me that's anti-reset wind-up.

Click to expand...

You would think....However, let's say that your CV is being driven to your SP, and by the time CV gets to 100%, the Integral portion is at 1.5 (the math, not the actual gain), because it's accumulated over time. Now, suppose your P Gain is only 1. No matter the error, the 1.5 will always overcome the 1 and the CV will never fall, and the Integral is locked in at 1.5 so it's not going to get any smaller. That could explain what I've seen all these years. I have witnessed:

PV at 200 degrees
CV at 0 %
SP at 500 degrees

Put loop into Auto

Takes awhile for CV to get to 100%
PV at 400 degrees (someone turned off boiler)
Fix boiler
PV at 550 degrees
CV still at 100%
10 minutes later
CV still at 100%
PV still at 550 degrees or better

Change Integral to 0
CV goes to 0%

So, the supposed non-anti windup, or frozen integral or whatever you want to call it, is overcoming the P and keeping the valve open...for what seems like forever. These are 1000ms update loops BTW, if that matters.

It seems like constraint control (or override control) might be the most appropriate solution to your problem. This can be very cleanly implemented if you can use the PIDE function block. See the section on 'multiloop selection' here: http://literature.rockwellautomation...p008_-en-p.pdf