Generated reference › Varying PID Controller — Control Systems/Linear Parameter Varying
kind: generated#block#control-systems-linear-parameter-varying

Varying PID Controller — Control Systems/Linear Parameter Varying

PID s varying

Control_Systems/Linear_Parameter_Varying/Varying_PID_Controller · 5 input / 1 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text

Description#

The block's own DESCRIPTION_HTML, rendered verbatim — the same text the config dialog's info panel and the library navigator show. Fix a wrong sentence in the block's .cpp (R-D9), never here.

Varying PID Controller

Control Systems / Linear Parameter Varying

A continuous-time PID controller with a filtered derivative whose four gains arrive as signals rather than as parameters, so the controller may be re-scheduled at any instant. It takes the error u and produces the control signal y, with two integrator states – the integrator xI and the derivative filter xF:

dTerm = N·( D·u − xF )
Parallel:  y = P·u + xI + dTerm
Ideal:     y = P·( u + xI + dTerm )
dxI/dt = I·u
dxF/dt = dTerm

The output reads the states before the update, and the update consumes the same dTerm the output used. That ordering is part of the specification, not an implementation detail – it is what fixes the block against Simulink's own once the gains move.

Ports

  • u – the error signal, of any size [p,q]. The controller is SISO and is applied independently to every entry, each carrying its own xI and xF.
  • P – the proportional gain at this instant, a scalar shared by every entry of u.
  • I – the integral gain at this instant, a scalar. Zero removes the integral action while it lasts.
  • D – the derivative gain at this instant, a scalar. Zero removes the derivative action, whatever N is.
  • N – the derivative filter bandwidth at this instant, a scalar. The filter pole is at −N, so N must stay positive for the filter state to decay – see the Notes.
  • Output – y, the same size as u.

The port order is Simulink's own: (u, P, I, D, N).

Parameters

  • Controller Form – how P enters the sum:
    • Parallel – P, I and D are independent gains on the three branches.
    • Ideal – P multiplies the whole controller, so it scales the integral and derivative action too.
  • Initial Condition (Integrator) – the integrator state at the start of the run, a scalar used for every entry. The I gain sits before the integrator, so this is the initial value of the integral term, not of the accumulated error.
  • Initial Condition (Filter) – the derivative filter's state at the start of the run, a scalar used for every entry. Because the filter method is pinned to Forward Euler (see Notes), it is expressed in exactly the same units Simulink expresses it in, with no conversion on either side.
  • Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period. Under a continuous solver the states are integrated and the rate is only a schedule; under a discrete solver, and in every exported core, it is the step of the forward-Euler update.

Everything else about the controller arrives on ports.

Code export

All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The gains are emitted as reads of the P/I/D/N signals rather than as constants, so a generated core re-schedules with them exactly as the simulation does; the only literals baked in are the sampling period, the chosen form and the two initial conditions.

A time-varying system cannot be pre-discretized, so the cores integrate with forward Euler on the gains they read each step rather than with a baked-in ZOH. The block's own discrete-solver path takes the identical step, which is why the two agree exactly instead of to O(Ts).

The three HDL targets carry the recursion in Q16.16 fixed point, which is possible only because the methods are pinned: any other choice would put a division by 1 + N·cF inside the loop and cost a fixed-point divider per entry per step. Verilog and SystemVerilog round rather than truncate when bringing an increment back down – Ts·I·u is small against one Q16.16 quantum, and a truncation would bias every step the same way and walk the integrator off over a long run. VHDL needs none of that, because sfixed keeps the fractional bits through resize().

Simulink bridge

Import and export, mapped to cstblocks/Linear Parameter Varying/Varying PID Controller (the library is cstblocks, not the "Control System Toolbox" display name, which add_block does not accept). "Controller Form" to Form (a 1:1 and therefore lossless pair), "Initial Condition (Integrator)" to InitialConditionForIntegrator and "Initial Condition (Filter)" to InitialConditionForFilter. The four gains need no parameter mapping at all – on both sides they are signals – and the port order is identical.

"Sampling Time (s)" crosses as SampleTime, under the standard name. That is worth stating because it is the exception in this family: every other Linear Parameter Varying block calls its rate Ts, and the continuous State Space and Observer Form blocks have no rate parameter at all. This one does, because underneath it is the stock PID Controller with ControllerParametersSource = external, which is what moves P/I/D/N onto ports.

Thirteen further Simulink parameters are always implied, with no config behind them: ControllerParametersSource = external, TimeDomain = Continuous-time, Controller = PID, IntegratorMethod = Forward Euler, FilterMethod = Forward Euler, UseFilter = on, InitialConditionSource = internal, UseExternalDerivativeSource = off, UseKiTs = off, LimitOutput = off, AntiWindupMode = none, ExternalReset = none and TrackingMode = off. Every one of them either defines the block as the varying one rather than the stock one, or would add an input port in Simulink that no config value here can add.

Notes

  • Continuous and stateful: two integrator states per entry of u. Under a discrete solver, and in every exported core, they step with forward Euler.
  • The two discretization methods are pinned to Forward Euler. On a continuous controller that is no restriction of the math – continuous integration is exactly cI = cF = 0 – but it does pin the two Simulink parameters. The alternatives divide by 1 + N·cF inside the loop, which a varying N cannot fold away at export time, and they make the filter initial condition ambiguous: Simulink scales it by N·Ts/(1 + N·cF), and there is no single N to use. At Forward Euler that scale is exactly 1. Use Discrete PID Controller for the other eight integrator × filter combinations, with constant gains.
  • Stability is the user's responsibility, in a way it is not on a fixed-gain controller. The filter pole is at −N, so a negative N makes xF grow, and nothing here can prevent it: N is a signal and its trajectory is not known until the run. Under a discrete solver the pole is 1 − Ts·N, so N must additionally stay below 2/Ts.
  • Integrator wind-up is not limited. With no output saturation to unwind against, a sustained error accumulates without bound – the same behaviour Simulink's block has with LimitOutput off.
  • Being time-varying, the block carries no state space and the model reduction and linear-analysis commands correctly refuse it. Use PID Controller when the gains are constant: it is linear, mergeable, and bakes the gains into the generated code.
  • The discrete counterpart is Discrete Varying PID, which is the same controller sampled.

