Generated reference › Second Order Integrator — Control Systems/Base Blocks
kind: generated#block#control-systems-base-blocks

Second Order Integrator — Control Systems/Base Blocks

1 s 2

Control_Systems/Base_Blocks/Second_Order_Integrator · 1 input / 2 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.

Second-Order Integrator

Control Systems / Base Blocks

Integrates its input twice with respect to time: d²x/dt² = u, the transfer function 1/s². It reports both the position x and the velocity dx/dt. The integrator is scalar and is applied independently to every entry of the input signal, so both outputs have the input's size.

Ports

  • Input u – the second derivative to integrate, of any size [m,n].
  • Output x – the twice-integrated signal, of the same size.
  • Output dx/dt – the once-integrated signal (the velocity), of the same size.

Parameters

  • Initial Value x / Initial Value dx/dt – the two states at the start of the run. A scalar is broadcast to every entry; a matrix must match the input's size exactly.
  • Limit xoff or on. When on, x is held inside Upper Limit x / Lower Limit x and integration of x stops at a limit instead of winding up.
  • Upper Limit x / Lower Limit x – the band for x, used only while Limit x is on. They default to the widest finite doubles, which stand in for Simulink's ±infinity.
  • Limit dx/dtoff or on. When on, dx/dt is held inside its own band and stops integrating at a limit, exactly as x does.
  • Upper Limit dx/dt / Lower Limit dx/dt – the band for dx/dt, used only while Limit dx/dt is on.
  • Wrap xoff or on. When on, x is wrapped into Wrapped Lower Value xWrapped Upper Value x instead of growing without bound – the usual choice for an angle. Wrapping and Limit x are alternatives: with both on, wrapping is applied and the block reports that the x band was ignored.
  • Wrapped Upper Value x / Wrapped Lower Value x – the wrap range, used only while Wrap x is on. They default to ±π.
  • Reinitialize dx/dt at Saturationoff or on. When on, reaching either x limit also forces dx/dt to zero, so the velocity does not survive an impact. Meaningful only while Limit x is on.
  • Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.

Code export

All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The exported block carries the discretization of the scalar 1/s² system for the run's method, so generated code matches the in-app simulation for every method, not just forward Euler. The twelve recursion coefficients are baked into the body at export time; the limits, the wrap range and the initial states are baked in too, so none of them is retunable on the generated core.

Wrapping costs a floored modulo. On the three HDL targets that is evaluated in Q16.16 through a constant reciprocal, so a wrap range that is not a clean binary fraction carries up to one quantum (about 1.5×10-5) of extra error per wrap; the software targets use their native floor and do not.

Wrapping and reinitialization are verified on the seven software targets only. Both put a discontinuity – a wrap boundary, a saturation latch – under the control of a state that has been integrated twice. The HDL datapath carries that state in Q16.16, integration turns the quantum into a slow drift, and the drift moves the step at which the state crosses the trigger. The exported core is correct either side of that step, but a sample-by-sample comparison against a double-precision reference scores the whole jump whenever the two disagree about which sample it falls on, so the suite reports those combinations as not comparable rather than passing or failing them. The HDL cores themselves are unaffected: with limiting alone, or with neither, all three targets are verified normally.

Simulink bridge

Import and export, mapped to simulink/Continuous/Integrator, Second-Order. "Initial Value x" to ICX, "Initial Value dx/dt" to ICDXDT, "Limit x" to LimitX, "Upper/Lower Limit x" to UpperLimitX/LowerLimitX, "Limit dx/dt" to LimitDXDT, "Upper/Lower Limit dx/dt" to UpperLimitDXDT/LowerLimitDXDT, "Wrap x" to WrapX, "Wrapped Upper/Lower Value x" to WrappedUpperValueX/WrappedLowerValueX, and "Reinitialize dx/dt at Saturation" to ReinitDXDTwhenXreachesSaturation.

Simulink's Integrator, Second-Order Limited is the same Simulink block with its limits preset on, so it imports to this block too, with those presets applied. The block always shows both outputs from internal initial conditions (ShowOutput both, ICSourceX and ICSourceDXDT internal). External reset does not cross, nor do external initial conditions: both show extra input ports in Simulink, and no config value here can add or remove a port. This Simulink block has no SampleTime parameter, so "Sampling Time (s)" stays on the ICore side and an explicitly rated block reports that its rate did not cross.

Notes

  • Stateful: two continuous states per input entry, x and dx/dt.
  • Wrapping is applied to the x output rather than to the stored state. Neither dx/dt = v nor dv/dt = u depends on x, so the trajectories are identical, and the continuous and discrete paths stay in exact agreement.

Code facts#

