PID loop tuning basics: check the loop, step-test it, then tune with a trend you can trust

Picture a heat exchanger loop that's been "fine" for years. Then someone changes a pump, the outlet temperature starts swinging a few degrees either side of setpoint, and the operators put it in Manual and leave it there. The usual next step is somebody nudging the gains by feel until it looks a little better, without writing down what they started with.

This tutorial is the other way to do it: check that the loop can be tuned at all, measure how the process actually responds, start from gains you can explain, and keep a trend of before and after. It uses a heat exchanger outlet temperature (TT101) controlled by a hot water valve (TV101) as the example, but the same steps work for pump pressure, flow, and most temperature loops. Tank level is a little different, and we'll point out where.

What P, I and D do, in plain words

The controller looks at the error, the gap between setpoint (SP) and process value (PV), and decides where to put the output (CV), usually a valve or a drive speed.

• P, proportional: "how far off am I right now?" The output moves in proportion to the error. More gain means a harder push. P alone usually settles a little away from setpoint (offset), and too much P makes the loop oscillate.
• I, integral: "how long have I been off?" As long as there's any error, integral keeps adding to the output, which is what removes the offset. Too much integral (too short an integral time) makes slow, rolling overshoot.
• D, derivative: "how fast is it changing?" Derivative pushes against fast changes, like a brake. It can help some slow temperature loops, but it amplifies noise. Most flow, pressure and level loops run fine with D at zero, and that's where we start.

Almost every loop you'll meet on a plant floor is a PI loop. Get P and I right and you've solved most of it.

Check the loop before you touch the gains

No gain setting fixes a mechanical or signal problem; it only hides it until conditions change. Start here. Do all of this with the loop in Manual, with operations' OK and someone watching the process.

1. Valve or actuator stiction. Make small output steps, about 0.5–1% at a time, in one direction, then reverse. If the valve position (or the PV) doesn't move until a few steps pile up, and then jumps, the valve is sticking or has deadband. In Auto, that shows up as a PV that moves in squarish steps while the output saws up and down. That's a job for the valve packing or positioner, not for tuning.
2. Sensor noise. Hold the output still and watch the PV for a few minutes. If it jitters by more than the swing you're trying to fix, look at grounding, shielding, and the transmitter's damping before you filter it in the PLC. Filter lightly if you must: every filter adds lag, and lag is what makes loops hard to tune.
3. Scaling and units. Confirm the PV range in the PLC matches the transmitter range (what 4 mA and 20 mA really mean), and that 0–100% output really drives the valve closed-to-open. PIDE works in percent of span, so a wrong span means every gain you calculate is off by the same factor.
4. Direction. Decide which way the output has to move when the PV is below setpoint. For a heating valve, PV low means open more: error is SP − PV, which is PIDE's default (ControlAction = 0). A fail-open valve, or a cooling loop, may need the other setting. Getting this wrong makes the loop run away the moment you go to Auto.
5. Update rate. Run the loop in a periodic task that's fast compared to how quickly the process responds. For most temperature, level and pressure loops, a period in the 100–500 ms range is plenty; fast flow or pressure loops may want faster.
6. A manual bump. Finally, make one small step in the output and watch. Does the PV move the way you expect, by roughly the amount you expect, without a long wait? If it does, you're ready for the step test.

A simple step test

The step test gives you three numbers that describe the process. They come from the process, not from anybody's opinion, which is why they make a good starting point.

1. With the loop in Manual and the PV steady, step the output by enough to clearly see the PV move above the noise, typically 5–10%. Note the time and both values.
2. Wait until the PV settles at its new value. Note the new PV.
3. Step back, and if you can, repeat in both directions. If the results differ a lot, the process is nonlinear (valves often are), and you should tune for the range it normally runs in.

From the trend, read:

• Process gain K: the change in PV divided by the change in output, with both in percent. Convert the PV change to percent of the PV span: a 12 °F rise on a 0–200 °F transmitter is 6%.
• Dead time θ: the time from the step until the PV first starts to move.
• Time constant τ: the time from when the PV starts moving until it has made 63% of its total change.

Then pick a closed-loop time constant λ (lambda): how quickly you want the loop to bring the PV back to setpoint. That's the one tuning choice you make; the rest is arithmetic. A cautious first choice is λ equal to τ, so the closed loop responds about as fast as the open loop did. Faster loops (smaller λ) are tighter but less forgiving when the process changes; don't go below θ.

