How to Tune a PID Loop for a Moving Setpoint: The Sawtooth Challenge

Tuning a PID loop for a moving setpoint is a command-following problem, not a standard disturbance-rejection exercise. A sawtooth waveform exposes both steady ramp-tracking error and transient recovery weakness at the reset edge, making it a useful simulation test for gain balance, windup control, and derivative restraint.

A common misconception is that a loop tuned well for a step test is therefore tuned well for any setpoint profile. It is not. A loop that looks respectable on a static bump can still trail badly when the target moves continuously, which is exactly what happens in batch ramps, coordinated motion, tension control, and some thermal profiles.

In internal OLLA Lab testing, PID loops tuned only for static setpoint changes showed materially higher tracking error when driven by a repeating sawtooth command than when evaluated on simple step recovery alone [Methodology: 500 simulated loop runs across preset command-following exercises, baseline comparator = step-oriented tuning workflow, time window = Q1 2026]. This internal benchmark supports one narrow point: step-only tuning can miss command-following weakness. It does not establish a universal industry failure rate.

This is where a simulation environment becomes operationally useful. “Simulation-Ready,” in Ampergon Vallis's bounded sense, means an engineer can prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process. Syntax is not the hard part. The hard part is what the syntax does when the plant stops being polite.

Static tuning methods fail on moving setpoints because they are usually optimized for disturbance rejection around a fixed operating target, not for continuous trajectory tracking. That distinction matters more than many training workflows admit.

In classical process control terms, this is the difference between regulatory control and servo control. Regulatory control asks whether the controller can hold a setpoint against disturbances. Servo control asks whether the controller can follow a commanded change in setpoint over time. ISA-oriented control literature treats these as related but distinct objectives, and the tuning tradeoffs are not identical.

A moving setpoint creates persistent error unless the controller and process together can generate enough corrective action to match the commanded rate of change. With proportional action alone, the process variable typically lags behind the setpoint by a more or less stable offset during the ramp. This is often described as velocity error or tracking lag.

That lag is not a cosmetic issue. In a live process, it can mean:

• a thermal batch profile that never quite reaches the intended trajectory,
• a level or flow loop that trails recipe timing,
• a tension or position loop that follows commands with visible delay,
• or a coordinated sequence whose downstream logic assumes the process is somewhere it has not yet reached.

A bump test is still useful. It is just not the whole story. Step response tells you how a loop reacts to a sudden change; it does not fully tell you how the loop behaves when the target keeps moving and then resets sharply. Different failure mode, different evidence.

A sawtooth waveform reveals two different weaknesses in one repeating test: ramp-tracking deficiency and reset-edge recovery behavior. That is why it is more diagnostic than a single step when the real problem is command following.

Mathematically, a sawtooth combines:

• a linear rising ramp, where the setpoint changes continuously at a fixed slope, and
• a discontinuous drop, where the setpoint resets almost instantaneously to its starting value.

Those two phases stress different parts of the loop. Conveniently, they do so without requiring a large test matrix.

The two phases of sawtooth tracking

This phase tests whether the loop can follow a moving target without accumulating unacceptable lag. If proportional gain is too low, the PV trails visibly. If integral action is too aggressive or poorly constrained, the controller may build excess corrective effort while chasing the ramp.

• The linear ramp

This phase tests transient recovery after an abrupt setpoint reset. If derivative action is taken on error rather than on measurement, the falling edge can produce a large control spike often described as derivative kick. If integral action has wound up during the ramp, the drop can be followed by overshoot, sluggish unwinding, or both.

• The discontinuous drop

The value of the sawtooth is that it exposes a contradiction many loops cannot hide from: the loop must track smoothly during the ramp but remain stable and nonviolent at the reset edge. A controller that looks acceptable in one phase can look reckless in the other.

A sawtooth setpoint can be risky on physical equipment because the reset edge may demand an abrupt actuator response that the mechanical system, final control element, or process should not experience during exploratory tuning. Simulation is not a luxury here; it is often the only sensible first venue.

The risk is most obvious in systems with:

• control valves sensitive to sudden travel demand,
• servo or drive systems with backlash, saturation, or mechanical compliance,
• thermal systems with actuator limits and delayed process response,
• and process skids where sequencing, permissives, or trips interact with analog control output.

A poorly tuned loop subjected to a discontinuous setpoint drop can generate:

• large output reversals,
• valve slam or aggressive repositioning,
• unnecessary wear on actuators,
• nuisance trips from interacting interlocks,
• and misleading commissioning conclusions because the test itself has become the disturbance.

