Probe — Control Systems/Signal Attributes

Probe

Control Systems / Signal Attributes

Reports three properties of the signal that reaches it, one per output port: w = m×n, the element count of an [m,n] input; Ts = [period 0], the rate the block runs at; and c = 0, its complexity. None of the three depends on the samples – sizes and rates are resolved when the model is built, so all three are constant for a whole run.

Ports

• Input u – the signal being asked about, of any size [m,n]. Its VALUES are never read; only its size, and the rate this block runs at.
• Output w – the element count m×n, always 1×1. A [2,3] input answers 6, a three-element vector answers 3, a scalar answers 1. It is a count and not a dimension.
• Output Ts – the rate, always 1×2, carrying [period offset]. The offset is always 0: ICore has no sample-time offset to report.
• Output c – the complexity, always 1×1 and always 0. Every ICore signal is a real matrix, so there is no complex case for this port to report.

Parameters

• None beyond the rate below. What this block reports is a property of the model, not something to set.
• Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period. On this block alone the value is also an output: it is what the Ts port carries.

Code export

All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. All three answers are inlined as literals rather than exposed as tunable parameters, and that is not an optimization: on a generated core the signal sizes and the rate are already fixed, so there is nothing left to measure at run time. The three HDL targets are fully synthesizable – the body is three constant assignments with no arithmetic to quantize.

Simulink bridge

Import and export, mapped to simulink/Signal Attributes/Probe. Three of that block's four outputs are always implied and written on export – ProbeWidth, ProbeSampleTime and ProbeComplexSignal all on – so the exported block shows the same three ports in the same order.

The DIMENSIONS output is pinned off and REPORTED. ProbeSignalDimensions is always written off, and a Simulink model that had it on is reported on import rather than mapped. Simulink emits the dimensions vector there, which is [width] for a one-dimensional signal and [rows columns] for a two-dimensional one – measured in R2026a, where a three-element signal answered a scalar 3. Every ICore signal is an [m,n] matrix with no one-dimensional case, so there is no value this port could carry that is right in both tools.

The rate does NOT cross. That block defines no SampleTime parameter – verified by set_param against R2026a, which answers "Probe block does not have a parameter named 'SampleTime'" – so "Sampling Time (s)" stays on the ICore side. Simulink's four output-data-type settings (ProbeWidthDataType and its three siblings) have no counterpart here, every ICore signal being a matrix of doubles, and are left at their defaults.

Notes

• Algebraic, with no state, and constant for a whole run: both numbers it reports are resolved by the model build before the first step.
• The rate reported is this block's own. Simulink's Probe reports the rate of the SIGNAL that arrives – measured: driven from a 0.02 s source inside a model stepping at 0.01 s it answered [0.02 0]. ICore carries no rate on a wire; a block has one. Left inheriting, the two are the same number; given an explicit period, this block reports that period.
• Under a variable-step solver a block's period is the initial step rather than a rate it keeps, so the Ts port reports that initial step. Use a fixed-step solver when the value is meant to be read.
• Deliberately carries no state space, for the reason Width gives: the outputs do not depend on the input at all, so there is no A/B/C/D that represents the relation – it would need a constant term and a state space has nowhere to hold one. Model reduction reports the block as unmergeable rather than absorbing it.