Slider — Control Systems/Dashboard
Control_Systems/Dashboard/Slider · 0 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
Control Systems / Dashboard
An operator control that puts its current setting on a wire:
y = v, the position of the slider, held inside [Minimum, Maximum]
Ports
- Output – the control's value y, always a scalar [1,1] signal. The block has no inputs: it is a source, and nothing it reads comes from the diagram.
Parameters
- Minimum – the low end of the range the slider sweeps. Scalar;
defaults to
0, as in Simulink. - Maximum – the high end. Scalar; defaults to
100, as in Simulink. Must be greater than Minimum. - Value – where the slider is set, and therefore the number on the output. Scalar, and it must lie between Minimum and Maximum: a value outside the range is reported and the run is stopped rather than quietly pinned to the nearest end, because a slider cannot be moved outside its own range and a value that is outside one is a typo. Widen the range or move the value.
- 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 setting is resolved to one number when the configuration is loaded and exposed as a tunable parameter on the generated core, so a deployed core can be re-pointed at a different setting without regenerating it – which is the whole point of a control. Like Constant and unlike the time-driven sources, this block reads no clock on any target, so the three HDL targets are genuinely synthesizable: the value is a Q16.16 literal driven onto the signal.
Simulink bridge
No equivalent, and this is not an omission. Simulink's SliderBlock is a DASHBOARD block and has ZERO ports of any kind - measured on R2026a, where a model holding one and nothing else refuses to run with "contains no blocks or all blocks are virtual". It does not put its value on a wire: it reaches its target through Binding, a reference to another block's PARAMETER, and ICore has no cross-block parameter reference for that to become (the same absence that blocks Signal Routing/Parameter Writer and the State Reader/Writer pair). This block is the ICore reading of that control - the value goes on a wire instead - so it is a DIFFERENT block from the Simulink one rather than a mapping of it, and it is reported on exchange rather than asserted. There is also nothing to compare against: the Simulink block is virtual, so no simulation of it produces a sample. Wire this block into whatever the Simulink dashboard control would have been bound to.
Notes
- Algebraic and stateless, and time-independent: the output is the same at every instant of a run, because the setting is read once when the configuration loads.
- The range bounds the CONTROL, not the arithmetic. Minimum and Maximum do not reach the generated core – there is no slider to bound on a deployed core – which is the call Slider Gain makes for the same pair of parameters.
- The arithmetic is Knob's exactly – a range and a setting inside it – and the only difference is the control a user is offered. Neither is a better spelling of the other; pick the one that reads right on the diagram.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Dashboard/Slider |
| family | Control_Systems/Dashboard |
| solver environment class | ICoreBlock_0_Control_Systems_1_Dashboard_2_Slider |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Dashboard/Slider/ICoreBlock_0_Control_Systems_1_Dashboard_2_Slider.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Dashboard/Slider/ICoreBlock_0_Control_Systems_1_Dashboard_2_Slider.h |
| default size on canvas | 70 × 70 px |
| ports at insert | 0 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 | 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 | — |
Maximum | 100 | — |
Value | 0 | — |
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::None |
| Simulink path | — |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
Caveat (shown to the user): Simulink's SliderBlock is a DASHBOARD block and has ZERO ports of any kind - measured on R2026a, where a model holding one and nothing else refuses to run with "contains no blocks or all blocks are virtual". It does not put its value on a wire: it reaches its target through Binding, a reference to another block's PARAMETER, and ICore has no cross-block parameter reference for that to become (the same absence that blocks Signal Routing/Parameter Writer and the State Reader/Writer pair). This block is the ICore reading of that control - the value goes on a wire instead - so it is a DIFFERENT block from the Simulink one rather than a mapping of it, and it is reported on exchange rather than asserted. There is also nothing to compare against: the Simulink block is virtual, so no simulation of it produces a sample. Wire this block into whatever the Simulink dashboard control would have been bound to
Catalog contract: src/ICoreBlocks/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 block -- an operator control that puts its setting on a wire y = v, the position of the control, a single number held inside [Minimum, Maximum].
It is a SOURCE: no inputs, one 1x1 output. The setting is resolved to a single number when the configuration loads, so the block reads no clock, holds no state and answers the same number at every instant of a run -- which is what lets all ten targets share one body that copies a tunable parameter onto the output signal, exactly as Constant's does.
⚠ THERE IS NO SIMULINK COUNTERPART, AND THAT IS A MEASUREMENT RATHER THAN A GAP. Simulink's SliderBlock has ZERO ports of any kind and is VIRTUAL -- a model holding one and nothing else refuses to run with "contains no blocks or all blocks are virtual" (R2026a, measured). It reaches its target through Binding, a reference to another block's PARAMETER, which this tree has no counterpart for. So this block is the reading of that control which this tree's signal model can express -- the value goes on a wire -- and the bridge reports it rather than asserting a mapping that would be wrong. There is also nothing to compare against: a virtual block produces no sample, so no parity testbench is owed or possible.
Sample results#
Plotted: free — No input: the block run alone
Category source · sample time 0.1 · 60 steps · commit 38bce32b1d1471614469d78cd797992dfd022eac · produced by docsSample --out <folder> --blocks Knob Slider Check_Box Toggle_Switch Rocker_Switch Slider_Switch Push_Button Rotary_Switch Combo_Box Radio_Button Edit --steps 60 · data docs/generated/samples/Control_Systems__Dashboard__Slider.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).