How to Analyze PID Settling Time with Square Wave Setpoints in OLLA Lab

A square wave setpoint forces a PID loop through an abrupt step response, making rise time, peak overshoot, and settling time directly measurable. In OLLA Lab, engineers can apply that test to simulated equipment and digital twins, observe loop behavior safely, and tune gains without imposing the same stress on live actuators.

A common misconception is that a loop is “well tuned” if it eventually reaches setpoint. That standard is too weak to be useful. A loop that reaches setpoint with excessive overshoot, long settling time, or repeated output saturation is not well behaved; it is merely finished arguing with physics.

Ampergon Vallis Metric: In an internal OLLA Lab benchmark using a standard liquid-level digital twin, disabling derivative filtering during a 50% square-wave setpoint test increased measured peak overshoot by 32% relative to the filtered baseline. Methodology: n=20 repeated square-wave trials on one standard level-control scenario, baseline comparator = same loop with derivative filtering enabled, time window = March 2026 benchmark session. This supports a narrow point: abrupt setpoint changes can materially amplify transient stress when damping is reduced. It does not support a universal overshoot percentage for all PID loops, processes, or actuator classes.

This matters because square-wave testing is one of the cleanest ways to expose how a loop actually recovers, while OLLA Lab provides a bounded environment for that test before a real valve, drive, or pump pays the tuition.

A square wave step response is the process variable’s transient behavior after the setpoint is forced to jump between discrete levels with near-instantaneous edges. In control terms, it is a repeated step test.

Engineers use it because a square wave is an aggressive disturbance to the controller’s command path. It reveals how the loop accelerates, overshoots, damps, and settles after a sudden demand change. If the tuning is weak, the waveform makes that weakness difficult to hide.

In strict terms, the square wave is not “real process behavior.” It is a diagnostic input. Plants do not usually ask for mathematically sharp setpoint edges; engineers do, because they want the loop to confess.

The 3 phases of system recovery

The standard step-response metrics are observable and bounded:

- Rise Time (\(t_r\)): the time required for the process variable to move from 10% to 90% of the final value after the step. - Peak Overshoot (\(M_p\)): the maximum amount by which the process variable exceeds the final setpoint, usually expressed as a percentage. - Settling Time (\(t_s\)): the time required for the process variable to enter and remain within a specified error band around the final value, commonly ±2% or ±5%.

These definitions are standard control-theory anchors, not house vocabulary. If the error band is not stated, “settling time” becomes editorial fog.

Why square waves are such effective loop stress tests

A square wave tests more than whether the controller can move the process variable. It tests whether the loop can recover cleanly under abrupt demand.

Specifically, it exposes:

• excessive proportional aggression, which often appears as large overshoot,
• weak damping, which appears as ringing or repeated oscillation,
• poor integral balance, which shows up as slow bias correction or prolonged hunting,
• derivative misuse, especially when measurement noise or setpoint discontinuities produce output spikes,
• actuator saturation, where the controller asks for more movement than the final control element can deliver.

That is the useful contrast: syntax versus recoverability. A PID block can be configured correctly and still behave badly.

Sudden setpoint changes increase mechanical and electrical stress because the controller output often responds with a large, fast correction that pushes the actuator toward its limits. Real equipment does not move like algebra.

When a loop sees a sharp setpoint edge, several things can happen at once:

• the proportional term reacts immediately to the full error,
• the derivative term, if applied to error without adequate filtering or structure, can produce a large transient spike,
• the controller output can saturate at a high or low limit,
• the final control element may accelerate, reverse, or cycle more aggressively than it would under smoother demand changes.

On live equipment, that can translate into:

• valve stem and seat wear,
• damper linkage fatigue,
• pump and motor starts under unfavorable hydraulic conditions,
• pressure shocks such as water hammer,
• thermal shock in temperature-control applications,
• nuisance trips, blown fuses, or protective interlock activation.

The exact failure mode depends on the process. The principle does not. A 10-inch butterfly valve does not care that the square wave looked elegant on a trend.

What “derivative kick” means in practice

Derivative kick refers to a large transient controller response caused by a sudden change in the error signal, especially when derivative action is taken on error rather than on measurement. A square-wave setpoint is the classic trigger.