For a process that settles at a new value (most temperature, pressure and flow loops), Skogestad's SIMC rules give PI settings:

• Controller gain: Kc = τ ÷ (K × (λ + θ))
• Integral time: Ti = the smaller of τ and 4 × (λ + θ)
• Derivative: 0 to start

Source: S. Skogestad, "Simple analytic rules for model reduction and PID controller tuning," Journal of Process Control 13 (2003) 291–309. With Ti = τ these are the same as the classic lambda (IMC) tuning rules.

Tank level is different. A level with a pump or valve on the outlet usually doesn't settle at a new value after a step; it keeps ramping. That's an integrating process. Measure the change in ramp rate instead (percent of span per minute, per percent of output) and call it K′. The SIMC rules for that case are Kc = 1 ÷ (K′ × (λ + θ)) and Ti = 4 × (λ + θ). Many level loops are surge tanks where a slow, smooth level is the goal, so a long λ is often the right choice.

Starting gains are a starting point. Put the loop in Auto, make a small setpoint change, and watch the trend. If it's sluggish, shorten λ a little and recalculate; if it overshoots or rolls, lengthen it. Change one thing at a time, and write each change down (the Ignition section below does that for you).

In the PLC (Studio 5000 / Logix)

The example uses the Enhanced PID instruction, PIDE, the better choice for new work on ControlLogix and CompactLogix. It has proper operator and program modes, output limits, PV fault handling, and anti-windup built in. Older code often uses the PID instruction instead; that's covered at the end of this section.

Set up the PIDE once

These are set in the PIDE tag (or its properties dialog), not every scan. The values are for the example loop; use your own ranges.

The loop

Both versions below do the same thing in the same order, with the same tag names. Ladder is shown first. Switch to Structured Text if that's your plant standard.

XIC(S:FS)MOV(TT101_Raw,TT101_Filt);

CPT(TT101_Filt,TT101_Filt+FiltK*(TT101_Raw-TT101_Filt));

[XIC(TT101_ChFault),LES(TT101_Raw,TT101_BadLo),GRT(TT101_Raw,TT101_BadHi)]OTE(TT101_Bad);

[XIO(P101_Running),XIO(HX_Permit)]OTE(TIC101.ProgOverrideReq);

[MOV(TT101_Filt,TIC101.PV),XIC(TT101_Bad)OTE(TIC101.PVFault)];

JSR(TIC101_PIDE,0);

MOV(TIC101.CVEU,TV101_Out);

XIC(S:FS)MOV(TT101_Raw,TT101_Filt);
CPT(TT101_Filt,TT101_Filt+FiltK*(TT101_Raw-TT101_Filt));
[XIC(TT101_ChFault),LES(TT101_Raw,TT101_BadLo),GRT(TT101_Raw,TT101_BadHi)]OTE(TT101_Bad);
[XIO(P101_Running),XIO(HX_Permit)]OTE(TIC101.ProgOverrideReq);
[MOV(TT101_Filt,TIC101.PV),XIC(TT101_Bad)OTE(TIC101.PVFault)];
JSR(TIC101_PIDE,0);
MOV(TIC101.CVEU,TV101_Out);

(* TIC101_PIDE: structured text routine called by the JSR in rung 5 *)
PIDE(TIC101);

(* TIC101_Main: structured text routine in a periodic task (for example 100 ms) *)

(* 1. First scan: start the filter at the live reading, not at zero *)
IF S:FS THEN
    TT101_Filt := TT101_Raw;
END_IF;

(* 2. Light first-order filter on the temperature (FiltK 0 to 1, 1 = no filter) *)
TT101_Filt := TT101_Filt + FiltK * (TT101_Raw - TT101_Filt);

