Cascade PID control explained: inner loops, bandwidth, and when cascade fails

A single PID loop sees a disturbance only after that disturbance has already corrupted the process variable. By then the damage is in the tank, the coil, or the product. Cascade control exists to intercept the disturbance earlier. You close a fast inner loop around a secondary measurement that sits on the path of the usual upsets — flow, speed, current, fuel — and you let the outer PID write the inner loop’s setpoint instead of writing the actuator directly. The inner loop rejects supply-pressure changes, fuel-header swings and load-torque steps before they accumulate in temperature, level or composition. The outer loop still exists; it still has to correct model error, unmeasured loads and setpoint changes. It just no longer has to do the inner loop’s job as well.

This article is about when that split is worth the extra transmitter, how to tune the two loops in the only order that works, what “four to ten times faster” actually means in bandwidth, and the failure modes that make cascade worse than a well-tuned single loop: an inner loop that saturates, a slave measurement that lies, or a pair of loops that were tuned as if they were independent. The worked pictures are a fired furnace with a fuel-flow slave and a tank with an outflow slave. You can prototype both structures as FOPDT or first-order plants in PID Solver 360 and inspect the same metrics you would on a single loop.

Why a single loop is late

Consider a steam-heated exchanger whose product temperature is controlled by a valve on the steam line. Inlet flow rises. More cold fluid enters, temperature begins to fall, the PID opens the steam valve, steam flow rises, and temperature recovers. The recovery cannot start until the bulb has seen the dip. If the thermal lag is two minutes, you have already made two minutes of off-spec product before the controller has done anything intelligent. A feed-pressure dip on the steam side is worse in a different way: the valve position is unchanged, steam flow falls immediately, and the temperature loop discovers the problem only through the same slow bulb.

Now put a steam-flow transmitter on the pipe and a fast PI loop around that flow, and let the temperature PID write the flow setpoint. The feed-pressure dip becomes a flow error in a fraction of a second. The inner PI opens the valve and restores steam mass flow before the bulb has moved. The inlet-flow increase is not measured by the steam-flow loop, so it still has to wait for temperature — unless you add feedforward from inlet flow — but at least the temperature controller is now commanding a flow that the inner loop will actually deliver. Supply disturbances and actuator nonlinearity have been taken off the outer loop’s plate.

That is the whole argument for cascade, in any industry. The secondary variable must be on the disturbance path and faster to measure and to move than the primary. Flow under temperature, current under speed, speed under position, fuel flow under fired duty, and outflow under level are the combinations that keep earning their keep. A secondary that is not on the path — a nearby pressure that does not determine the heat, a speed that is not what is upsetting the temperature — adds a loop without intercepting the load.

Inner and outer: what each loop is for

Call the inner loop the slave and the outer loop the master, which is the DCS vocabulary, or secondary and primary, which is the textbook vocabulary. The slave’s process variable is the secondary measurement. The slave’s output is the real actuator. The master’s process variable is the quality variable you actually care about. The master’s output is not a valve position; it is the slave’s setpoint.

The slave’s job is disturbance rejection and linearisation. A flow loop turns a nonlinear valve and a swinging header into an approximately linear, first-order flow response from the master’s point of view. A current loop on a drive turns supply voltage and back-EMF into a torque that tracks a current setpoint. A speed loop turns load torque into a small speed error instead of a large position or temperature error. The master never sees the original actuator. It sees a slave that, if well tuned, looks like a modest lag plus a little delay.

The master’s job is to hold the slow variable to setpoint despite the disturbances the slave cannot see: product flow, incoming temperature, composition, a change in heat-transfer coefficient, an operator changing the production rate. The master is allowed to be slow. It must be slow relative to the slave, or the two loops fight.

This split also changes what you tune to. The slave should be judged on how fast it restores flow (or speed, or current) after a supply step, and on whether it stays inside valve limits for the master’s normal output range. The master should be judged on temperature, level or composition: overshoot, settling, and the remaining effect of a load the slave cannot reject. Tuning both loops on the same setpoint-step plot of the primary PV is how cascade gets a reputation for mystery. They are two control problems. Tune them as two.

Tuning order: inner first, and much faster

The only order that works is slave first, master second. The master cannot be tuned while the slave is an untuned valve. The master’s plant is the closed slave plus the slow process. If you tune the master against a slave that you later retune, you have changed the master’s plant and the master’s PID is now wrong.

Procedure:

