Problems with PID loops

All-

I was hoping you could shed some light on the PID instruction. I have done a lot of research but I still have some gaps in my understanding.

Here is the situation:

We have 2 lines that are mixing fluids of different viscosity at a junction. The liquids are then blended via a static mixer and sent to the filler stations. One of the liquids is is a large vat, and the other liquid is in totes that are pressurized. The totes are swapped out every couple hours. At the end of the day, the lines are CIPed.

Here is how the program works

Each flow is controlled by a PID loop. The operator sets the flow rate for the liquid coming for the large vat, and the ratio that will calculate the addition of the second liquid.

The problem that is occurring is in the morning when both lines have been cleaned, and the CV has been zeroed (via MOV instruction). The liquid pumps are both primed to verify that there is satisfactory flowrates. When the PID instruction begins to execute, ~ 20 gallons of product must be dumped because the PID takes awhile to setting down. During tote exchanges the PID loop settles down extremely quickly. It is like it starts up where it left off.

I have tried forcibly changing the pump % to a value that is close to the operating condition only during startup, and then hoping that when the PID takes over it will need little adjustment. The flowrates get into the ballpark this way, however once the PID loop takes over, the flowrates vary pretty drastically until it is finally settled in.

I have the PID instructions in a periodic task that scans every 250 ms. I really appreciate the help, please let me know if you need more information.

During tote exchanges the PID loop settles down extremely quickly. It is like it starts up where it left off.

Click to expand...

Can you duplicate the conditions at tote-change for the morning start-up, maybe not zero the CV?

The I and specially the D parts of a PID computation depend on past events. If there are no past events (at morning start-up) then it will work differently for some time period. This may be partially offset by retuning the PID loop with different I and D parameters.

You are trying to control flow by varying pump speed? Is that correct? What is your feedback signal? You should be able to get by with just a PI controller, but be sure you can reset the I component when you start. I bet you can fix your issue by decreasing P and increasing I. And I don't mean by just small amounts.

Blending application....

Firtly, is it important to match the flowrates instantaneously, or is it important that the volumes are "in ratio" over a specific time?

Since you used the phrase "periodic task", I will assume you are using a Logix5000 controller, e.g. ControlLogix, CompactLogix, FlexLogix, DriveLogix, GuardLogix, SoftLogix.... ??

plc.ucd said:

The problem that is occurring is in the morning when both lines have been cleaned, and the CV has been zeroed (via MOV instruction)

Click to expand...

Why is the CV zeroed ? The very first time the PID instruction is executed in automatic mode it will write the CV from the result of it's own calculation.

plc.ucd said:

When the PID instruction begins to execute, ~ 20 gallons of product must be dumped because the PID takes awhile to setting down

Click to expand...

Which PID takes a while to settling down ? The Vat flowrate, or the tote additive ?

plc.ucd said:

Each flow is controlled by a PID loop. The operator sets the flow rate for the liquid coming for the large vat, and the ratio that will calculate the addition of the second liquid.

Click to expand...

What do you use as the SP for your additive loop, the calculated SP, or the PV of the primary loop (Vat)

plc.ucd said:

I have tried forcibly changing the pump % to a value that is close to the operating condition only during startup, and then hoping that when the PID takes over it will need little adjustment.

Click to expand...

That's a common solution to overcome badly adjusted PIDs. Do you think you can do a better job than a properly constructed and tuned PID controller.

plc.ucd said:

The flowrates get into the ballpark this way, however once the PID loop takes over, the flowrates vary pretty drastically until it is finally settled in.

Click to expand...

Be more specific, you say "the flowrates" - do you mean both PIDs are fluctuating ?

plc.ucd said:

I have the PID instructions in a periodic task that scans every 250 ms.

Click to expand...

Excellent, but have you written the periodic task repeat rate into the .UPD element of the PID instruction tag? It is important that the PID calculation knows the time period between executions.

I agree that a D term may not be required in this application.

Firtly, is it important to match the flowrates instantaneously, or is it important that the volumes are "in ratio" over a specific time?

