Sometimes the problem with a signal is not noise but speed: a setpoint that jumps in one step, an output that would slam a valve open, or a glitch that asks a value to leap somewhere impossible in an instant. A slew-rate limiter is the small piece of logic that refuses to let a value change faster than an allowed rate, releasing the change over several scans instead of all at once. This guide explains how a slew-rate limiter works, how the max-change-per-dt implementation is built, how it differs from a low-pass filter, and where it is used on setpoints and outputs.
Slew-rate limiter in one line: A slew-rate limiter is logic that caps how fast a signal, setpoint, or output may change, allowing it to move only a maximum amount per unit of time and ramping it toward a new target over several scans rather than stepping. It is implemented by computing the maximum allowed change for the elapsed time and clamping the actual change to that limit each scan. Unlike a low-pass filter, which weights a smooth average, it enforces a hard bound on rate of change, so it protects equipment from step changes and rejects impossible jumps.
A slew-rate limiter sits between a desired value and the value actually applied, and its job is to make sure the applied value never changes faster than a configured rate. When the desired value jumps, the limiter does not follow it in one step; instead it moves the applied value toward the new target by a bounded amount each scan, so the value ramps rather than leaps. Once the applied value catches up to the target, the limiter stops interfering and passes the value through unchanged until the next fast move. The rate at which it is allowed to ramp, expressed as an amount per unit of time, is the limiter's single defining parameter.
The behavior is asymmetric to the size of the change, not to its direction. A small change that is already within the allowed rate passes straight through untouched, because it does not exceed the cap. Only a change large or fast enough to break the rate limit gets throttled, and then only the excess is held back, spread across subsequent scans. This means the limiter is invisible during normal, gentle operation and only asserts itself when something tries to move the value abruptly, which is exactly when protection is wanted.
The point of enforcing a maximum rate is twofold. First, it protects equipment and the process from the shock of a step change: a setpoint that jumps or an output that slams can cause pressure surges, mechanical stress, or process upsets that a gradual ramp avoids. Second, it rejects the impossible: a real physical quantity cannot teleport, so a value that suddenly demands a change faster than anything real could produce is almost certainly a glitch, and refusing to follow it faster than a plausible rate blunts the effect of such spikes without discarding legitimate movement.
The implementation is a clamp on the per-scan change. Each execution, the limiter works out the maximum amount the value is permitted to move by multiplying the allowed rate by the elapsed time since it last ran, the dt. That product is the largest step allowed this scan. It then compares the desired change, the difference between the new target and the current applied value, against that maximum. If the desired change is within the limit, it applies it in full; if it exceeds the limit in either direction, it applies only the maximum allowed amount, moving that far toward the target and no further this scan.
Using the actual elapsed time rather than assuming a fixed scan is what makes the rate limit mean a real rate. If the code simply added a fixed increment every scan, the effective rate would change whenever the scan time changed, so a busier controller would ramp slower. Multiplying the allowed rate by the measured dt keeps the ramp at the intended amount per second regardless of how the scan wanders, which ties the slew-rate limiter directly to the same delta-time discipline that underlies totalizers and derivatives. A limiter that ignores dt gives a rate that drifts with CPU load.
Two practical details round out a good implementation. Because the limiter holds internal state, the current applied value, it must be initialized sensibly, usually to the current value at startup so it does not ramp from zero on the first scan. And when the process is in a mode where the ramp should not apply, such as tracking a manual value, the applied value is often forced to follow so that when normal control resumes the limiter starts from where things actually are rather than jerking. Handled this way, the limiter contributes to a bumpless change, letting a value move to a new target smoothly and without a discontinuity.
A slew-rate limiter and a low-pass filter both smooth abrupt movement, but they do fundamentally different things and are not interchangeable. A low-pass filter produces a weighted average, blending each new sample with the accumulated history, so it softens fast changes but does not impose a hard ceiling on rate; a large enough input still pushes the output quickly, just with rounded corners, and the output can overshoot toward the input. A slew-rate limiter imposes a strict bound: the output cannot move faster than the allowed rate no matter how large the demand, and it produces a straight ramp rather than an exponential approach. One weights an average; the other clamps a rate.
That distinction determines when to use which. A low-pass filter is the right tool for taming ongoing measurement noise, where you want to attenuate jitter while still following the signal. A slew-rate limiter is the right tool when the movement is legitimate but must be paced, or when a single large jump must be refused: pacing a setpoint so a loop does not chase a step, limiting how fast an output opens a valve to protect the process, or bounding a signal so a momentary glitch cannot drag it far in one scan. Because a real process variable has physical limits on how fast it can move, a slew limit that reflects those limits also serves as a sanity check that rejects non-physical jumps.
In field control, slew-rate limiters most often guard setpoints and outputs: an operator or a supervisory command that changes a setpoint is ramped so the change is gentle, and a controller output driving a valve or a drive is rate-limited so equipment is not shocked. In a cloud SCADA architecture such as Merobix, the enforcement of an output slew limit belongs at the edge, where the control action is applied in real time, because only the controller sees every scan and can hold state safely. The platform's role is to make a setpoint change explicit and to carry the limited and unlimited values so an operator can see that a commanded change is ramping in as intended rather than jumping. Being able to see both the target and the ramping applied value on the same trend confirms the limiter is doing its job and helps distinguish a deliberately paced change from a stuck or slow signal.
It caps how fast a value may change by allowing only a maximum amount of movement per unit of time. Each scan it multiplies the allowed rate by the elapsed time to get the largest step permitted, compares the desired change against that limit, and applies either the full change if it is within the limit or just the maximum allowed amount if it exceeds it. Large jumps are therefore spread over several scans into a ramp, while small changes pass through untouched.
A low-pass filter produces a weighted average that softens fast changes but does not impose a hard ceiling on rate, so a large input still moves the output quickly with rounded corners. A slew-rate limiter enforces a strict bound: the output cannot move faster than the allowed rate no matter how large the demand, producing a straight ramp. Use a filter to attenuate ongoing noise and a slew limiter to pace legitimate movement or refuse a single impossible jump.
Most often on setpoints and outputs. A setpoint change is ramped so a control loop does not chase a step and cause a surge, and a controller output driving a valve or a drive is rate-limited so equipment is not shocked by a slam. A slew limit also rejects non-physical jumps, since a real process variable cannot change faster than its physical limits, so it blunts the effect of glitches while still following legitimate movement.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.