PID for temperature control: measure the delay before you touch a single gain

The call I get about a heating loop is almost never "it doesn't work." It's "the autotune ran, the numbers look reasonable, and it still overshoots twenty degrees every startup." Usually nothing is broken. PID for temperature control fails in a very particular way, and it has little to do with picking a better proportional gain. It has to do with how long the process waits before it tells you anything at all. Here is what to measure first, what the arithmetic actually gives you, and the two vendor traps that quietly wreck good tuning numbers.

The delay is the whole problem

PID for temperature control has one real enemy and it isn't the gains. Open a valve on a flow loop and the flow transmitter answers in a second or two. Add heat to an element and nothing happens for a while. The element warms, that heat conducts through metal, through product, through whatever is between it and a sensor sitting some distance downstream. Meanwhile the controller is still integrating error against a process that has not answered yet, so it keeps asking for more. Every degree of overshoot you fight later gets bought during those seconds.

That gap is dead time, and it is separate from the process simply being slow. A slow process with almost no dead time is easy. Put a long transport delay on a fast one and you have a fight.

Worth knowing what the output is doing while this happens. Panel controllers with relay or SSR outputs do not modulate power, they chop it: the output toggles across a fixed cycle time and the duty cycle is the analog part. Thermal mass smooths it out, which is why it works at all.

I stopped touching gains before I know the dead time. Not because tuning by feel never works. Because on a heater you can burn a whole shift chasing a number the process was never going to accept.

Three numbers off a trend, then it's arithmetic

Before you tune PID for temperature control you need a bump test. It takes one step change and some patience.

1.    Put the loop in manual and let it settle, ideally somewhere near normal operating temperature.

2.    Step the output by a fixed amount. Ten percent is usually enough to see.

3.    Trend the PV until it settles at a new steady value.

4.    Process gain is the change in PV expressed as percent of span, divided by the change in output percent.

5.    Dead time is the time from the step until the PV has moved 2% of its total change.

6.    The time constant is the time from the end of dead time until PV reaches 63.2% of its total change.

The three numbers every PID for temperature control tuning method starts from. Dead time is the flat stretch after the step, before the PV admits anything happened.

Say the trend gives you this:

What you read off the trend	Example value
Output step	10%
Total PV change	15% of span
Process gain	1.5
Time until PV moves 2% of total change	5 s, that is dead time
Time from there to 63.2% of total change	15 s, that is the time constant

 

Now lambda tuning turns those into terms. Controller gain is the time constant divided by process gain times the sum of lambda and dead time. Integral time is just the time constant. Lambda is the closed-loop response time you are asking for, and you pick it: bigger lambda gives a slower, more forgiving loop, smaller lambda gets you closer to the edge. On a heater with real dead time, three times the measured dead time is a sane starting point.

Run the numbers above with lambda at 15 seconds and you get a controller gain of 0.5 and an integral time of 15 seconds. Defensible, repeatable, and you can re-derive it next year without re-running anything.

The closed-loop route, when you can't bump the process

Some processes you are not allowed to step, and PID for temperature control still has to get set. The closed-loop method works like this on a Eurotherm 3216: turn integral time and derivative time to Off, set both cutback values to Auto, then narrow the proportional band until the PV just starts to oscillate. Note that band as B and the period of the oscillation as T.

Control type	Proportional band	Integral time	Derivative time
Proportional only	2 x B	Off	Off
P + I	2.2 x B	0.8 x T	Off
P + I + D	1.7 x B	0.5 x T	0.12 x T

 

Most heating loops run fine on PI, and derivative is the first term I turn off when a loop starts getting jumpy. It earns its place on high-mass equipment where the lag is thermal rather than transport. On a noisy sensor signal it amplifies the noise instead of the trend, and you will see the output twitching for no reason at all.

Autotune, and what it actually does to your process

The autotune button is where most people start PID for temperature control, and the one-shot tuner behind it is neither passive nor magic. It works plainly enough: the controller switches the output on and off to force an oscillation in the measured value, then reads the amplitude and period of that oscillation to calculate the terms. It waits roughly a minute after you start it to establish steady state, and it does its work at about 0.7 of setpoint rather than at setpoint. If the process cannot take full heat you cap it with the output power limits, but the PV still has to move, or the tuner has nothing to measure.

That last line is why autotune stalls on well-insulated equipment more than for any other reason. Clamp the output too tightly and the tuner sits there waiting for an oscillation that never arrives.

Rockwell went a different way. The PIDE autotuner is open loop and built into the instruction itself, driven by an autotune tag of type PIDE_AUTOTUNE. Two catches. It ships with the software but needs an activation key before it will run, and the autotuner itself is function block only, not ladder, not structured text: that restriction is on the autotuner, not on PIDE, which runs fine in structured text once it's tuned. You can fire it from a PanelView or another operator interface, which is more useful than it sounds when the loop has to be tuned by whoever is standing at the machine.

Where PID for temperature control quietly goes wrong