• Put the master in manual, or freeze its output at a typical slave setpoint. The slave must be able to run as a standalone loop.
• Identify the slave plant: valve (or drive) to secondary PV. A flow loop is usually a fast FOPDT with τ of one to five seconds and a little transport delay. A current loop may be first-order with almost no delay. Use a small step or, on a permitted loop, a relay autotune.
• Tune the slave, almost always as PI. Flow and current measurements are noisy; derivative on the slave is rarely justified. Use SIMC or a modest Ziegler–Nichols PI, not a quarter-amplitude-decay PID. Confirm on a slave-setpoint step and on a supply disturbance. Enable anti-windup on the slave: it will hit the valve more often than the master will.
• Only then identify the master’s plant: slave setpoint to primary PV, with the slave in automatic. That closed-loop slave is now part of the dynamics. Fit FOPDT or a second-order model. The apparent delay will include the slave’s settling.
• Tune the master. Temperature and composition usually deserve PID with filtered derivative; level is often PI. Choose a closed-loop speed that leaves the slave looking like a unity-gain block over the master’s bandwidth.

If you reverse the order — tune a temperature PID directly to the valve, then “add cascade” by inserting a flow loop — the temperature gains are too aggressive. They were designed for a plant that included valve and header dynamics the slave has now removed, and they will overshoot or fight the flow loop. Retune the master after the slave exists. There is no conversion table that saves you that step.

Bandwidth separation: the 4–10× rule

Two loops in cascade are stable as a pair only if their bandwidths are separated. A useful field rule is that the slave’s closed-loop bandwidth should be at least four times, and preferably about ten times, the master’s. In time constants: the slave should settle in one-quarter to one-tenth the time the master is allowed to settle. In frequency: if the master is designed for a crossover near 0.01 rad/s, the slave should be crossing over near 0.04–0.1 rad/s or faster.

Why a factor of four is a floor, not a target: the master’s PID, especially with integral action, still has gain at the slave’s frequencies. If the slave is only twice as fast, the master will write slave-setpoint moves that the slave cannot track without lag, the master’s model (which assumed a fast slave) is wrong, and the pair can ring at a beat frequency that neither loop showed in isolation. A factor of ten makes the slave look like a static gain of one from the master’s seat, which is the assumption every simple cascade-tuning recipe makes.

You cannot always have ten. A composition loop with τ of twenty minutes and a tray-temperature slave with τ of three minutes may only give you a factor of five, which is still worth doing. A temperature loop with τ of thirty seconds and a flow loop with τ of eight seconds is already tight; you may need to slow the temperature controller further rather than try to make the flow loop heroic. If the secondary is not actually faster, cascade is the wrong structure. Use feedforward, or a single PID, or fix the secondary measurement.

Bandwidth is not the same as “the slave Kp is bigger.” A sluggish slave with high gain is still sluggish. Check the slave’s settling time to a setpoint step, in the same units you will use for the master. If the flow loop settles in 8 s and you want the temperature loop to settle in 40 s, you have a factor of five: usable, not luxurious. If both settle in 30 s, you have built two interacting PIDs, not a cascade.

When cascade fails

Cascade is not free. It adds a transmitter, a loop to maintain, and a new way to saturate. The failure modes below are more common than a wrongly applied 4–10× rule.

The inner loop saturates

The slave has a real actuator with limits. When the valve is fully open, the flow loop cannot honour a higher flow setpoint. The master does not know that unless you tell it. It still sees temperature (or level) error, its integral still winds, and it writes an even more impossible flow setpoint. When the disturbance that saturated the valve finally leaves, the master is wound up and the slave is slammed against the opposite limit. You have invented a two-loop windup problem.

Fixes, in order of how often they work:

• Anti-windup on the slave, always. That stops the flow PID from winding while the valve is stuck.
• Anti-windup or an output limit on the master that matches the slave’s achievable range. If the flow loop cannot deliver more than 80 % of span at this header pressure, the temperature PID’s output should not be able to ask for 110 %.
• External reset feedback from the slave PV to the master, which is the classical cascade anti-windup: the master integrates the difference between the flow it asked for and the flow it got.
• A feedforward or override that prevents the master from asking for the impossible: a firing-limit overlay, a valve-position constraint, a surge controller that owns the valve when needed.

Saturation also destroys the bandwidth assumption. A saturated slave has zero bandwidth: it is a constant output. The master is then a single loop with a stuck actuator, but with extra delay in its own output path (the slave setpoint sitting in saturation). If your process regularly saturates the inner loop — a furnace at maximum firing on a cold start, a level loop whose outflow pump is at stop — cascade will look worse than a single PID during those periods unless the windup path is designed.

The slave measurement is poor

