Lesson 6 — Derivative Control

Lesson 6 · Objective

Derivative Control — Anticipation

By the end of this lesson you'll be able to explain what derivative control actually does: it reacts to the rate of change of error — how fast things are moving right now — not the error itself, and not how long it has stuck around.

Quick Refresher: P, I, and Now D

A fast recap of the two terms you already know, and where D fits next to them:

P

Proportional reacts to how far off the process is right now — the size of the error.

I

Integral reacts to how long error has been sticking around — the accumulated total.

D

Derivative reacts to how fast things are changing right now — the rate of change of error. That's this lesson's whole job.

What's ahead: you'll see the mechanics of D on a process you already know well, then an honest look at why its payoff doesn't show up everywhere, and finally a process where derivative's anticipation really is obvious. This lesson is derivative-only — no combined P+D or full PID strategy yet. That's coming in later lessons.

Concept

Seeing It Coming

Picture an experienced operator who has watched a process for years. They don't just react to where the needle is right now — they react to how fast the needle is moving, and they start easing off before it gets there. That's anticipation, and it's exactly what derivative control brings to an automatic controller.

Everyday Anticipation

You already do this instinctively, every day:

Braking a car: you brake harder the faster you're approaching a stop sign, not just based on how far away it is. A car crawling toward the sign needs a lot less brake than one flying toward it, even at the exact same distance.
A hot water tap: if the water is heating up fast, you back the tap off before it reaches scalding — you don't wait until it's already too hot to react.

In both cases, the thing driving your reaction isn't just "how far from the target am I" — it's "how fast am I approaching it." That's the rate of change, and it's information that neither P nor I ever look at.

Why would a controller want this? Because reacting only to the error itself (P) or to how long it has lingered (I) means a controller can only ever catch up to a fast-moving situation after the fact. Something that reacts to the rate of change can start correcting before the error even gets big — the same way you ease off the brake before you're right on top of the stop sign, not after.

Live Illustration

Concept

What "Derivative" Actually Means

Before you see derivative wired into a controller, it's worth pinning down what the word itself means. Strip away the PID context entirely: derivative is just the rate of change — how fast some value is moving, per unit of time. That's it. No error, no setpoint, not yet — just slope.

Steep vs. Shallow

Watch the two lines below draw. Both climb from the same starting point over the same amount of time, but at very different steepness — and the number below each one is that line's rate of change, ΔY ⁄ ΔT: how much the value changed, divided by how much time it took.

Steep Slope

Value is changing fast — a big rate of change.

Shallow Slope

Value is changing slowly — a small rate of change.

The whole idea, in one line: a steeper line means a bigger derivative — the value is changing quickly. A shallower line means a smaller derivative — the value is barely changing at all. A perfectly flat line would have a derivative of zero: no change, no matter how much time passes.

Hang on to that picture. In the pages ahead, the "value" doing the changing will specifically be error, and the controller will react to exactly this — how steep that error is rising or falling right now.

Concept

Where D Fits in the Block Diagram

You've already seen proportional and integral drawn as two parallel paths, both reacting to the same error signal and summed together into the controller output. Derivative is a third parallel path on that same diagram — it just reacts to error in a different way.

CO

=

Bias

+

Kp × Error

+

Ki × ∫Error dt

+

Kd × d(Error)/dt

That last piece — Kd × d(Error)/dt — just means "Kd times how fast error is currently changing." Where the ∫ symbol in the integral term means "keep adding up," the d/dt symbol here means "how steep is the slope right now." Don't let either symbol intimidate you — they're just shorthand for the plain-English ideas you already have.

The Sum block now adds three terms together — you're not meeting "PD" or "PID" as a combined strategy yet; this diagram just shows where the D branch physically fits.

Concept

Kd: The Slope Multiplier

If Kp is a multiplier on error's size, and Ki is a dial on how fast the accumulator fills, think of Kd as a multiplier on error's slope — how steeply it's rising or falling right now. Mathematically, derivative output is Kd × d(Error)/dt: Kd times the instantaneous rate of change of error.

Big for a Fast Change, Zero for a Steady One

That definition has an important consequence worth sitting with: derivative output is large when error is changing quickly, and zero the instant error stops changing — even if error itself is still sitting there, nonzero. A steady, unmoving error contributes nothing to D, no matter how big it is. Only motion in the error signal produces a derivative response.

That's worth remembering for two reasons you'll run into shortly: it's exactly why D "does nothing" at steady state (there's nothing left to differentiate once the process has stopped changing), and it's part of why the muted demo coming up on the next page looks the way it does.

A Name From an Older Era

Just like Ki is sometimes called Reset, you'll sometimes see Kd called Rate instead of Derivative — same idea, older industrial name, same underlying math.

Rate Derivative Time (Td) Kd

The takeaway: whatever a controller calls it — Kd, Derivative, Rate — you're always adjusting the same thing: how strongly the controller reacts to the speed of a changing error, not its size or its history.

Guided Exercise

Live Demo: D Mechanics on the Tank

The button below opens the real PID simulator in its own tab, already set up for this exercise — this lesson tab stays open behind it, so just switch back (or close that tab) when you're done. This is the same tank-level process and the same well-tuned P+I baseline (Kp = 3, Ki = 0.3) you already trust from Lesson 5 — you're just adding Kd on top of it.

D Mechanics on the Tank

Kp = 3, Ki = 0.3 (locked, your Lesson 5 baseline). Kd starts at 0. Click Start, let it settle, step the Setpoint, then try Kd = 1 and watch the derivative term spike on the fast transient and decay back toward zero.

