Slider Gain — Control Systems/Base Blocks
Control_Systems/Base_Blocks/Slider_Gain · 1 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.
Slider Gain
Control Systems / Base Blocks
Multiplies the input by a scalar gain: y = k·u, applied entry by entry. The gain is declared together with the range it may be adjusted over, which is what separates this block from Gain: it is the block to reach for when a value is meant to be swept while tuning, and the range says how far.
Ports
- Input – the signal u, of any size [m,n].
- Output – the scaled signal y, of the SAME size [m,n]. A scalar gain cannot change a signal's dimensions, so unlike Gain this block never reshapes one.
Parameters
- Minimum – the low end of the adjustment range. Scalar; defaults
to
0, as in Simulink. - Maximum – the high end. Scalar; defaults to
2. Must be greater than or equal to Minimum. - Gain – the gain k. Scalar only – a matrix
belongs on a Gain block, and Simulink's Slider Gain rejects one outright –
and it must lie between Minimum and Maximum. A gain outside the range is
reported and the run is stopped, rather than exported into a Simulink script that
cannot run; widen the range or move the gain. Defaults to
1, which passes the signal through unchanged. - 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 gain is exposed as a tunable parameter on the generated core
– params in the software targets, a parameter port on the
three HDL cores, a VAR_INPUT on the function block in Structured
Text – so it can be retuned on the deployed core without re-exporting.
That is the point of a slider. Minimum and Maximum do not reach the core:
they bound the editing gesture, not the arithmetic, and a deployed core has no
gesture to bound.
The three HDL targets carry the multiplication in Q16.16 fixed point and are fully synthesizable. Note that the gain crosses into the core as a Q16.16 parameter, so a gain finer than one quantum (1.5×10-5) is not representable there.
Simulink bridge
Import and export, mapped to simulink/Math Operations/Slider Gain:
"Minimum" to low, "Maximum" to high and "Gain" to
gain, all as pass-through values. They cross in that order, and
the order matters – Simulink range-checks gain against
low and high the moment it is set, so a gain written
before its range is a hard error that aborts the generated script rather than a
warning.
The rate does NOT cross: Simulink's Slider Gain is a masked subsystem
whose only parameters are gain, low and
high – it defines no SampleTime at all – so
the entry sets hasSampleTimeParam = false and "Sampling Time (s)"
stays on the ICore side.
Notes
- Algebraic, with no state: the output depends only on the current input.
- Linear, so the block carries a feed-through continuous state space with D = k·I and model reduction absorbs it into a neighbouring plant. Unlike Gain it has no multiplication modes, so that is unconditional: a scalar gain is y = k·u and nothing else.
- For a matrix gain, an element-wise product, or a right multiplication, use Gain.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Base_Blocks/Slider_Gain |
| family | Control_Systems/Base_Blocks |
| solver environment class | ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Slider_Gain |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Base_Blocks/Slider_Gain/ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Slider_Gain.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Base_Blocks/Slider_Gain/ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Slider_Gain.h |
| default size on canvas | 80 × 70 px |
| ports at insert | 1 in, 1 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | — |
| 2 | out | ICoreDouble | — |
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 variable | Default | Simulink parameter |
|---|---|---|
Minimum | 0 | low |
Maximum | 2 | high |
Gain | 1 | gain |
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.
Simulink bridge#
| support | Support::Both |
| Simulink path | simulink/Math Operations/Slider Gain |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Minimum | low | passes through |
Maximum | high | passes through |
Gain | gain | passes through |
Caveat (shown to the user): the rate does not cross: Simulink's Slider Gain is a masked subsystem whose only parameters are gain, low and high, with no SampleTime, so "Sampling Time (s)" stays on the ICore side
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).
Slider Gain block -- a scalar gain with a declared adjustment range y = k*u, entry by entry, with the gain k a SCALAR held inside [Minimum, Maximum]. The range is what distinguishes this block from Gain: it is the span a user is allowed to sweep k over while tuning, and Simulink draws it as the slider the block is named for.
THE RANGE IS ENFORCED, not decorative, and that is a bridge requirement rather than a preference. Simulink's Slider Gain range-checks
gainagainstlow/highthe instant set_param touches it, and a value outside the range is a HARD error ("Value '2.5' is out of range") that aborts the whole generated script. So a gain outside the range here is reported at verification rather than exported into a script that cannot run. It was measured, not assumed: set_param with gain before low/high fails even for a gain the FINAL range admits.Which is also why the catalog entry lists Minimum and Maximum BEFORE Gain. The .m writer emits one set_param carrying the pairs in entry order and Simulink validates each as it is applied, so the range has to arrive first. (Emitting in entry order rather than the block map's alphabetical order is what ICoreSimulinkMCodec does for exactly this case.)
The gain is a TUNABLE parameter on every generated core rather than a constant inlined into the arithmetic. That is the whole point of a slider: it names a value the user expects to retune, which is the same call Gain and Bias make and the opposite of the one Sum makes for its signs. Minimum and Maximum do NOT reach the core -- they bound the editing gesture, not the arithmetic, and there is no gesture on a deployed core.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 |
|---|---|---|
| 0 | -2 | -2 |
| 0.4 | 0.5 | 0.5 |
| 0.8 | -2 | -2 |
| 1.2 | 0.5 | 0.5 |
| 1.6 | -2 | -2 |
| 2 | 0.5 | 0.5 |
| 2.4 | -2 | -2 |
| 2.8 | 0.5 | 0.5 |
| 3.2 | -2 | -2 |
| 3.6 | 0.5 | 0.5 |
| 4 | -2 | -2 |
| 4.4 | 0.5 | 0.5 |
| 4.8 | -2 | -2 |
| 5.2 | 0.5 | 0.5 |
Every 4th of 60 samples, from the table stimulus.
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | 0 … 1 |
ramp | Ramp: slope 1 from t = 0 | 0 … 5.8 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -1 … 0.9996 |
step | Step: 0 -> 1 at t = 1 s | 0 … 1 |
Plotted: table — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample
Category static · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Base_Blocks__Slider_Gain.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).