The inner loop can only reject disturbances it can see, and it will reject them by moving the actuator to make the measured secondary track the setpoint. If the flow transmitter is noisy, the slave PI will chase noise and chew the valve. If the transmitter is biased, the slave will hold the wrong flow and the master will offset its output to compensate — which still works for the primary PV, slowly, but you have spent a loop on a lie. If the transmitter is in the wrong place — downstream of a leak, on the wrong burner, on a tap that fills with condensate — the slave will tightly control the wrong stream.

Noise on the slave is more dangerous than noise on the master. The slave is the fast loop; it has the bandwidth to act on the noise. Filter the secondary PV, keep the slave as PI, and do not add derivative. If you cannot get a usable secondary measurement, do not cascade. A single outer PID on a good primary PV beats a cascade whose slave is hunting a noisy orifice.

Stiction on the slave valve is another measurement-and-actuator failure. The flow loop will enter a limit cycle, the master will see a periodic load, and both loops will look unstable. Fix the valve. No cascade-tuning session will.

The loops were tuned as if they were independent

A common commissioning shortcut is to copy flow-loop gains from another skid and temperature-loop gains from a single-loop furnace, then wire them in cascade. The temperature PID was designed to drive a valve, not a flow setpoint. Its Kp is in the wrong units (percent valve versus kg/h of fuel) and its Ti is too short for a loop that now includes the slave. The pair either saturates or oscillates. Treat the master’s output span as the slave’s setpoint span, identify the master’s plant with the slave closed, and retune. There is no shortcut that preserves the old temperature gains.

Another independent-tuning failure is two loops with similar integral times. Even if the slave Kp is high, a slave Ti of 30 s under a master Ti of 40 s means both integrators act on the same horizon. Lengthen the master’s Ti until the separation is visible on a plot: slave recovers from a supply step while the master’s output has barely moved; then the master trims the slave setpoint on the slow PV.

Furnace with a fuel-flow slave

A fired heater or furnace is the textbook cascade that operations will actually defend. The primary PV is coil-outlet temperature, or a pass temperature, or sometimes a calculated absorbed duty. The actuator that can hurt you is the fuel valve. Header pressure swings with every other consumer on the fuel-gas system. If the temperature PID drives the valve directly, every header dip is a delayed temperature dip, and every temperature correction is a firing swing that the rest of the system feels.

Install a fuel-flow transmitter (or a fuel-gas flow with density compensation, or a mass flow on oil) and a fast PI slave. The temperature master writes a fuel-flow setpoint. Header-pressure disturbances become flow errors and die in seconds. The temperature loop sees a firing rate that matches what it asked for, so its plant is closer to the thermal FOPDT you identified: gain from fuel flow to outlet temperature, time constant of the coil and the process fluid, dead time from transport along the pass.

Typical numbers, order of magnitude, not a copy-paste:

• Fuel-flow slave: τ of 1–4 s, L of 0.3–1 s, PI, Ti of a few seconds, Kp high enough to restore flow after a header step in well under 10 s. No derivative.
• Temperature master: τ of 60–180 s, L of 10–40 s, PID with filtered derivative, Ti of a minute or more. Closed-loop settling of several minutes. That is a bandwidth ratio of ten or better if the slave is not over-filtered.

Safety is the reason this cascade is not optional on many heaters. You do not relay-autotune the fuel valve through a temperature loop on a live firebox. You may identify the flow loop with a small step. You identify the temperature loop with the firing-rate slave in automatic, using a small flow-setpoint step, not a valve step. Skin-temperature and stack-oxygen overrides must still be able to seize the valve or the firing setpoint; cascade does not outrank a trip. The master’s output limits should be the minimum and maximum firing the heater is allowed, not 0–100 % of some internal scale.

Where this cascade fails on furnaces: a flow meter on the wrong burner of a multi-burner heater; a slave that saturates at the firing limit while the master winds; a temperature bulb so slow that operators demand a violent master, which then writes flow-setpoint spikes the slave tracks into the firebox. Slow the master. The point of cascade was to let the temperature loop be calm.

A second inner loop, air flow or damper, is a different problem (cross-limiting, lead-lag of air and fuel) and is not a simple cascade. Do not copy the fuel-flow pattern onto air without the combustion-control structure that belongs there.

Level with an outflow slave

A tank whose level is controlled by the outflow, and whose outflow is itself a pumped or valved flow with a transmitter, is the hydraulic analogue of the furnace. The primary PV is level. Disturbances are inlet flow and, on a boiling or aerated tank, density. If the level PID drives the valve directly, inlet-flow steps become level ramps until the valve moves, and header pressure on the discharge side changes the outflow for a given valve position. A flow slave on the outflow holds the discharge flow to whatever the level controller asked. Inlet-flow disturbances still integrate into level — cascade does not magically add feedforward — but the level controller is now writing a flow command that is delivered despite the header.