(* 3. Bad PV: channel fault, or a reading outside the transmitter's range *)
TT101_Bad := TT101_ChFault OR (TT101_Raw < TT101_BadLo) OR (TT101_Raw > TT101_BadHi);

(* 4. Process can't respond: hold the loop in Override at CVOverride *)
TIC101.ProgOverrideReq := NOT P101_Running OR NOT HX_Permit;

(* 5. Hand the PV and its health to the PIDE *)
TIC101.PV := TT101_Filt;
TIC101.PVFault := TT101_Bad;

(* 6. Run the PIDE *)
PIDE(TIC101);

(* 7. Send the output to the valve *)
TV101_Out := TIC101.CVEU;

What the pieces are doing:

• Bad PV goes to Manual. When PVFault is on, PIDE stops calculating and drops to Manual, holding the output instead of chasing a broken signal. Alarm on TT101_Bad so someone knows why.
• Anti-windup. PIDE uses the velocity form: it calculates a change in output each update and clamps the result at CVLLimit / CVHLimit, so integral can't pile up past the limits. The windup you still have to handle is the loop staying in Auto while the process can't respond (pump off, a hand valve closed). It ramps the output to the limit, and when the process comes back the valve slams. Rung 3 holds the loop in Override at a known output instead.
• Bumpless manual/auto. While not in operator Manual, PIDE keeps CVOper equal to the output, so going to Manual doesn't move the valve. Going back to Auto starts from the current output, and with PVTracking on, the setpoint starts where the PV is. The operator then moves the setpoint deliberately.
• Output limits. CVLLimit and CVHLimit apply in Auto. In Manual they only apply if CVManLimiting is on; decide with operations whether an operator should be able to go outside them.

Starting gains from the step test

You can do this math on a phone calculator. Putting it in the PLC means the step-test numbers, the starting gains, and the trend can sit on one Ignition screen, and nobody types a gain into the wrong box.

NEQ(StepCV,0)GRT(PVSpan,0)CPT(Proc_Gain,ABS(StepPV*100.0/PVSpan/StepCV));

GRT(Proc_Gain,0)GRT(LambdaMin,0)[ADD(LambdaMin,DeadMin,LamDead),CPT(Kc_Start,TauMin/(Proc_Gain*LamDead)),CPT(Ti_Limit,4.0*LamDead)];

[MOV(TauMin,Ti_Start),GRT(Ti_Start,Ti_Limit)MOV(Ti_Limit,Ti_Start)];

XIC(ApplyGainsReq)XIC(TIC101.DependIndepend)GRT(Ti_Start,0)[MOV(Kc_Start,TIC101.PGain),MOV(Ti_Start,TIC101.IGain),MOV(0.0,TIC101.DGain)];

XIC(ApplyGainsReq)OTU(ApplyGainsReq);

NEQ(StepCV,0)GRT(PVSpan,0)CPT(Proc_Gain,ABS(StepPV*100.0/PVSpan/StepCV));
GRT(Proc_Gain,0)GRT(LambdaMin,0)[ADD(LambdaMin,DeadMin,LamDead),CPT(Kc_Start,TauMin/(Proc_Gain*LamDead)),CPT(Ti_Limit,4.0*LamDead)];
[MOV(TauMin,Ti_Start),GRT(Ti_Start,Ti_Limit)MOV(Ti_Limit,Ti_Start)];
XIC(ApplyGainsReq)XIC(TIC101.DependIndepend)GRT(Ti_Start,0)[MOV(Kc_Start,TIC101.PGain),MOV(Ti_Start,TIC101.IGain),MOV(0.0,TIC101.DGain)];
XIC(ApplyGainsReq)OTU(ApplyGainsReq);

(* Starting PI gains from a manual step test. Run it anywhere; it only does math until asked. *)

(* 1. Process gain K, in % of PV span per % of output *)
IF (StepCV <> 0) AND (PVSpan > 0) THEN
    Proc_Gain := ABS(StepPV * 100.0 / PVSpan / StepCV);
END_IF;

(* 2. SIMC starting gains: Kc = Tau / (K * (Lambda + Dead)), and the 4 * (Lambda + Dead) limit *)
IF (Proc_Gain > 0) AND (LambdaMin > 0) THEN
    LamDead := LambdaMin + DeadMin;
    Kc_Start := TauMin / (Proc_Gain * LamDead);
    Ti_Limit := 4.0 * LamDead;
END_IF;

(* 3. Ti = the smaller of Tau and 4 * (Lambda + Dead) *)
Ti_Start := TauMin;
IF Ti_Start > Ti_Limit THEN
    Ti_Start := Ti_Limit;
END_IF;

(* 4. Apply on request: dependent form only (PGain = Kc, IGain = Ti in minutes), and only once Ti is set *)
IF ApplyGainsReq THEN
    IF TIC101.DependIndepend AND (Ti_Start > 0) THEN
        TIC101.PGain := Kc_Start;
        TIC101.IGain := Ti_Start;
        TIC101.DGain := 0.0;
    END_IF;
    ApplyGainsReq := 0;    (* always clear it, so a refused apply can't fire later *)
END_IF;

Applying only in the dependent form matters: in the independent form, IGain is in repeats per minute (Kc ÷ Ti), and copying Ti straight in would be wrong. If your plant standard is independent gains, set PGain = Kc and IGain = Kc ÷ Ti instead. PIDE's velocity form takes gain changes without a bump in the output, but have someone watching the trend when you apply them anyway.

If your code uses the older PID instruction

PID runs in ladder and structured text, and plenty of working plants still use it. It needs a periodic task, with .UPD (loop update time, in seconds) set to match the task period. Manual is software manual (.SWM) with the output set by .SO; output limits are .MAXO / .MINO, in percent; PV scaling is .MINS / .MAXS.

Both versions run the same instruction with the same operands. Tieback, master loop and inhold aren't used here, so they're 0.

PID(TIC101_PID,TT101_Filt,0,TV101_Out,0,0,0);

PID(TIC101_PID,TT101_Filt,0,TV101_Out,0,0,0);

(* Older PID instruction, in a periodic task. Unused operands are 0. *)
(* TIC101_PID.UPD must equal the task period in seconds, for example 0.1 for 100 ms *)
PID(TIC101_PID, TT101_Filt, 0, TV101_Out, 0, 0, 0);

Watch the units if you move gains between PID and PIDE. In PID's independent form (.PE = 0), .KI is per second and .KD is in seconds. In PIDE's independent form, IGain is per minute and DGain is in minutes. In the dependent forms both use minutes. With the worked example above (Kc 1.33, Ti 2.0 min), PID independent would be .KP = 1.33 and .KI = 1.33 ÷ 120 s ≈ 0.011, while PIDE independent would be PGain = 1.33 and IGain = 0.67. Copy the numbers straight across and the integral is off by a factor of 60.

PIDE also has a built-in autotuner, but it needs a separate activation and only works in function block routines. A manual step test teaches you more about the process anyway.

In Ignition: trend it, and log every change

Tuning without a trend is guessing. Bring the PIDE members in as OPC tags in a TIC101 folder: PV, SP, CV, Auto, Manual, PGain, IGain, DGain, plus SPOper, CVOper, OperAutoReq and OperManualReq for the faceplate. The Oper...Req bits are momentary: the PIDE clears them itself after each execution, so a button only has to write a 1.

• Historize PV, SP and CV. Turn on history for all three, plus Auto and the three gains. For tuning work, use a periodic sample mode around 1 second, or "on change" with a small historical deadband. A large deadband or a slow sample rate flattens exactly the wiggles you're trying to see.
• One chart, two axes. In a Perspective Power Chart (or a Vision Easy Chart), put PV and SP on one axis in °F and CV on a second axis, 0–100%. Most tuning problems are obvious once you can see the output and the PV together: a sawtooth output with a squarish PV is stiction; slow rolling waves are usually too much integral; fast chatter is noise or derivative.
• Before and after. Save the chart's time range from before you change anything, and compare the same kind of upset (a setpoint change, or a normal load change) after. Same window length, same axes, so the comparison is fair.
• Log every gain change. A tag event script on each gain tag writes a row whenever the value changes, from any source: the HMI, Studio 5000, or the apply button.

# Tag Editor > the PGain tag (and IGain, DGain) > Tag Events > Value Changed
def valueChanged(tag, tagPath, previousValue, currentValue, initialChange, missedEvents):
    if initialChange or previousValue is None:
        return
    if previousValue.value == currentValue.value:
        return
    system.db.runPrepUpdate(
        "INSERT INTO tuning_log (t_stamp, tag_path, old_value, new_value) VALUES (?, ?, ?, ?)",
        [system.date.now(), str(tagPath), previousValue.value, currentValue.value],
        "PlantDB")

-- One row per gain change. Adjust types for your database.
CREATE TABLE tuning_log (
    t_stamp    DATETIME,
    tag_path   VARCHAR(255),
    old_value  FLOAT,
    new_value  FLOAT
);

Change PlantDB to your database connection's name. Tag event scripts run on the Gateway, so they log changes even when no client is open. Put the tuning_log rows in a table next to the trend and the history of "who tuned this and what did they start with" stops being tribal knowledge. If you also want to know who made a change from a screen, turn on auditing for the project.

This is also how we approach tuning on our own jobs, with more data: our in-house, read-only PLC recorder captures setpoint, process value and output over real production runs, and we use that data to help tune loops instead of tweaking by feel. More on that on how we troubleshoot.

Gotchas

← Previous: First-out fault capture · All tutorials