Rate Limiter — Control Systems/Discontinuities

Rate Limiter

Control Systems / Discontinuities

Caps how fast the output is allowed to follow the input – an actuator that cannot slew instantly, a ramp-limited setpoint. With y the previously held output and dt the block's sampling period:

and d = u − y the step the input is asking for:

• d > rising·dt → y = y + rising·dt
• d < falling·dt → y = y + falling·dt
• otherwise → y = u, the demanded step already fits

So the output climbs by at most rising units per second and falls by at most |falling| units per second, and passes the input straight through whenever the step is inside the band. Applied entry by entry.

Ports

• Input – the demanded signal u, of any size [m,n].
• Output – the rate-limited signal y, of the SAME size [m,n]. The block never reshapes a signal.

Parameters

• Rising Slew Rate – scalar, the maximum upward rate in units per second. Defaults to 1, as in Simulink.
• Falling Slew Rate – scalar, the maximum downward rate, and therefore negative. Defaults to −1. It must not exceed the rising rate, which would leave an empty band; that is reported rather than silently reordered.
• Initial Condition – scalar, where the held output starts. Defaults to 0. This is a real seed: the first sample is already clamped against it, so a block starting at 0.4 with a zero input walks down at the falling rate rather than jumping.
• Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period. It multiplies both rates into the per-sample step, so halving the rate halves the step and the block is only as smooth as its sampling. ICore-side only – see the bridge note below.

All three parameters are scalars; per-entry vectors are not implemented and are reported rather than broadcast from their first entry.

Code export

All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The two rates are baked in already multiplied by the sampling period, so the generated core carries one constant per direction and never divides by a time step. The exported state is the held output itself, one value per entry, seeded with the initial condition – so a generated core starts where the in-app block does. The three HDL targets are fully fixed-point: the whole step is an add, a compare and a clamp, with no real arithmetic.

Simulink bridge

Import and export, mapped to simulink/Discontinuities/Rate Limiter. "Rising Slew Rate" to RisingSlewLimit, "Falling Slew Rate" to FallingSlewLimit and "Initial Condition" to InitialCondition, all as plain pass-through values, so the round trip is lossless. SampleTimeMode is always written as inherited, which is the mode this block implements. "Sampling Time (s)" does NOT cross: this Simulink block has no SampleTime parameter, so the rate stays on the ICore side and an explicitly set one is reported rather than written. That matters more here than on most blocks, because the sampling period is part of the arithmetic – a rig whose two sides step differently produces genuinely different slew steps.

Notes

• Stateful: one held output per input entry.
• Discrete by nature – the band is a step per sample, so the block always runs at its own rate rather than being pushed through a continuous solver's stages.
• Setting either rate to zero freezes the output in that direction; both at zero holds it at the initial condition forever.
• Not linear, and so deliberately carries no state space – the clamp is a genuine nonlinearity that no A/B/C/D can express.