In the long run it is better to have the volumes in ratio, however it would be great to get match the flowrates as soon as possible. Usually once the flowrates are matched they are practically constant for the during the fill cycle.

Since you used the phrase "periodic task", I will assume you are using a Logix5000 controller, e.g. ControlLogix, CompactLogix, FlexLogix, DriveLogix, GuardLogix, SoftLogix.... ??

Yes, we are using ControlLogix.

Why is the CV zeroed ? The very first time the PID instruction is executed in automatic mode it will write the CV from the result of it's own calculation.

During the CIP, there is a MOV instruction that sets the CV value for both pumps at 100. After the CIP is completed, another MOV instruction sets the CV values to zero.



Which PID takes a while to settling down ? The Vat flowrate, or the tote additive ?

It is Vat flowrate that varies a lot. The set point is usually at 12 gpm, however in the morning, the flowrate get fluctuate between 19 gpm and 10 gpm until it settles in at the 12 gpm set point. It usually takes about 20 gallons of product to get to this steady state.



What do you use as the SP for your additive loop, the calculated SP, or the PV of the primary loop (Vat)

It is the calculated SP,

CPT(FIC2528.SP,FT2527_SP(FT2528_Ratio_Entry/100)*100)

FT2527_SP is the setpoint from the Primary loop.

Be more specific, you say "the flowrates" - do you mean both PIDs are fluctuating ?

Mainly, the Vat loop varies the most. It seems like it overshoots the setpoint quite a bit. See above.

Excellent, but have you written the periodic task repeat rate into the .UPD element of the PID instruction tag? It is important that the PID calculation knows the time period between executions.

I have set the Loop Update Time to match the period task scan time at 0.25 secs.

Thanks for all the replies. I really appreciate it. Hopefully this reply answers the question that were asked before dada's reply.

Also Lancie,

I am curious as to how long the PID instruction "holds on" to the events. Is there a way to specify this. Could I somehow how retain the events from the night before?

OK, I'm gonna jump right in and say....