This structure is especially useful when the outflow also feeds a downstream unit that cares about flow smoothness. The slave can be tuned to track the master’s fairly slow flow-setpoint changes without passing valve stiction and header noise downstream. The master can be a level-to-flow cascade with a deliberately sluggish PI, which is what you want on a surge tank: use the inventory, do not chase every ripple.

Typical numbers:

• Outflow slave: fast PI, settle in a few seconds, noisy PV, no derivative, tight anti-windup because level controllers will drive the flow setpoint to a limit when the tank is empty or full.
• Level master: for a self-regulating tank, FOPDT with large τ; for a true integrator, A s in the denominator. PI, often with a low Kp so that a 10 % level error asks for a moderate flow change. Settling of minutes, not seconds. Derivative is optional and usually more trouble than it is worth on a level transmitter.

The failure mode that bites here is slave saturation at empty or full. When the tank is filling against a closed outlet, the flow slave is at zero (or at minimum), the level still rises, the master integrates, and the flow setpoint winds to a huge number. When you finally need to run, the slave slams to maximum. External reset from measured outflow, or a master output limit of 0–maximum pump capacity, is mandatory. Averaging-level control — a master so slow it uses the tank as a filter — makes this worse if you forget the limits, because the integrator has more time to wind.

Do not cascade level-to-inflow and also expect the outflow slave to hold a production rate. Someone has to set throughput. A common correct pattern is: throughput is set by the inlet (or by a downstream demand), and the level-to-outflow cascade trims inventory. The other common pattern is the reverse on a feed tank. Pick one. Two masters writing two flow setpoints on the same vessel is not cascade; it is a fight.

How to see cascade in a simulator

PID Solver 360 is a single-loop studio, but you can still learn the cascade numbers before you wire two DCS blocks. First, identify and tune the slave as its own plant in the identifier and the tuner: a fast FOPDT, PI, check gain and phase margin and a load step on the secondary. Record the closed-loop settling time ts_slave. The docs describe those modes if you need a map of the studio.

Second, build the master’s plant as the slow process plus a small extra lag standing in for the closed slave. A crude but honest approximation is to add 0.5 ts_slave to the master’s dead time, or to add a first-order lag with time constant ts_slave / 4. Identify that combined plant, tune the master so that its closed-loop settling is at least four times ts_slave, and simulate a load on the primary. If you cannot get that separation without making the master useless, the secondary is not fast enough.

Third, simulate slave saturation by clamping the master’s output and enabling anti-windup. The outer-loop overshoot with and without anti-windup is the plot that convinces people to wire external reset. Compare a single PID from valve to primary PV against the cascaded design on a supply disturbance (header pressure, modelled as a load on the inner plant) versus a demand disturbance (inlet flow or incoming temperature, modelled as a load on the outer plant). Cascade should crush the supply case and only modestly help the demand case. If your simulation shows the opposite, the secondary is not on the supply path.

For industrial context on which loops are naturally inner and which are outer, see industrial PID applications. Flow and current are inner; temperature, level and composition are outer. Speed can be either: inner under position or tension, outer over current.

Design checks before you add a transmitter

Ask four questions, in writing, before the extra loop exists.

Is the secondary on the path of the disturbances that actually hurt? Header pressure and fuel-gas swing: yes, fuel flow. Ambient temperature on a well-insulated reactor: no, jacket flow will not intercept that; you need feedforward or a better insulation story. Inlet composition on a column: a tray-temperature slave intercepts some of it; a reflux-flow slave intercepts reflux-header upsets, not feed composition.

Is the secondary faster, by a factor you can measure? If you cannot name τ_slave and τ_master, you cannot claim cascade. A factor of two is a warning. A factor of ten is the design you should want.

Can the slave saturate, and what happens to the master then? If the answer is “the operator takes it over,” you have not finished the design. Limits and anti-windup are part of cascade, not extras.

Is the secondary measurement quieter than the slave’s intended bandwidth? If not, you will spend the extra loop amplifying noise into the actuator, and the primary will see that as a periodic load.

If those four are satisfied, cascade is one of the highest-leverage structure changes in process control: you spend one transmitter and one PI, and you take supply disturbances off a slow quality loop. If they are not, a single PID tuned with a robust rule, perhaps plus feedforward from a measured load, will outperform a fashionable cascade. Structure first, then tuning. The extra loop does not excuse a violent master, and it does not excuse skipping identification. Tune the slave until it is boring. Then tune the master on the plant that includes that boring slave. That is cascade control as it is practised on furnaces and tanks that stay in automatic.