Slow Acting Long Time Interval PID Tuning

GrizzlyC

Member
Join Date
Feb 2021
Location
Alberta
Posts
28
Hello,

I have a issue with tuning a slow acting PID loop using AB PIDE instruction. The system is designed to cool a tank after it heats up using a proportional valve that allows glycol to circulate through the tank.

My main issue is that the CV does not begin open to allow cooling until after the PV has passed the SP and does not start to close until after the PV has fallen below the SP. This creates an oscillation that wont correct its self over time.

If attached a picture to show what is happening in the tank right now. The time span is 24 hours For clarity this is the legend.

Blue = Tank Temp (used in the PID loop)
Purple = Secondary Tank Temp (not used in the PID loop)
Red = Setpoint (12C)
Orange = position of glycol valve (its stepped in 1% intervals)

I have a basic tuning parameter already set, information below.

P = 5
I = 8
D = 1.5
Execution Time for PID algorithm = 45 seconds
deadband = 0.01

Control Action = Direct acting (PV-SP)
Gains Equation = Dependent

I'm looking to make the system more predictive to throttle back the valve before the PV goes below the SP line. Any help would be greatly appreciated.

All the best,

Tuning Loop.PNG
 
With dependent gains PIDE, the integral term is in units of minutes/repeat. In that configuration, one starting point for tuning a first order system is to use the open-loop time constant as the integral setting.

Based on the trend chart of closed-loop response, it appears that 8 minutes much too fast for this loop. I would recommend increasing this value (for less integral) -- maybe as much as 120 minutes and see if it tamps down the amplitude of the oscillation.

In an ideal situation, you would put the loop in manual and make a step change to observe the response and compute the actual time constant and process gain. It is understandable that it might not be possible to run an open loop test with a process like this.
 
The deadtime is so long because the glycol valve is is cooling a tank via 2 cooling jackets with 11000L of media inside and the temperature sensor is located between the two jacket rings. The tank will naturally heat its self up over time.
 
Hello,

I have a issue with tuning a slow acting PID loop using AB PIDE instruction. The system is designed to cool a tank after it heats up using a proportional valve that allows glycol to circulate through the tank.

My main issue is that the CV does not begin open to allow cooling until after the PV has passed the SP and does not start to close until after the PV has fallen below the SP. This creates an oscillation that wont correct its self over time.

If attached a picture to show what is happening in the tank right now. The time span is 24 hours For clarity this is the legend.

Blue = Tank Temp (used in the PID loop)
Purple = Secondary Tank Temp (not used in the PID loop)
Red = Setpoint (12C)
Orange = position of glycol valve (its stepped in 1% intervals)

I have a basic tuning parameter already set, information below.

P = 5
I = 8
D = 1.5
Execution Time for PID algorithm = 45 seconds
deadband = 0.01

Control Action = Direct acting (PV-SP)
Gains Equation = Dependent

I'm looking to make the system more predictive to throttle back the valve before the PV goes below the SP line. Any help would be greatly appreciated.

All the best,


I don't tune loops. I don't *GET* the whole process. So the discussion below follows NO RULES AT ALL. Just 30 years of occasional observation.


Where the temperature changes slowly and the control variable takes a while to show any change at all... particularly on a long time constant ... I would drop your Kp to maybe 1, your Ki is OK I think, Kd to 30, and your execution time closer to 300 seconds.


If the temperature takes that long to see any change, there is no point letting the outputs execute and 'wind up'. If I read your graphs correctly, the delay between control output and result is at least 3 minutes?


Having your control valve go 'digital' and do full open for 5 minutes, then full closed after the temperature starts to change ... is likely OK. It's the PWM version of PID control :D
 
I have not touched the integral time since I started tuning the PID. Increasing the I mins will certainly dampen the oscillation but in the very long term will it also help to make the system more predictive?
 
Not my forte...

Predictive would be a feed-forward, wouldn't it? I don't think any Integral term will achieve this. You would need something to signal the next change in temperature before it happened. This might able to be achieved with the parameters, or maybe an external sensor upstream of the process.
 
Based on the trend chart of closed-loop response, it appears that 8 minutes much too fast for this loop. I would recommend increasing this value (for less integral) -- maybe as much as 120 minutes and see if it tamps down the amplitude of the oscillation.

Ill take Mispeld advice and crank the I parameter up to 120 as a start. I can also play with the feedforward control although I would need to create the correct formula in order to predict the changes correctly.

Since it take a day for the tank to show a consistent response on the trending Ill post the results late tomorrow.
 
I have not touched the integral time since I started tuning the PID. Increasing the I mins will certainly dampen the oscillation but in the very long term will it also help to make the system more predictive?

With better tuning it could appear more predictive because there will not be so much overshoot from the integral term. Based on the description of the process and the one trend chart there will be a few challenges (1) pure dead time, (2) long process lag, (3) relatively small process gain.

It can be difficult to sort out (1) from (2) when all you have is closed-loop response. Pure dead time (aka transport delay) is the time it takes for a change in the CV (e.g., valve) to cause any movement in the PV (e.g., temperature). If this time is similar or greater than (2), it will be difficult to get good control without adding an explicit prediction algorithm (e.g., Smith Predictor, model-based control).