In practice, derivative kick can:

• create a sharp output spike at the moment of the setpoint transition,
• push an actuator briefly into saturation,
• exaggerate overshoot rather than reduce it,
• make the loop appear unstable even when the underlying process is reasonably tame.

This is why derivative action is often filtered and why many industrial implementations are structured to reduce setpoint-induced derivative shock. The derivative term is useful, but it is not a free lunch.

“Simulation-Ready” should be defined operationally, not aspirationally. In this context, it means an engineer can prove, observe, diagnose, and harden control behavior against realistic process response before the logic reaches a live process.

For PID step testing, a Simulation-Ready workflow includes the ability to:

• inject a known setpoint change into a simulated loop,
• observe the process variable, controller output, and relevant tags in time sequence,
• define what “correct” means using measurable criteria such as overshoot and settling band,
• compare ladder logic state against simulated equipment state,
• introduce an abnormal condition or fault,
• revise the logic or tuning and verify the improvement.

That is the shift Ampergon Vallis cares about: syntax versus deployability. Writing a rung is not the same as validating a loop.

OLLA Lab provides a web-based environment where engineers can build ladder logic, run simulation, inspect variables and I/O, and validate control behavior against realistic simulated equipment. In the square-wave test context, its value is bounded and practical: it is a risk-contained place to rehearse an aggressive step-response test before applying similar logic to physical hardware.

Within that workflow, engineers can:

• build or modify the ladder logic containing the PID instruction,
• bind simulated tags to process variables and setpoint values,
• run the loop in simulation mode,
• observe variable changes and output behavior over time,
• compare control logic behavior against the digital twin or scenario state,
• repeat the test after tuning changes without imposing wear on real actuators.

This is where OLLA Lab becomes operationally useful. It lets engineers test cause and effect, not just diagram structure.

A practical square-wave routing pattern

At the logic level, the square-wave source is simply routed into the PID setpoint tag so the loop sees a repeated step demand.

[Language: Ladder Diagram] // Routing simulated square-wave source to PID setpoint [MOV] Source: Sim_WaveGen_Square.Out Dest: Flow_PID.SP

The exact tag names will vary by project. The engineering point does not: the setpoint source is being driven by a deterministic test signal so the response can be measured.

What to observe during the test

When the square wave is applied, monitor at least these signals:

- Setpoint (SP): confirms the exact timing and amplitude of the command step, - Process Variable (PV): shows the actual loop response, - Controller Output (CV/OUT): reveals saturation, spikes, or oscillatory demand, - Mode and status bits: confirms whether the PID is in the intended operating mode, - Relevant interlocks or permissives: ensures abnormal logic is not masking loop behavior.

If the platform scenario includes analog tools, PID dashboards, and variable panels, use them together. A trend without context is only half a diagnosis.

The correct method is to define the test boundaries before you tune. If the acceptance criteria move every time the trend looks ugly, the loop is not the only unstable thing in the room.

Use this sequence:

1. Define the step amplitude Choose the square-wave transition size, such as 20% to 70% of setpoint range.
2. State the settling band explicitly Use a bounded criterion such as ±2% or ±5% of final value.
3. Record the response trend Capture SP, PV, and controller output over the full transient.
4. Measure rise time Determine the time from 10% to 90% of the final PV change.
5. Measure peak overshoot Find the maximum PV excursion above the final setpoint and express it as a percentage.
6. Measure settling time Identify when the PV enters the defined error band and remains there without leaving it.
7. Repeat across several cycles A single clean cycle can flatter a noisy or nonlinear loop. Repetition is cheap in simulation and expensive in the field.

Common measurement mistakes

Several errors make step-response analysis look more precise than it is:

• calling the first crossing of setpoint “settled,”
• failing to specify the error band,
• ignoring output saturation,
• measuring only one transition edge,
• comparing loops using different step amplitudes,
• treating noisy PV traces as if they were ideal textbook curves.

A trend can be visually persuasive and analytically wrong. Those are not the same thing.

The goal is not the fastest possible rise. The goal is a controlled transient that reaches the new setpoint with acceptable overshoot, acceptable actuator demand, and stable settling. Fast and violent is still violent.

Tuning adjustments for step responses

