Trigger Based Linearization — Control Systems/Model Wide Utilities
Control_Systems/Model_Wide_Utilities/Trigger_Based_Linearization · 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.
Trigger-Based Linearization
Control Systems / Model Wide Utilities
Takes a linear model of the whole diagram each time its trigger input
has an edge: the state-space matrices a, b, c and d
of the diagram linearized between its input and output gates (as MATLAB's
linmod takes them between a model's root Inports and Outports), at the
operating point of the step the edge comes in. When the run ends, each snapshot
is left in the variables space as one record.
Ports
- Input trigger – the signal whose edges take the snapshots, one value, any numeric type.
- No outputs.
Parameters
- Trigger Type – rising (the default), falling or either, by Simulink's rule for a trigger: rising is negative to zero, negative to positive, or zero to positive, and a crossing split over two steps through zero counts once; falling is the mirror. Simulink's function-call is not offered: a function call here drives a subsystem, not a block, and it is refused by name.
- Linearization Sample Time – the
Tswritten into the result. 0, the default, is the continuous linearization (linmod). A positive value asks for MATLAB's discrete linearization (dlinmod), which ICore does not compute; it is refused. - Sampling Time (s) – zero or less looks for an edge on every step of the model; a positive value looks at that period. It does not cross to Simulink, whose block takes its rate from its trigger.
What the run leaves
One record per snapshot, in time order, named from the block's path with every
character that is not a letter, a digit or _ made _, as
Simulink names its variable: a block T L on the top level gives
Home_T_L, then Home_T_L_2, and so on. Each holds
a, b, c, d,
OperPoint_x (the states, a column), OperPoint_u (the
inputs, a row), OperPoint_t and Ts; Simulink's
StateName, OutputName and InputName are
cells of block paths, which a record here does not hold, and reading one says so by
name.
When nothing is left
A snapshot needs the Continuous solver with Joint coupling. Under any other the run warns once, with the reason, and leaves nothing; so does a run with no edge.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text, as a named body that does nothing: a linearization is an analysis of the live run.
Simulink bridge
Import and export, mapped to simulink/Model-Wide Utilities/Trigger-Based
Linearization: Trigger Type ↔ TriggerType and
Linearization Sample Time ↔ SampleTime. ICore's trigger
input is Simulink's trigger port.
Notes
- To take a snapshot at set times instead, use Model-Wide Utilities / Timed-Based Linearization.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Model_Wide_Utilities/Trigger_Based_Linearization |
| family | Control_Systems/Model_Wide_Utilities |
| solver environment class | ICoreBlock_0_Control_Systems_1_Model_Wide_Utilities_2_Trigger_Based_Linearization |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Model_Wide_Utilities/Trigger_Based_Linearization/ICoreBlock_0_Control_Systems_1_Model_Wide_Utilities_2_Trigger_Based_Linearization.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Model_Wide_Utilities/Trigger_Based_Linearization/ICoreBlock_0_Control_Systems_1_Model_Wide_Utilities_2_Trigger_Based_Linearization.h |
| default size on canvas | 80 × 80 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 | trigger |
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 |
|---|---|---|
Trigger Type | rising%~%falling%~%either%~%function-call~~rising | TriggerType |
Linearization Sample Time | 0 | SampleTime |
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/Model-Wide\nUtilities/Trigger-Based\nLinearization |
| port-count rule | PortsParam:: |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Trigger Type | TriggerType | passes through |
Linearization Sample Time | SampleTime | passes through |
Caveat (shown to the user): "the trigger input is Simulink's trigger port
Catalog contract: src/ICoreBlocks/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:
B0no sample under docs/generated/samples/ — nothing to cross-check (P8.1)
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).
Trigger-Based Linearization -- the whole diagram linearized on each edge of a trigger Measured on R2026a (FEATURES_TO_ADD.md §F.BF17, BF17.1): a masked subsystem over
sfunlin, library pathsimulink/Model-Wide\nUtilities/Trigger-Based\nLinearization, ONE trigger port and no data ports, two parameters:TriggerType(rising, falling, either, function-call) andSampleTime(default 0, the result's Ts). The snapshot is taken in the major step the edge is detected in, with x at that t. It writes the same struct array as the Timed-Based block. The edge is Simulink's three-way sign rule with its unalias rule (ICoreSubsystemActivity::edge, the one a Triggered Subsystem's port uses); the snapshot is ICoreRunLinearization's requestAtStepEnd; the rest is ICoreLinearizationBlockBase.
Sample results#
No sample run is committed for this block. Samples come from the headless harness (DOCS_PLAN.md P8.1) into docs/generated/samples/; until one exists this block's behaviour is witnessed by the parity and export-verification suites, not by a plot here.