Process lag is the time it takes for the PV -- of a first order, non-integrating process -- to reach about 63% of its ultimate response to a CV change once the PV starts changing. You can have very good performance if response is dominated by lag (as opposed to deadtime) and disturbances (external impacts on PV) are not unreasonable.

Your deadtime will be determined by the pipe distance between the control valve and coil, and the fluid velocity. There will also be a component related to heat transfer through the coil and fluid to reach the temperature sensor. This could be reduced with active mixing in the tank as opposed to just heat conduction and convective mixing. Locating the valve closer to the tank is beneficial to reduce the transport aspect, but I'm guessing it is not far enough away to make a big difference.

The lag will have more to do with the fluid volume, heat capacity, glycol/process temperature difference, heat transfer effects (glycol flow, coil details), tank insulation, mixing, etc. Long process lag is not necessarily bad like long deadtime; it can oftentimes be dealt with effectively.

Process gain looks reasonable, but under the (external) conditions when the trend chart was made, the valve is operating close enough to zero such that it fully closes during the oscillation. This is making matters worse from the oscillation standpoint (e.g., average is not at target), but with better tuning it may be able to come off of zero and hover around 4%. Still quite close to one end, but needs to be considered in the context of all external operating conditions.

When I look at the trend and see the PV change direction shortly after the CV reaches zero, my inclination is to think that there might not be too much pure deadtime. If true, and the CV has room to work, it could very well be possible to significantly reduce or eliminate the amplitude of oscillation.

One watch-out is an oscillating external disturbance that overwhelms the control action capability. In that case, it may be a matter of chasing that disturbance with as much active control as possible to dampen its effect. But the cycle may still be significant and require feedforward action if it can be measured and the process model is known and well-behaved.

Last comment is about derivative action. You may be better off without it, even though the gain is so small in that its effect is marginal at these settings. That is especially true if it is the reason for the deadband, which looks like it may be contributing to the stepped CV action. It would be much better if the CV were moving smoothly through the control range instead of stepping by what looks like 1% increments.
 
@GrizzlyC: One follow-up questions: What are the PIDE configuration values for CVEUMin and CVEUMax?

I ask because the P gain is based on the input range, not directly engineering units. The trend period looks long enough to give some hint about an appropriate P gain, knowing the input scaling values.
 
[Update: combined three posts into one]

1) Is the output clamping happening in the PIDE or is it external (to the PIDE)? If the latter, the PIDE does not know it is being clamped and so (I think) it generates additional wind-up.

2) This is also suspect and a possibly a design issue i.e. measuring the temperature of something (or more specifically, at a location) that is being actively cooled.

... and the temperature sensor is located between the two jacket rings. ...

3) Also, what is an acceptable deadband around the temperature setpoint? is it more than the measurement noise?
 
Last edited:
With better tuning it could appear more predictive because there will not be so much overshoot from the integral term. Based on the description of the process and the one trend chart there will be a few challenges (1) pure dead time, (2) long process lag, (3) relatively small process gain.

All this information is very useful to understanding my process here.

The pure dead time is regrettably an unchangeable variable is this scenario. I must depend on thermal conduction to heat or cool the tank as using an agitator is not practical for this application.

In this closed loop scenario I should not have to work about an external disturbance changing the PV and resulting in unpredictable outputs.

I agree that derivative action may not be required here as at higher D numbers it tends to results in very temporary spikes in CV output when ever the PV changes 0.01 up or down.

Regarding the 1% increments. I have limited the output after the PID output to send whole numbers to the control valve as it tends to not move or get stuck in position if I send it micro increment adjustments. (this is a 4-20ma valve)

I'm interested in your comment about how " there might be too much pure deadtime. If true, and the CV has room to work it could very well be possible to significantly reduce or eliminate the amplitude of oscillation." Can you expand on this topic. I have the valve go to complete closed position 4ma when at 0%CV to ensure the valve is closed and move it to 7ma at 1%CV to just barely crack it open and proportion it up from there in small increments as it is a ball valve.

Also do you think that it worth my time to come up with a feed-forward formula to bias the valve as it approaches the SP. It would be the first time I messed with something like that in my automation career but I hear It can be quite useful for control applications with long pure dead times.

I appreciate the help your giving me on this topic:)
 
@GrizzlyC: One follow-up questions: What are the PIDE configuration values for CVEUMin and CVEUMax?

I ask because the P gain is based on the input range, not directly engineering units. The trend period looks long enough to give some hint about an appropriate P gain, knowing the input scaling values.

CVEUmin = 0
CVEUMax = 100

valve full range open and close for 4-20ma
 

Similar Topics

Hey guys, I have a Controllogix and I am tying to control a PID loop for Chlorine (CL2). The trouble is the mixing point is 15 minutes away from...
Replies
16
Views
6,716
Hi All, we've recently upgraded from FTView SE v10 to v12. Since the upgrade we've been having a problem where the HMI is slow to update tags in...
Replies
0
Views
38
Hi, I have some problem with View Point which I'm using to manual control of conveyors. On begin when in network was only PLC and HMI View Point...
Replies
0
Views
62
Hi. Importing a 2014 aapck in 2023: no problem using it, adding windows, works very well, no problem whatsoever. Creating a new project: as...
Replies
2
Views
707
I am having a weird experience using KepwareEx6 as an OPC Server for a set of SLC processors where the tag data is not updating remotely at the...
Replies
2
Views
530
Back
Top Bottom