Display — Control Systems/Sinks
Control_Systems/Sinks/Display · 1 input / 0 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.
Display
Control Systems / Sinks
Shows the value reaching it, sample by sample, in the chosen numeric format. It is a readout and nothing else: y is not produced, and u is not altered, rounded or delayed – Format chooses how the number is written down, never what the number is.
Ports
- Input – u, the value to show. Any size [m,n]; the whole matrix
is written on one line as
[a b; c d]. Exactly one input port, as in Simulink, and the count is not user-editable. - No outputs – Display is a pure sink and passes nothing on.
Where the value appears
On the block itself, centred in its frame, as Simulink does it – one line per matrix row, updated live as the run proceeds – at most once per Refresh Period (s), so a fast run stays readable – and left showing the final sample when it ends. Nothing is written to the run log. The face is cleared when a new run starts, so a Display never shows a number from the run before. To plot a signal instead of reading it, use Scope; to keep it for later analysis, use Signal Recorder or Record.
Make the block bigger if a wide matrix or a long format does not fit – the readout is drawn at the block's centre and is not clipped, so it will spill past a frame too small for it.
Parameters
- Format – how each number is written, matching MATLAB's formats
of the same names:
- short – fixed point, 4 decimals (the default).
- long – fixed point, 15 decimals.
- short_e – scientific, 4 decimals.
- long_e – scientific, 15 decimals.
- bank – fixed point, 2 decimals.
- Decimation – show every Nth sample. 1 shows every sample; a value below 1 is treated as 1. The first sample of a run is always shown.
- Refresh Period (s) – the shortest time, in seconds of real time, between one repaint of the face and the next. The default of 1 keeps a long run readable: Decimation counts solver steps, so it speeds up with the solver, whereas this does not. Set it to 0 to repaint on every sample Decimation lets through, which is the right choice for a slow run watched step by step. The first sample of a run is always shown immediately, and so is the last – the final value never waits for a period to expire. This parameter is about reading the number, never about the number: it changes nothing the model computes and nothing any exported core does.
- 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 six software targets print
<block path> = [a b; c d] per shown sample, in the same
format and gated by the same Decimation count as the face readout – the
format is translated to each language's own conversion, so an exported core and
the app agree digit for digit. They print rather than paint because a generated
core has a console and no block face; the digits are the same, the surface is
not. PLC Structured Text has no console, so the
function block instead keeps one LREAL per element holding the
latest shown value, which is what a display IS on a PLC: a variable an HMI or
trace binds to. The three HDL targets report each element into the
simulation transcript at the fixed-point word's own precision, so Format does
not cross to them – there is no formatted print in a Q16.16 datapath.
Decimation is baked into the body at export time in every target; it is
structural, not a tunable parameter.
Simulink bridge
Import and export, mapped to simulink/Sinks/Display. "Format" to
Format and "Decimation" to Decimation, both
pass-through; "Sampling Time (s)" to SampleTime, as on every block.
Refresh Period (s) does not cross in either direction and is not reported
as lost: it is a preference about how this app repaints a block face, Simulink
has no counterpart, and mapping it onto Decimation would change what the model
computes to serve a preference about reading it.
Floating is always written as off: a wired Display is the
only kind this block is, and the floating one is a separate library block
(Floating Scope is ICore's counterpart to that idea). Simulink's Format
also offers four Stored Integer options – hex, binary, decimal and
octal – which have no meaning for a double-precision signal and are
therefore not offered here; an imported Display set to one of them reports that
the value did not translate and keeps short.
Notes
- Algebraic and stateless as far as the signal is concerned. The Decimation counter is the block's only state, and it counts SOLVER STEPS at the block's own rate, not seconds. Refresh Period (s) is the one thing here measured in seconds, and they are seconds of REAL time, not of simulated time – a run compressing an hour of model time into two seconds still repaints once a second.
- Decimation gates the printing only, and the refresh period gates only the repainting. Code-export verification records this block's input, so a decimated or slowly-refreshed Display is verified exactly like a plain one.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Sinks/Display |
| family | Control_Systems/Sinks |
| solver environment class | ICoreBlock_0_Control_Systems_1_Sinks_2_Display |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Sinks/Display/ICoreBlock_0_Control_Systems_1_Sinks_2_Display.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Sinks/Display/ICoreBlock_0_Control_Systems_1_Sinks_2_Display.h |
| default size on canvas | 90 × 50 px |
| ports at insert | 1 in, 0 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 | — |
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 |
|---|---|---|
Format | short%~%long%~%short_e%~%long_e%~%bank~~short | — |
Decimation | 1 | — |
Refresh Period (s) | 1 | — |
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/Sinks/Display |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
| deliberately not crossed | CONFIG_REFRESH_PERIOD.c_str() |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
CONFIG_FORMAT.c_str() | Format | FORMAT_SHORT.c_str() → short, FORMAT_LONG.c_str() → long, FORMAT_SHORT_E.c_str() → short_e, FORMAT_LONG_E.c_str() → long_e, FORMAT_BANK.c_str() → bank |
CONFIG_DECIMATION.c_str() | Decimation | passes through |
Catalog contract: src/ICoreSDK/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The checker has a blind spot here — it could not resolve something (a grouped port bullet, a computed config name), which is reported and never counted as a pass. A reader has to settle it:
B0Ports lists 2 entries for 1 port (1 in, 0 out) — grouped, or one undocumented? a reader must sayB02 Simulink params rule(s) this tool cannot resolve
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.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-In-0 |
|---|---|---|
| 0 | 0 | 0 |
| 0.4 | 0 | 0 |
| 0.8 | 0 | 0 |
| 1.2 | 1 | 1 |
| 1.6 | 1 | 1 |
| 2 | 1 | 1 |
| 2.4 | 1 | 1 |
| 2.8 | 1 | 1 |
| 3.2 | 1 | 1 |
| 3.6 | 1 | 1 |
| 4 | 1 | 1 |
| 4.4 | 1 | 1 |
| 4.8 | 1 | 1 |
| 5.2 | 1 | 1 |
Every 4th of 60 samples, from the step 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 |
table | Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample | -2 … 3 |
Plotted: step — Step: 0 -> 1 at t = 1 s
Category sink · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Sinks__Display.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).