User manual › Reading results — scopes, charts, stored values, and what a run tells you
kind: manual#manual#results#scope#chart#variables#diagnostics

Reading results#

A run produces signals. This page covers the blocks that show them, the chart window, the values the command window keeps, and what a run's messages mean.

The blocks that show a signal#

Sinks are the blocks that consume a signal rather than producing one. The ones you will reach for most:

BlockWhat it gives you
ScopeA plot against time, filling in as the run advances. The usual way to watch a signal.
Floating ScopeA scope with no input link — it is pointed at a signal instead, which is useful for a quick look without redrawing anything.
DisplayThe current value as a number, rather than a curve.
XY GraphOne signal against another instead of against time.
Signal RecorderSaves what it receives as a time series in the variables space, so the run's numbers can be worked with in the command window afterwards.
To File / RecordWrites the signal out for use elsewhere.
Stop SimulationEnds the run when its input says so, rather than at the stop time.
TerminatorDeliberately discards a signal, for an output you do not want.

Each of these has its own page under Block catalog — every library block, with a sample of it running.

The chart window#

A scope's plot can be opened as a chart of its own, and the chart can be exported — as an image, as a PDF, as SVG, or as the plotted numbers in CSV form when what you want is the data rather than the picture.

You can also plot without involving the diagram at all. plot() in the command window opens a chart over a matrix, a pair of x/y vectors, or a recorded signal.

Values the command window keeps#

The command window has a variables space: results you name are kept there for the rest of the session, so a value can be computed once and reused.

A recorded signal is a time series — time stamps against one column per channel. It deliberately prints as a summary rather than as its samples, because a run of any length would otherwise fill the window:

$ ICoreBlocks --console "G = tf([1],[1 1]); y = step(G, 5, 6); y"
y = Time Series (6 samples, t = 0 .. 5)  # Time Series

To get at the numbers, ask for the two halves — .time() and .values():

$ ICoreBlocks --console "G = tf([1],[1 1]); y = step(G, 5, 6); y.time()"
[[0], [1], [2], [3], [4], [5]]  # Matrix of Double

$ ICoreBlocks --console "G = tf([1],[1 1]); y = step(G, 5, 6); y.values()"
[[0], [0.632121], [0.864665], [0.950213], [0.981684], [0.993262]]  # Matrix of Double

Those values are 1 − e⁻ᵗ at each second, which is the step response of 1/(s+1) — a result you can check by hand, and a good way to confirm the application is doing what you think before trusting it on a model you cannot check.

Asking for something a value does not have tells you what it does have:

$ ICoreBlocks --console "G = tf([1],[1 1]); y = step(G, 5, 6); y.toMatrix()"
error: a time series has no member 'toMatrix' (try .time() or .values())

clearVariablesSpace empties the variables space when you want to start clean.

What a run's messages mean#

The diagnostics panel collects what a run reports. Two messages are worth recognising:

  • "Unable to retrieve config …" — a block asked for one of its own parameters and did not get it. In practice this means a parameter the block needs was never set, and the run stops rather than continuing on a value nobody chose. Open that block's configuration dialog and check the parameter named in the message.
  • A run that ends immediately — most often a Stop Simulation block whose input was already nonzero at the first step, or a stop time that is not later than the start time. Note that any nonzero entry fires that block, so a vector signal only one of whose elements is nonzero will still stop the run. Both causes are visible in the model configuration panel and on the diagram.

If a result looks wrong rather than absent, the first thing to check is sample rate rather than the block itself — Running a simulation — solver settings, sampling, starting and stopping covers why a signal sampled more slowly than it changes produces a response that looks stepped or delayed.

Real runs#

Every transcript on this page is a real run rather than an illustration. Binary cmake-build-debug/ICoreBlocks.app, built 2026-08-17 01:28 (source at approximately commit c2a229c6); one process per line, HOME=<scratch> QT_QPA_PLATFORM=offscreen ICoreBlocks --console "<line>", with the toolkit's startup noise removed and paths under that scratch home shortened to . Re-run any line above to check this page against the program.