Lesson 1 — Introduction to Control

The Simplest Approach

On/Off Control (a.k.a. "Bang-Bang" Control)

The oldest and simplest kind of control just has two states: fully on or fully off — nothing in between. Old-timers call this "bang-bang" control, because the output slams between the two extremes.

You already own one: your house thermostat. When the temperature drops below the setpoint, the heater kicks on full blast and stays on — not a gentle trickle of heat, everything it's got — until the temperature climbs back up and passes the setpoint. Then it shuts off completely and the house drifts back down until it dips below setpoint again, and the cycle repeats. A refrigerator works the same way — and so does a window air conditioner, or an electric water heater keeping a tank at temperature.

Placeholder graphics — a thermostat and a refrigerator, two everyday on/off controllers.

On/Off Control: A Furnace Example

This is a simulation, not a live reading — just a preview animation, styled the same way our real simulator is, so that tool feels familiar when we get to it. No controls to touch here, just watch the furnace cycle on and off.

The furnace switches the instant the temperature crosses setpoint — on the moment it dips below, off the moment it climbs above. But the room itself has lag: it doesn't reverse direction the instant the furnace switches. Temperature keeps dropping for a moment after the furnace kicks on, and keeps climbing for a moment after it shuts off — that lag is what causes the overshoot and undershoot you're about to watch, not some extra buffer zone around the setpoint.

Red band = furnace running.

Meet the Terminology

Two Signals: PV and CO

So far you've watched Room Temperature — in the real simulator that's called the Process Variable, or PV. Now let's put a number on the other half of the picture: what the furnace itself is doing. That's the Control Output, or CO — how hard the final control element (the furnace, a valve, a pump) is being driven, from 0% to 100%.

On/off control only ever uses two CO values: 100% (full on) or 0% (full off) — nothing in between. Watch the red CO line below: it jumps straight to the top of the graph the instant the furnace switches on, rides across at 100%, then drops straight to the bottom and rides along the zero line while it's off. That square wave is the on/off signal — same information as the red shading, just drawn the way the real simulator draws it.

Red band = furnace running. Dashed red line = CO, on the 0–100% scale at right.

The Problem

Why On/Off Isn't Good Enough

• It never actually holds the setpoint — the process value is always sawing back and forth around it, overshooting and undershooting on every cycle.
• It wears out equipment — constantly snapping fully on and fully off (short-cycling) is hard on motors, valves, and compressors compared to smoother adjustments.
• It's imprecise — fine for a house thermostat where a couple degrees of swing doesn't matter, but not good enough for an industrial process that needs to hold tight and steady.

Good enough for your house. Not good enough for a plant. There must be a better way.

Same signals, no shading — this is closer to how the real simulator shows it. Dashed red line = CO, on the 0–100% scale at right.

The Better Way

Continuous Control Systems

To fix on/off control's problems, engineers developed continuous control systems — instead of slamming fully on or fully off, the controller's output can land anywhere in between and adjusts smoothly as the error changes. No more sawtooth, no more short-cycling.

The continuous control method used across nearly every industry today is called PID control:

Those are math terms, and we'll unpack exactly what each one does over the next few lessons. For right now, the only thing to remember is what PID buys you: it holds closer to setpoint, and it gets there more smoothly, than on/off control ever can.

No more square wave — PV rises smoothly to setpoint and CO eases off continuously as the error shrinks, instead of slamming between 0% and 100%.

One More Distinction

Transient State vs. Steady State

There's one more piece of vocabulary worth nailing down before we move on, because it's the cleanest way to describe what actually separates on/off control from PID control.

Whenever something disturbs a process — a setpoint change, a load change, anything that knocks PV away from where it was — the process goes through a transient state: PV is actively moving, working its way toward a new value. Once PV finally settles down and holds essentially constant — flat, no more meaningful movement — the process has reached steady state.

Same PID response as before — now marked off into the transient region, while PV is still actively settling, and the steady state region, once it's gone flat at setpoint.

Naming What Caused It

What Actually Upsets a Loop? Two Categories, Not a Grab-Bag

Last page you saw the list of things that can knock a process out of steady state and into a transient: "a setpoint change, a load change, anything that knocks PV away from where it was." That list isn't actually open-ended. Every single thing that can start a transient falls into exactly one of two categories — there's nothing outside these two.

From the controller's point of view, both look identical: an error appears, and it reacts the same way either time. But from an operator's or troubleshooter's point of view, telling the two apart matters a great deal. A lingering error right after a known setpoint change is expected. That same lingering error with no setpoint change means something in the process moved on its own — and it's worth investigating.

One More Idea

Adjusting a Controller: Meet "Tuning"

Here's something worth being upfront about: no control system, on/off or PID, is ever technically perfect. Nothing holds a process variable at exactly, mathematically the setpoint forever with zero error. What a good control system gets you is close enough — close enough that, for practical purposes, it's holding right where you need it.

With PID control, you're not stuck with whatever response the controller happens to give you. The controller has settings — the P, I, and D terms from a couple pages back — and you can adjust them. Turn them up, turn them down, change the balance between them, and the very same controller, on the very same process, will respond completely differently: faster or slower, with more overshoot or less, tighter or looser around setpoint.

The procedure of making these adjustments — dialing in a controller's settings to get the process to behave the way you want — is called tuning. It's one of the most important practical skills in this entire section, and we'll come back to it often.

Tuning Example — Fast

Tuned Aggressive: Fast, but Loose

This is the same controller and the same process as the last few pages — just tuned differently. Push the tuning toward being more aggressive and the response gets to the neighborhood of setpoint noticeably faster. That sounds like a win, and in one sense it is — but watch what it costs: the response overshoots setpoint by a lot more, and it may swing back and forth, ringing a couple of times, before it finally settles down.

Aggressive tuning is trading precision for speed.

Compare this to the PID response a few pages back — PV gets close to setpoint much sooner, but overshoots hard and rings before it settles.

Tuning Example — Slow

Tuned Conservative: Precise, but Slow

Now swing the tuning the other direction — more conservative. The response approaches setpoint smoothly, with little to no overshoot at all. It's about as clean and precise an approach as you could ask for. The cost this time: it takes considerably longer to actually get there and settle out.

Conservative tuning is trading speed for precision.

Compare this to the aggressive tuning on the last page — barely any overshoot here, but PV takes a lot longer to close in on setpoint.

Review

Review