Reset windup is usually explained through a saturated valve, but some of its nastiest appearances come from transfers rather than saturation: a loop left in manual, a cascade whose secondary hits a limit, or an output held at a clamp. In each case a controller keeps integrating against an error it cannot actually act on, and it winds up out of sight. This guide focuses on those transfer and cascade scenarios, explaining the symptom of a bad overshoot on returning to control, the likely causes, and how back-calculation and tracking keep the controller from winding up in the first place.
Reset windup on transfer in one line: Reset windup on transfer is the accumulation of a controller's integral term while it is not actually in command of the output, which happens when the loop is in manual, when a cascade secondary saturates or is taken to manual, or when the output is clamped. When control is restored, the wound-up integral drives a large overshoot. Back-calculation and output tracking prevent it by keeping the integral consistent with the output that is really in force.
The familiar cause of reset windup is a saturated final element: the valve is fully open, the error persists, and the integral keeps accumulating because it has no way of knowing the output can go no further. Transfer-related windup has the same mechanism, an integral accumulating against an error the controller cannot act on, but a different trigger. Here the controller is not in command of the output at all, so even though nothing is saturated, its integral is winding up against a situation it is powerless to change. The controller is computing as if it were driving the process, when in fact something else is.
The clearest example is a loop in manual. While an operator holds the output by hand, the controller in a naive implementation may keep running its calculation in the background, and if a standing error exists its integral marches steadily upward the whole time the loop sits in manual. Nothing looks wrong, because the operator's manual output is what reaches the valve. But the controller has quietly wound up, and the longer it stays in manual with an error, the larger the hidden integral grows. This is windup produced purely by the mode, with no saturation anywhere.
The same thing happens whenever a controller is displaced from command. If an override selector passes through a different controller, the sidelined ones are not driving the output and can wind up against their errors while they wait. If an output is held at an engineered clamp, the controller is prevented from moving further and integrates just as it would against a physical stop. In every one of these, the defining feature is a controller integrating while not truly in control of what the process is doing, which is the essence of transfer and cascade windup.
Cascade control is where transfer windup is most consequential, because two controllers are chained and the primary depends entirely on the secondary to carry out its wishes. The primary sets the secondary's setpoint; the secondary drives the valve. If the secondary saturates, is taken to manual, or is put in local setpoint, then the primary's output is no longer being honoured, even though the primary keeps calculating. If the primary is not protected, its integral winds up while the secondary is not following it, and the primary has no direct awareness that its commands are going nowhere.
The symptom to recognise is a severe overshoot when the cascade is restored to normal. Consider the diagnosis in three steps. The symptom is that on reclosing a cascade, or on returning a loop from manual to automatic, the process lunges well past setpoint and takes a long time to recover, far worse than a normal setpoint move would cause. The likely causes are a controller that was integrating while out of command: a primary that wound up while its secondary was saturated or in manual, a loop that wound up while sitting in manual, or a controller sidelined by an override that wound up while not selected. The diagnostic step is to correlate the overshoot with what the loop or its secondary was doing just before: check whether the secondary was at a limit or in manual, whether the loop had been in manual with a standing error, or whether an override handoff had just occurred, and confirm the overshoot coincides with the return of command to a controller that had no anti-windup protection during that period.
The reason the overshoot is so large is that the wound-up integral must be unwound before the output can come back to a sensible value. The controller returns to command carrying a big accumulated integral pointing the wrong way, and it drives the output hard in that direction until the accumulated error is slowly bled off by the process moving past setpoint and generating opposite error. Only then does the output return to normal. This delayed, one-directional recovery is the signature of windup, and it distinguishes a windup overshoot from an ordinary bit of overshoot due to aggressive tuning, which recovers quickly and symmetrically.
The prevention is to stop the controller from integrating against a reality it is not in charge of, and the standard tool is back-calculation. Back-calculation continuously adjusts the integral term so that the controller's equation reproduces the output that is actually in force, whether that output is being set by an operator in manual, by a clamp, or by a saturated or manual secondary. When a controller is out of command, its integral is held consistent with the real output instead of drifting, so no hidden accumulation builds. On the return to command there is nothing wound up to unwind, and the loop resumes cleanly.
For the mode cases, this is realised through tracking. A controller in manual is put in track mode so it follows the actual manual output and back-calculates to it, meaning it stays synchronised with what the operator is doing and does not wind up during the manual period. A controller sidelined by an override selector is made to track the selected output so it too stays ready without accumulating. In each case tracking keeps the idle controller's integral truthful, which is exactly what prevents the windup, and it is the same tracking mechanism that also delivers bumpless transfer.
For the cascade case, the secondary tells the primary when it can no longer honour the primary's commands, and the primary uses that signal to stop integrating and instead track the secondary's real state. When the secondary saturates or goes to manual, the primary is inhibited from winding up and follows what the secondary is actually doing, so on reclosure it resumes without an overshoot. In a cloud SCADA operation, the payoff of getting this right is visible on trends: clean cascade reclosures and manual-to-auto returns with no lunge past setpoint. Because the modes and limits of both primary and secondary are recorded, an engineer reviewing a distributed operation remotely can spot the tell-tale windup overshoot, trace it to a period when a controller was out of command without protection, and confirm that back-calculation or tracking has since been applied to close the gap.
The mechanism is the same, an integral accumulating against an error the controller cannot act on, but the trigger differs. Saturation windup comes from a valve reaching a physical limit while the controller keeps integrating. Transfer windup comes from the controller being out of command entirely, because the loop is in manual, a cascade secondary has saturated or gone to manual, or an override has sidelined it, so it winds up while not actually driving the process.
If the controller was integrating while the loop sat in manual with a standing error, it wound up an integral term that was never acting on the process. On the switch to automatic it returns carrying that accumulated integral and drives the output hard until the accumulation is bled off, causing a large one-directional overshoot. Proper anti-windup, holding the integral consistent with the manual output while in manual, prevents this.
Back-calculation keeps the primary's integral consistent with the output actually in force. When the secondary saturates or is taken to manual and can no longer honour the primary, the primary is told to stop integrating freely and instead track the secondary's real state. Because the primary's integral is held truthful during that period, there is nothing wound up to unwind when the cascade recloses, so the process does not overshoot.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.