1. The Primary loop (Vat Flowrate) needs tuning badly (I'll rephrase that, it badly needs tuning - it is already badly tuned). It should not take nearly 2 minutes to get this loop under control. I always aimed get flow loops to SP within 1 second, (and no overshoot). I sometimes had to settle for slower if the pump had a large inertia. I would hazard a guess that your pump drives have Acceleration and Deceleration Ramps programmed into them. My first job on many commissioning jobs was to remove all of them, PIDs fight against them.

2. If you slave the secondary loop off the PV of the primary, then (and I assume the secondary loop also has good tuning), you would not need to dump the first 20 gallons of (expensive?) product. Even if the primary loop varies from setpoint, the secondary loop will track the PV, and produce the correct blend ratio. Remember, it is the product flowing in the pipe that you are blending into, not a figure that you'd like the flowrate to be.

3. Lancie1's comments about "past events" may have misled you. The PID instruction has no memory, other than the values it was working with the last time it was scanned, and an accumulation of SP to PV error (integral). It performs calculations based on what has changed between scans, that it why it is important that the PID is scanned at a constant time period.

4. Another good trick with fixed-SP loops is to continuously track the CV into another register, freezing the value when the loop is disabled. You can then start the next run in manual at that CV, wait a few seconds for the PV to get near, and then engage auto. You can have much tighter tuning control doing this. I wouldn't recommend it if the SP gets changed often though.

Lancie1's comments about "past events" may have misled you. The PID instruction has no memory, other than the values it was working with the last time it was scanned, and an accumulation of SP to PV error (integral).

Click to expand...

Yes, the Integral term is based on the sum of PAST errors, therefore it is a type of memory (although not user-accessible, so can cause problems where the PID is turned off for some time period and the past error accumulation is deleted).

Don't forget the Derivitive term, which is the rate of change of the PAST errors. If the rate-of-change of past errors is deleted, that can also cause the PID to start all over again.

Lancie1 said:

Yes, the Integral term is based on the sum of PAST errors, therefore it is a type of memory (although not user-accessible, so can cause problems where the PID is turned off for some time period and the past error accumulation is deleted).

Don't forget the Derivitive term, which is the rate of change of the PAST errors. If the rate-of-change of past errors is deleted, that can also cause the PID to start all over again.

Click to expand...

Neither the Integral accumulation, nor the Derivative memories are user-accessible. And there is no way to restart a loop "from where it left off". Switching away from "Auto" will clear the internal accumulators. Every start is a new one.

Every start is a new one.

Click to expand...

Exactly right, and that can cause problems for many processes. I have used different PID settings for a furnace start-up, then later switched to another set once the process stabilized. No matter how well it was tuned, with a temperature range of 65 to 1800 degrees, the temperature could not be stabilized at 1800 (+ or - 1 degree) with the same tuning factors that were used from 65 to 1800. Tuned to maintain +/- 1 degree at 1800, then restarted at room temperature, the gain would be too small to reach 1800 in a 4-hour time period.

Lancie1 said:

Exactly right, and that can cause problems for many processes. I have used different PID settings for a furnace start-up, then later switched to another set once the process stabilized. No matter how well it was tuned, with a temperature range of 65 to 1800 degrees, the temperature could not be stabilized at 1800 (+ or - 1 degree) with the same tuning factors that were used from 65 to 1800. Tuned to maintain +/- 1 degree at 1800, then restarted at room temperature, the gain would be too small to reach 1800 in a 4-hour time period.

Click to expand...

This can be a problem with loops that have to work in a tight "bandwidth" - where the range of the feedback is very large - you quote a good example.

In these cases I would just turn on the heating until the PV is close (depends on inertia), then enable PID control. I would not need to mess with PID terms for the initial "warm-up".

In your quoted example I'd just go full-on until the furnace reached 1600 or so

There are motor drives are PowerFlex 40s and the accel/decel parameters are set at 5 secs (registers P039 and P040) for both the main and the addition. It looks like I can bring them down to 0.1 secs, but doesn't that risk damaging the drives as the are rapidly accelerating / decelerating without any ramping? These parameters were configured a long time ago by a different control engineer.

Also, the tuning constants are

Main:
Kc : 0.7
Ti: 0.08
Td: 0.0

Additive:
Kc: 1.0
Ti: 0.08
Td: 0.0

Thanks again

I have know idea why there are such limitations on the Rockwell PID. I am a BIG believer in using feed forwards to estimate the control output necessary to achieve the desired goals WITHOUT using a PID at all. When the feed forwards do a adequate job of "estimation or prediction" then add the PID to correct for small errors.

This can be implemented by using the feed forwards as a BIAS for the PIDs. It should be easy to change the biases in a way that maintain a ratio.

There are two active threads now that deal with PIDs and ratios. In both cases I think that these applications have been made more difficult than necessary.

The poor tuning and lack of access to variables is a different problem. I don't think anybody should be suggesting tuning parameters until we see a trend.

Definitely need to see a trend, when you say

PID takes awhile to setting down

Click to expand...

is it slow to bring the process up to setpoint, lots of fast oscillation around setpoint, few big slow oscillation around setpoint?

also how viscous is the fluid and what are the flow rates at normal operation.

just trying to look at it from a process perspective first and not so much a PLC PID issue.

As Peter said before anyone can make tuning suggestions a trend is needed.

It is a thick fruit jam, that is added to milk line. The goal is to have the milk line run at ~14 gpm and the fruit addition run at about 21.5% of the milk flowrate(~3 gpm). I can get the flowrates of each liquid right before the junction.

There is a pretty large overshoot in the milk line during startup. It will ramp up to 19gpm and then dip back to 10gpm. Small oscillations around the setpoint would be better suited for this application. Also, I will post a trend tomorrow.

One question regarding the behavior of the PID instruction. What happens when the input (XIO instruction) goes low? do the registers that contain the calculated error clear? Does the PID instruction retain any of information from the previous execution. This input goes high and executes the PID instruction several times a minute for riughly 15-20 secs, and then goes low. Also, could I use the .SWM bit for the move instructions that force the CV to 100% to backcalculate the error?