Lower proportional gain usually softens the initial reaction and reduces peak overshoot. Too little proportional action, however, can make the loop sluggish.

• Reduce Proportional (P) gain when overshoot is excessive

Integral action corrects steady-state offset, but too much can prolong oscillation and increase settling time.

• Adjust Integral (I) action to remove residual error

Derivative action can improve damping and reduce overshoot, but abrupt setpoint edges can produce output spikes if derivative structure or filtering is poor.

• Apply Derivative (D) carefully and filter it appropriately

If the output is pinned at a limit, the loop may be constrained by hardware capability rather than controller math.

• Check for actuator saturation before blaming the tuning alone

A level loop, temperature loop, and fast flow loop do not share the same acceptable transient behavior.

• Tune against the process objective, not the prettiest curve

A practical tuning sequence in simulation

A disciplined workflow in OLLA Lab looks like this:

• start with conservative gains,
• apply the square-wave setpoint,
• observe whether the output saturates,
• reduce overshoot first if the transient is aggressive,
• tighten settling time second,
• rerun the same test conditions after each change,
• document the before-and-after response using the same measurement band.

This is slower than random knob turning and much faster than replacing damaged hardware.

A credible tuning record is not a screenshot gallery. It is a compact body of engineering evidence showing what was tested, what failed, what changed, and what improved.

Use this structure:

1. System Description Identify the process, loop purpose, manipulated variable, measured variable, and operating range.
2. Operational definition of “correct” State the acceptance criteria, such as maximum overshoot, settling band, settling time target, and any actuator constraints.
3. Ladder logic and simulated equipment state Show the relevant PID logic, tag mapping, and the corresponding simulated equipment condition during the test.
4. The injected fault case Record the disturbance or adverse condition, such as derivative filtering disabled, sensor lag, output limit reached, or permissive interruption.
5. The revision made Document the tuning or logic change applied after the fault was observed.
6. Lessons learned Summarize what the response revealed about the loop, the actuator, and the control philosophy.

That format is useful because it preserves engineering reasoning. Anyone can save a trend. Fewer people preserve the decision trail that made the trend matter.

Square-wave testing should be avoided on live equipment when the transient itself introduces unacceptable process, mechanical, or safety risk. This includes systems where abrupt output changes can damage equipment, destabilize upstream or downstream units, or trigger protective shutdowns.

Use particular caution with:

• large valves and dampers with significant inertia,
• pump systems vulnerable to hydraulic shock,
• thermal systems sensitive to rapid energy input changes,
• pressure-control loops near trip thresholds,
• integrated process trains where one loop upset propagates into several others,
• any system where abnormal movement could challenge a safety function or protective layer.

This is also where product positioning must remain honest. OLLA Lab is a validation and rehearsal environment for high-risk commissioning tasks. It is not a substitute for site procedures, formal safety review, operator coordination, or functional safety qualification.

Digital twin validation improves square-wave testing by making the loop response observable against a realistic equipment model rather than against abstract tags alone. The value is not visual novelty. The value is behavioral context.

In a digital twin or realistic machine model, the engineer can compare:

• commanded state versus simulated physical response,
• ladder logic transitions versus process-state transitions,
• controller output versus actuator behavior,
• abnormal conditions versus fault-handling logic,
• tuning changes versus their effect on the broader sequence.

That matters because commissioning failures rarely come from one isolated rung. They come from interactions: permissives, delays, actuator limits, process lag, alarm logic, and sequence timing arriving in the same room at the same time.

OLLA Lab credibly adds a web-based rehearsal environment where engineers can build ladder logic, run simulation, inspect I/O and variables, work through realistic scenarios, and validate behavior against digital twins before touching live equipment. That is a bounded claim, and it is enough.

In this article’s context, the practical advantages are:

• repeated square-wave testing without physical wear,
• visibility into tags, analog values, and PID-related variables,
• scenario-based context for pumps, flow, level, HVAC, utilities, and process systems,
• guided support through the built-in AI lab coach when the user stalls or misreads the response,
• a structured place to compare “what the logic says” with “what the equipment model does.”

It should not be framed as a magic tuning oracle. It is a controlled environment for validation, iteration, and fault-aware learning.

- 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