Two things break more PID for temperature control loops than bad gains ever have, and both survive commissioning because the loop looks fine once it settles.

The first is span. PIDE does not work in engineering units, it works in percent of span. Here's the arithmetic: PVPercent is PV minus PVEUMin, times 100, divided by PVEUMax minus PVEUMin. The defaults are PVEUMin 0.0 and PVEUMax 100.0. Leave those alone on an oven that runs to 1500 degrees and every error the instruction sees is fifteen times larger than the real one. Your carefully calculated gains get multiplied by fifteen along with it. The loop drives to full output and holds it there long past the point it should have started backing off, which only shows up on startup and on big setpoint changes. Exactly when somebody is watching.

PID for temperature control starts at the input card. What the module reports and what PVEUMax says it means have to agree, or the gains are wrong before you tune anything.

The second is units, and this one crosses vendors. On a Eurotherm 3216, integral time is entered in seconds, anywhere up to 9999. Move to a Logix PIDE and IGain means one thing on the independent form and something else entirely on the dependent form. DependIndepend defaults to false, which is independent.

Term	Eurotherm 3216	Logix PIDE independent form	Logix PIDE dependent form
Proportional	Proportional band, 1 to 9999 display units	PGain, unitless proportional gain	PGain, unitless controller gain
Integral	Integral time, Off to 9999 seconds	IGain, in 1/minutes	IGain, in minutes per repeat
Derivative	Derivative time, Off to 9999 seconds	DGain, in minutes	DGain, in minutes

 

So an integral time of 300 seconds, carried across from a panel controller and typed straight into a PIDE, is not five minutes of reset. It is a different quantity in a different time base, and nothing on the screen warns you.

When the loop cannot be tuned out of it

Some heating processes carry more dead time than PID for temperature control can absorb on its own, and no set of gains fixes that.

Cascade is the usual answer, and the textbook case is exactly this: liquid in a tank heated by steam in a jacket. If upstream steam pressure sags, the tank temperature eventually drops and the loop reacts, late. Split it in two. The primary loop watches tank temperature and outputs a steam flow demand. Underneath it, a secondary loop watches steam flow and drives the valve. An upstream upset now gets caught by the fast loop before the slow one ever notices. The rule people break is this: the secondary loop must have a faster process response than the primary. Wire CVEU from the primary into SPCascade on the secondary, and set AllowCasRat on the secondary so it will accept cascade mode.

Cascade control on a steam jacketed tank. The fast flow loop absorbs the upset before the slow temperature loop ever sees it.

Feedforward is the other structural fix. If you know a disturbance is coming before it lands, inlet temperature, line speed, a cold charge dropping into the vessel, you can act on it instead of waiting for error to appear. In Logix that is the Lead-Lag instruction, LDLG, built specifically for feedforward PID control. Not available in ladder diagram, same restriction as PIDE, though both still run fine in structured text.

On panel controllers there is a cheaper fix for startup overshoot that has nothing to do with the PID terms at all. Low cutback is the number of display units below setpoint where the controller starts pulling output back on the way up, and high cutback is the mirror of that on cool down. Left on Auto they sit at three times the proportional band. Set them by hand instead, watch what a big step actually overshoots by, and shift the cutback value by that amount.

And then the option nobody wants to hear: PID for temperature control is not mandatory. If your product tolerates a few degrees of swing and there is real thermal mass in the system, an on-off controller with sensible hysteresis will hold it and will never need tuning again. Not every heater is a control problem.

Frequently asked questions

Can PID for temperature control work without running an autotune?

Yes, and on slow equipment it is usually better. A bump test plus lambda tuning gives you numbers you can defend and re-derive later. Autotune is faster, it just never tells you what it learned.

What are good starting values for PID for temperature control?

There are none that transfer between machines. The terms depend on process gain, dead time and span, and all three change with the equipment. Closest thing to a universal starting point is a lambda-tuned PI loop, with lambda set to about three times the measured dead time.

Why does PID for temperature control overshoot on startup but hold fine at setpoint?

Startup is the only time it sees a large step. Holding at setpoint needs almost no gain. Check the cutback settings and the span scaling before touching a single term.

Should I use derivative on a temperature loop?

Usually not. PI holds most heating processes. Derivative helps on high-mass equipment with genuine thermal lag and hurts on anything with a noisy signal.

Does moving the sensor help more than tuning?

Often, yes. Most dead time is transport delay between where heat goes in and where it gets measured. Moving the sensor closer changes the process itself, and no combination of gains can do that.

Getting the hardware right first

A tuning problem and a hardware problem look identical from the operator screen. Before you spend another shift on gains, check two things: that your input module resolves the band you are trying to hold, and that the controller in front of you supports the loop structure the process actually needs. Cascade, feedforward, or just a second control channel. A fair number of PID for temperature control jobs get solved by putting the right module in the rack rather than the right number in a parameter.

IQElectro stocks loop controllers, RTD and thermocouple input modules and universal process controllers, including older families that never got a drop-in replacement. A legacy loop can stay a legacy loop instead of turning into a migration project.