Heater PID operation during cooling phase

Am programming a PID for a heater controller which works OK in the heating phase, but when the setpoint drops and it is passively cooling
(at a fairly fast rate due to a fixed refrigeration scheme), there is a large undershoot.
I am guessing the PID operation is not appropriate until the lower setpoint is close, and the PID is causing large undershoot due to the integral windup etc, I have tried limited windup on cooldown but doesnt seem to be optimal re minimizing undershoot when coming out of the passive cooldown phase.
Is there an alternate control mode one could switch to during passive cooldown that would be more sensible than PID as far as minimizing undershoot?
TIA!
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@yahoo.com wrote:

I don't think a different mode is called for. You should either consider the PID tuning, or you should examine the fine detail of the integrator anti-windup.
I suspect that when you say "undershoot" you mean it's going too cold, i.e. it's overshooting in the negative direction. I have found that if you implement integrator anti-windup by simply limiting the integrator value between some constants you almost guarantee overshoot (or what I think you're calling undershoot here).
I have found that a much better anti-windup scheme is to limit the integrator based on the proportional component and the integrator, i.e. if
output = integrator_state + kd * error
then limiting the integrator such that
min_output <= integrator_state + kd * error <= max_output, or
min_output - kd * error <= integrator_state <= max_output - kd * error
can be very effective in eliminating overshoot while still having otherwise snappy response from a PID controller.
--
-------------------------------------------
Tim Wescott
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Tim Wescott wrote:

Whenever the integrator disagrees with sign of the measured error (give it a wee bit o' slack), dump it.
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Jerry Avins wrote:

"wee bit" = enough to accomodate the noise in the input!
Actually, the method I cite above is also susceptable to noise, but not, I suspect, as problematical as yours. The nice thing about it is that when it comes off of saturation the integrator has a large negative componoent that's actively holding it back -- in a system that's tuned for critical damping or more this seems to (probably "does", but I haven't proven it) always prevent overshoot.
--
-------------------------------------------
Tim Wescott
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Tim Wescott wrote:

Not just noise, but possible oscillations not under the loops control.

I haven't gone there very often -- not at all since retiring -- because I use Phelan's approach by preference. With all the embellishments that can be digitally be hung on in PIDs, the two come out about the same place, but Phelan's approach is more straightforward. For second-order systems, it has inherently no overshoot. Instead of dumping the integrator, it is bounded to just keep the output from saturating. In a way, the bound is dynamically adjusted depending on the input.
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Jerry Avins wrote:

Actually I'm fairly sure that the approach I outline above and Phelan's approach are either exactly or very nearly equivalent.
--
-------------------------------------------
Tim Wescott
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Allsorts of possibilities here. You do not say what the controller is manipulating, but there is quite likely a difference in gain between heating and cooling systems. It may be appropriate to have some form of gain compensation. You might characterise the output to achieve this. Presumably you have a split range output? Is the proportional response to set point change enabled/disabled?
H.T.Dearden Time Domain Solutions Ltd www.tdsl.org.uk
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Several companines, Yokogawa, specifically make heating/cooling controllers. The Yokogawa has separate tuning for each half of the cycle. MAy be of some use to you. 1/8 DIN size if I remember correctly.
wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi, Use different PID parameters for haeting and cooling phase.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.