Code facts#

FactValue
registered typeControl_Systems/Linear_Parameter_Varying/Varying_PID_Controller
familyControl_Systems/Linear_Parameter_Varying
solver environment classICoreBlock_0_Control_Systems_1_Linear_Parameter_Varying_2_Varying_PID_Controller
sourcesrc/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Linear_Parameter_Varying/Varying_PID_Controller/ICoreBlock_0_Control_Systems_1_Linear_Parameter_Varying_2_Varying_PID_Controller.cpp
headersrc/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Linear_Parameter_Varying/Varying_PID_Controller/ICoreBlock_0_Control_Systems_1_Linear_Parameter_Varying_2_Varying_PID_Controller.h
default size on canvas140 × 120 px
ports at insert5 in, 1 out
code generators implementedPython, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text

Ports#

#DirectionSignal typeDescription label
1inICoreDoubleu
2inICoreDoubleP
3inICoreDoubleI
4inICoreDoubleD
5inICoreDoubleN
6outICoreDouble

Ports the constructor creates. A block whose port list changes with its configuration adds or removes ports at load time; the count above is the one a freshly inserted block has.

Configuration variables#

Config variableDefaultSimulink parameter
Controller FormParallel%~%Ideal~~ParallelForm
Initial Condition (Integrator)0InitialConditionForIntegrator
Initial Condition (Filter)0InitialConditionForFilter

Every block also carries Sampling Time (s) from ICoreBlockSolverEnvironment: zero or less inherits the solver's rate, a positive value runs the block at that period.

supportSupport::Both
Simulink pathcstblocks/Linear Parameter Varying/Varying PID Controller
port-count rulePortsParam::None
SampleTime parameteryes
always setControllerParametersSource = external, TimeDomain = Continuous-time, Controller = PID, IntegratorMethod = Forward Euler, FilterMethod = Forward Euler, UseFilter = on, InitialConditionSource = internal, UseExternalDerivativeSource = off, UseKiTs = off, LimitOutput = off, AntiWindupMode = none, ExternalReset = none, TrackingMode = off
ICore configSimulink parameterValue translation
Controller FormFormParallelParallel, IdealIdeal
Initial Condition (Integrator)InitialConditionForIntegratorpasses through
Initial Condition (Filter)InitialConditionForFilterpasses through

Caveat (shown to the user): the four gains are signals on both sides, so none of them is a parameter to carry, and the port order (u, P, I, D, N) is identical; the integrator and filter methods are PINNED to Forward Euler, which on a continuous controller is what the math already is (cI = cF = 0) but which also keeps a divider by 1 + N*cF out of the sample loop that a varying N could not fold away at export time, and keeps InitialConditionForFilter unambiguous -- use PID Controller for constant gains and Discrete PID Controller for the other eight combinations; output saturation/anti-windup, external reset, an external derivative source, external initial conditions and tracking mode are not supported, each adding an input port in Simulink that no config value here can add

Catalog contract: src/ICoreSDK/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h

Description vs code#

The lists agree. check_block_descriptions.py finds no disagreement between the description's Ports, Parameters, Code export and Simulink bridge lists and the code's.

The verdict above is tools/docs/check_block_descriptions.py (P7.1), which compares LISTS. It cannot read a sentence: "stateless" on a block with a state, an initial-value semantic the recursion does not implement, a "not synthesizable" caveat the HDL banner contradicts. That is the agent audit (P7.3) on BLOCK_DESCRIPTION_AUDIT.md, and this tool's green is not a substitute for one.

File banner (developer view)#

The top comment of the block's .cpp — the maths, the realization and the export strategy, addressed to whoever changes it. It must not contradict the description above (P7.5).

Varying PID Controller — a continuous filtered-derivative PID whose four gains are SIGNALS dTerm = N*(D*u - xF) y = P*u + xI + dTerm (Parallel) y = P*( u + xI + dTerm ) (Ideal) dxI/dt = I*u dxF/dt = dTerm

The realization is Simulink's, reused from Control_Systems/Discrete/Discrete_PID_Controller at cI = cF = 0 rather than re-derived -- see the header, including why both methods are pinned. The state is the block's own [2K,1] state vector, [xI; xF] over the K entries of u, because the solver has to integrate it; the exported cores keep the same two accumulators and step them with forward Euler, which is exactly what compute_f_discrete does.

Sample results#

Varying PID Controller — Step: 0 -> 1 at t = 1 sVarying PID Controller — Step: 0 -> 1 at t = 1 s0246012345t (s)in ICoreDouble-Out-0in ICoreDouble-Out-0in ICoreDouble-Out-0out ICoreDouble-Out-0

The same rig also ran:

StimulusWhat it isOutput range
impulseImpulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair)0 … 2.009
rampRamp: slope 1 from t = 00 … 110.3
sineSine Wave: amplitude 1, 2 rad/s, no phase, no bias0 … 3.661
tableRepeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample-5.371 … 35.32

Plotted: step — Step: 0 -> 1 at t = 1 s

Category dynamic · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Linear_Parameter_Varying__Varying_PID_Controller.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).