This is one reason digital twin validation is useful when it is defined properly. In this article, digital twin validation means validating observable control behavior against a realistic machine or process model before live deployment: command response, I/O state changes, fault handling, and the relationship between ladder or control logic and simulated equipment state. It does not mean the model has become a substitute for field acceptance. Plants are not obliged to honor your simulation.

Integral windup shows up during a moving ramp when the controller keeps accumulating error correction faster than the process can physically respond, especially near output limits or when the commanded slope exceeds practical loop capability. The result is stored-up control effort that becomes obvious when the setpoint changes direction or resets.

During the ramp phase, the integral term sees persistent error and keeps summing it. That is its job. But if the actuator saturates, or if the process simply cannot keep pace, the integral term can continue to build despite the fact that additional output is no longer useful.

When the sawtooth drops, that stored integral action does not disappear politely. Typical symptoms include:

• overshoot below the new target,
• delayed settling while the integrator unwinds,
• oscillation after the reset edge,
• and output behavior that looks disproportionately aggressive until someone checks the anti-windup strategy.

This is why anti-windup is not a refinement for later. It is part of the minimum viable design for any loop expected to follow moving commands. In practice, useful protections may include:

• integral clamping,
• conditional integration,
• back-calculation methods,
• output limiting with integrator tracking,
• and command shaping so the setpoint itself respects process capability.

A loop can be stable and still be unfit for command following. That distinction is easy to miss until a ramp test exposes it.

Command following usually requires a different tuning emphasis than disturbance rejection. The controller must reduce tracking lag during the ramp without becoming unstable or violent at the reset edge.

The exact answer depends on process dynamics, dead time, actuator limits, and whether feedforward or setpoint filtering is available. Still, the tuning direction is often recognizable.

Tuning adjustments for dynamic tracking

| Parameter | Static Tuning Focus | Dynamic Sawtooth Focus | |---|---|---| | Proportional (P) | Moderate, with emphasis on stability margin | Higher, to reduce ramp lag and tighten command response | | Integral (I) | Often stronger to remove offset after disturbances | Moderate and constrained, to reduce lag without windup on reset | | Derivative (D) | Sometimes useful for damping step response | Often minimal or zero if setpoint edges are abrupt and derivative kick is a risk |

Several practical points matter here.

If the PV trails the ramp consistently, insufficient proportional action is a common cause.

• Higher proportional gain often helps ramp tracking first.

If the loop tracks better during the ramp but becomes unruly at the drop, the integral strategy may be too aggressive or insufficiently protected.

• Integral action should remove persistent lag, not create stored trouble.

Derivative can help in some loops, especially when applied carefully to measurement rather than error. But on a sawtooth reset edge, careless derivative tuning is a reliable way to produce actuator complaints.

• Derivative action deserves suspicion on discontinuous commands.

If the desired setpoint profile is known in advance, shaping the command or adding feedforward can improve tracking without forcing the feedback loop into bad compromises.

• Feedforward or command shaping may be better than brute-force PID gain increases.

A useful engineering contrast is this: disturbance rejection asks how well the loop resists being pushed; command following asks how well it obeys being led.

You should measure tracking error, output behavior, and recovery quality across both phases of the waveform. If you only watch whether the PV eventually gets there, you miss most of the diagnostic value.

At minimum, capture:

• ramp-phase tracking lag between SP and PV,
• steady-state error during the ramp,
• controller output behavior near output limits,
• overshoot or undershoot after the reset edge,
• settling time after the drop,
• evidence of windup, such as delayed integrator recovery,
• and actuator demand spikes, especially if derivative action is enabled.

If the environment allows it, trend:

• SP,
• PV,
• controller output,
• integral contribution,
• derivative contribution,
• and any saturation or clamp indicators.

This is also where engineering evidence should be built properly. If you need to show that you can validate a loop rather than merely animate one, document the work in a compact, reproducible form:

1. System Description
2. Operational definition of correct behavior
3. Ladder logic and simulated equipment state
4. The injected fault case
5. The revision made
6. Lessons learned

That structure is more useful than a folder of screenshots with optimistic filenames. Evidence should survive contact with another engineer.

OLLA Lab can be used as a bounded validation environment for command-following tests because it lets engineers build logic, run simulation, inspect variables, and compare control behavior against simulated equipment state without imposing the test directly on physical hardware.

In this context, OLLA Lab should be understood narrowly and credibly. It is a web-based interactive ladder logic and digital twin simulator that supports ladder construction, simulation, variable inspection, analog and PID tools, and realistic industrial scenarios. It is useful because it allows rehearsal of high-risk validation tasks: observing I/O, tracing cause and effect, injecting abnormal conditions, and revising logic before site exposure.