FactValue
registered typeControl_Systems/Base_Blocks/Second_Order_Integrator
familyControl_Systems/Base_Blocks
solver environment classICoreBlock_0_Control_Systems_1_Base_Blocks_2_Second_Order_Integrator
sourcesrc/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Base_Blocks/Second_Order_Integrator/ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Second_Order_Integrator.cpp
headersrc/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Base_Blocks/Second_Order_Integrator/ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Second_Order_Integrator.h
default size on canvas80 × 80 px
ports at insert1 in, 2 out
code generators implementedPython, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text

Ports#

#DirectionSignal typeDescription label
1inICoreDoubleu
2outICoreDoublex
3outICoreDoubledx/dt

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
Initial Value x0ICX
Initial Value dx/dt0ICDXDT
Limit xoff%~%on~~offLimitX
Upper Limit x1e+308UpperLimitX
Lower Limit x-1e+308LowerLimitX
Limit dx/dtoff%~%on~~offLimitDXDT
Upper Limit dx/dt1e+308UpperLimitDXDT
Lower Limit dx/dt-1e+308LowerLimitDXDT
Wrap xoff%~%on~~offWrapX
Wrapped Upper Value x3.1415926535897931WrappedUpperValueX
Wrapped Lower Value x-3.1415926535897931WrappedLowerValueX
Reinitialize dx/dt at Saturationoff%~%on~~offReinitDXDTwhenXreachesSaturation

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 pathsimulink/Continuous/Integrator, Second-Order
port-count rulePortsParam::None
SampleTime parameterno — the counterpart defines none; the rate stays on the ICore side
always setShowOutput = both, ICSourceX = internal, ICSourceDXDT = internal
ICore configSimulink parameterValue translation
Initial Value xICXpasses through
Initial Value dx/dtICDXDTpasses through
Limit xLimitXoffoff, onon
Upper Limit xUpperLimitXpasses through
Lower Limit xLowerLimitXpasses through
Limit dx/dtLimitDXDToffoff, onon
Upper Limit dx/dtUpperLimitDXDTpasses through
Lower Limit dx/dtLowerLimitDXDTpasses through
Wrap xWrapXoffoff, onon
Wrapped Upper Value xWrappedUpperValueXpasses through
Wrapped Lower Value xWrappedLowerValueXpasses through
Reinitialize dx/dt at SaturationReinitDXDTwhenXreachesSaturationoffoff, onon

Caveat (shown to the user): external reset and external initial conditions are not supported; limiting, wrapping and reinitialization are

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).

Second-Order Integrator block — per-entry scalar double integrator Solves d2x/dt2 = u. The continuous system is the SCALAR double integrator A = [0 1; 0 0], Bu = [0; 1], C = I2, Du = [0; 0] applied INDEPENDENTLY to every entry of the input signal. Both output ports carry the SAME signal size as the input: port 0 is x, port 1 is dx/dt. Each entry owns its own pair of scalar states.

STATE LAYOUT. compute_f may return one ICoreMatrix, so the two states per entry are STACKED: an input of [r,c] gives a [2r,c] state whose top r rows are x and whose bottom r rows are dx/dt. The entries stay independent either way.

Simulation: the discrete path runs, per entry, the recursion yx = c00*x + c01*v + d0*u (outputs come from the CURRENT state) yv = c10*x + c11*v + d1*u x' = a00*x + a01*v + b0*u v' = a10*x + a11*v + b1*u whose twelve scalars are the discretization of the 1x1-input/2-state system above per the model's method. The continuous path is just dx/dt = v, dv/dt = u, y = (x, v).

Code export (Python/MATLAB/Java/Rust/C/C++ and HDL/PLC) Every generator realizes that SAME recursion per [r,c] entry, structurally identical to the in-app simulation, with the twelve scalars embedded as constants and the per-entry states seeded with the (embedded) initial values. discreteScalars() calls discretize() and reads the DISCRETE state space, so — exactly as with the first-order Integrator — the export matches the in-app simulation for EVERY discretization method, not just forward Euler. It also means Cd/Dd are read rather than assumed to be I2/0, which they are not under Tustin or Matched.

Limiting, wrapping and reinitialization All four features are config-only, so they cross to Simulink and cost no ports. The order they are applied in is fixed and identical in all eleven realizations (the four compute_* here and the ten backends) — see applyOutputStage/applyStateStage below. Wrapping is applied to the x OUTPUT rather than to the stored state. That is not an approximation: neither dx/dt = v nor dv/dt = u depends on x, so a wrapped state and a wrapped output produce identical trajectories, and keeping the state unwrapped is what lets the continuous and discrete paths agree bit for bit.

Sample results#

Second Order Integrator — Step: 0 -> 1 at t = 1 sSecond Order Integrator — Step: 0 -> 1 at t = 1 s0510012345t (s)in ICoreDouble-Out-0out ICoreDouble-Out-0out ICoreDouble-Out-1

The same rig also ran:

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

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__Base_Blocks__Second_Order_Integrator.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).