🔧 D Mechanics on the Tank

Stay honest about this one: the derivative term is genuinely working here — watch it spike on the fast transient and settle back toward zero as the rate flattens. But don't expect a dramatic improvement in the response itself. On this process, D's payoff is real but subtle. The next page explains exactly why.

Concept

Why Doesn't D Help Much Here?

You just watched D mechanically work — spiking on the fast transient, settling back to zero as things flattened out — and yet the level's actual path to setpoint barely changed. That's not a mistake in the demo. It's telling you something important about when derivative actually earns its keep.

It Comes Back to Process Lag

Back in Lessons 4 and 5 you met the idea of process lag and dead time — how long a process takes to actually respond once the controller output changes. Derivative's whole value proposition is anticipation: reacting early to something that's about to become a problem. But anticipation is only useful if there's something worth anticipating.

The tank-level process you just used is near-integrating, with relatively little lag — the level responds to the valve quickly and fairly directly. There isn't much "coming" for derivative to see ahead of time; by the time error is changing fast, the process is already almost caught up. On a fast process like this, anticipation just doesn't have much to anticipate.

The pattern to remember: derivative's anticipation is only useful when the process itself is slow to respond — lag-dominant. On a fast, near-integrating process, D has little to contribute, no matter how it's tuned.

So let's look at a process where the lag is real — one where a controller genuinely benefits from seeing a change coming before it fully arrives.

Live Illustration

Side-by-Side: Baseline (P+I) vs. Baseline (P+I) + D

Same setpoint step, same lag-dominant heater process, run through two controllers side by side — the only difference is whether Kd is zero or not. Both panels start from your same locked P+I baseline; the right panel just adds D on top of it.

Setpoint (SP) Process Variable, baseline P+I Process Variable, P+I + D

Baseline: P+I Alone

Overshoots and oscillates before finally settling on setpoint.

Baseline + D

Eases off as it approaches — less overshoot, faster clean settling.

This is the payoff. Both panels start from the exact same P+I baseline and the exact same setpoint step on a process with real thermal lag. The only thing added on the right is derivative reacting to how fast temperature is approaching setpoint — anticipating the arrival and easing off early, instead of sailing past and having to swing back. On a lag-dominant process, that anticipation is the entire reason derivative control exists.

Keep this in perspective: this page is only adding D on top of your existing P+I baseline — it's not "PID" as a named strategy or a decision framework yet. That's a later lesson's job. Here, the point is just seeing derivative's effect in isolation, on a process where it actually matters.

Guided Exercise

Hands-On: Add D Yourself

The button below opens the real PID simulator in its own tab, already set up for this exercise — this lesson tab stays open behind it, so just switch back (or close that tab) when you're done.

P and I are locked at the baseline values from the last page — only Kd is yours to adjust. This isn't a free-for-all PID tuning exercise (that comes later, once you've met all three terms together); it's isolating derivative's effect the exact same way Lesson 5 isolated Ki on its own hands-on page.

The baseline is an honest tune, not a rigged one. Kp = 1.9 and Ki = 0.03 are exactly what the standard Ziegler–Nichols reaction-curve rule gives you for this heater after a step test — nobody cranked the gain up to manufacture a problem. The overshoot you're about to see is simply what a correctly tuned two-term controller does on a process with this much lag and dead time behind it. Turning P down wouldn't fix it; it would just make a slow loop slower. What's missing is information about rate — and that's D's job.

Add D Yourself

Kp = 1.9 and Ki = 0.03 are locked. Kd starts at 0. Step the Setpoint from 50 to 70 and watch it overshoot and swing back, then add Kd = 15 and run the same step again. After that, deliberately overdo it — push Kd toward 80 and watch it get worse.

🎯 Add D Yourself

What to feel: too little Kd (try 5, then 10) and you still overshoot, just less than the baseline. Around Kd = 15 the overshoot disappears entirely and the loop settles in well under half the time. Push much past that — 40, 60, toward 80 — and it gets worse again: settling drags out, and near the top of the range the output turns jittery instead of smoother. That's derivative amplifying every wiggle in the signal rather than helping. There's a right amount of D, and more is not better.

From the Field

Why you'll see D used far less often than P or I: in the large majority of real industrial control loops, D never gets turned on at all — most run P-only or PI. Three honest reasons, straight from running real loops.

First, most processes don't have anything for D to anticipate. Derivative earns its keep when a process has real inertia — several lags stacked up, a big thermal mass, a PV that keeps drifting the same direction for a while — like the heater above. If the dominant dynamic is a single lag, or the loop is already fast, D has nothing useful to predict and PI is simply enough. And if the loop is mostly dead time, derivative is worse than useless: during dead time the PV isn't moving yet, so there's no slope to read.

Second, derivative amplifies measurement noise. Any jitter in the signal gets multiplied by its rate of change, and a noisy PV turns into a jittery output that wears valves out. That's why flow and liquid-pressure loops — noisy and fast — almost never get D, while temperature and smooth level loops are its natural home.

Third, three terms are harder to tune than two. Adding D means one more knob whose effect shows up tangled with P and I in the loop's behavior, and derivative is the hardest of the three to get right.

That's not textbook caution — it's why, in the field, D stays off unless a process genuinely needs the anticipation, the way the heater process above did.

Review

Coming up in Lesson 7: now that you've met P, I, and D individually, we'll look at how to actually choose between them — P vs. PI vs. PID — and how to make that tuning decision for a real process.