### Step-by-step: running a sawtooth tracking test in OLLA Lab

Start with moderate amplitude and frequency. For example: - Amplitude: 100 engineering units - Frequency: 0.2 Hz - Initial derivative term: 0 or minimal

Use the available monitoring view or oscilloscope-style trend tools to observe:

• SP-to-PV lag during the ramp,
• output saturation,
• reset-edge overshoot,
• and any signs of windup.

Inject a realistic abnormal condition such as:

• actuator limit,
• delayed process response,
• noisy measurement,
• or a permissive/interlock interaction.

1. Create or open a PID-capable simulation project. Use a scenario with an analog process variable and a controllable setpoint path.
2. Bind the setpoint to a generated command signal. In the Variables Panel, assign the SP source to a waveform or equivalent command generator if available in the scenario configuration.
3. Select a sawtooth profile and define bounded test values.
4. Trend SP, PV, and controller output together.
5. Adjust gains one change at a time. Increase proportional gain until ramp tracking improves without inducing sustained oscillation. Then introduce or refine integral action carefully to reduce residual lag. Add derivative only if the process benefits and the implementation avoids harmful kick behavior.
6. Repeat with a fault or constraint case. A loop that only behaves in ideal conditions is not validated. It is merely unopposed.
7. Record the revision and outcome. Document what changed, what improved, and what tradeoff appeared. That is the beginning of commissioning judgment.

Example PID configuration artifact

[Language: Structured Text / PID Configuration]

PID_Target.SP := Waveform_Gen.Sawtooth_Out; PID_Target.Kp := 2.5; // Raised to reduce ramp tracking lag PID_Target.Ki := 1.2; // Moderated and clamped to limit windup PID_Target.Kd := 0.0; // Zeroed initially to avoid reset-edge kick

Image Alt Text: Screenshot of an OLLA Lab trend view showing a PID loop tracking a sawtooth setpoint, with the process variable lagging slightly during the ramp and recovering after the reset edge while the variables panel displays proportional and integral gain values.

Correct must be defined operationally before the test begins. Otherwise, tuning turns into aesthetic preference with better graphing.

For a sawtooth command-following exercise, an operational definition of correctness may include:

• PV tracking the ramp within a stated error band,
• no sustained oscillation,
• no prolonged output saturation,
• bounded overshoot after the reset edge,
• acceptable settling time after the drop,
• and no unsafe or unrealistic actuator demand in the simulated equipment model.

That definition should be tied to process purpose. A thermal batch ramp, a flow command, and a servo-like position loop do not share the same acceptable error envelope. “Looks pretty good” is not a control criterion.

This is also the right place to restate the bounded role of simulation. OLLA Lab can help engineers validate logic behavior, compare ladder state to simulated equipment state, and rehearse fault-aware revisions before field exposure. It does not certify site competence, functional safety compliance, or deployability by association. IEC 61508 and related safety practice are not satisfied because a graph looked tidy in a browser.

You should consider feedforward or setpoint shaping when the commanded trajectory is known, repeatable, and physically more demanding than the feedback loop can track cleanly without unacceptable gain tradeoffs. Sometimes the right answer is not more PID.

Feedforward is useful when:

• the command profile is predictable,
• major load changes are measurable,
• or the process has enough structure that proactive compensation is credible.

Setpoint shaping is useful when:

• the raw command contains discontinuities,
• actuator protection matters,
• or the process should not be asked to respond to mathematically abrupt edges.

A sawtooth is a useful diagnostic signal precisely because it is harsh. That does not mean the live process should be commanded with the same brutality. Validation signals and operational signals are not always the same thing.

The distinction between servo and regulatory behavior, the importance of anti-windup, and the role of simulation in control validation are well grounded in mainstream control engineering literature and recognized industrial practice.

Relevant support includes:

• ISA-aligned process control literature distinguishing servo and regulatory objectives,
• control systems texts addressing ramp tracking error and derivative kick,
• anti-windup research in industrial PID implementation,
• IEC 61508’s broader emphasis on lifecycle rigor, verification, and bounded claims around safety-related systems,
• and applied simulation literature showing the value of digital environments for testing control behavior before live deployment.

The careful point is this: simulation supports safer validation and better diagnosis. It does not erase the need for field commissioning, acceptance testing, or process-specific engineering judgment.

- IEC 61508 Functional Safety overview - exida Functional Safety and Automation resources - Åström & Hägglund, *Advanced PID Control* (ISA) - Skogestad (2003), PID tuning rules00062-8) - Tao et al. (2019), Digital Twin in Industry