Hit Scheduler — Control Systems/Messages And Events
Control_Systems/Messages_And_Events/Hit_Scheduler · 2 input / 1 output port(s) at insert · no code generators declared
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.
Hit Scheduler
Control Systems / Messages And Events
Schedules a step the solver must take: on every step its enable is true, it asks for a hit at now + dt, and the variable-step solver lands exactly on that time. Its output is true on a scheduled step and false on every other one – or, as a function call, calls what it is wired to once per scheduled step. It also fires once at the start of the run, whatever the enable says.
Ports
- Input enable – scheduling is on while it is true (nonzero). It is a level, not an edge: an enable held true across several steps schedules one hit per step it is read on. Wired straight from a discrete block (a Unit Delay, a Counter, a Repeating Sequence Stair), it is read only on that block's sample hits; otherwise it is read on every step.
- Input dt – the delay to the hit, in seconds, one value. It must be positive and finite while the enable is true; it is not read while the enable is false.
- Output – with Signal, a bool, true on a scheduled step and at the start; with Function-Call, a function call once per scheduled step, which drives a Function-Call Subsystem.
Parameters
- Output Type – Signal (the default) or Function-Call.
- Initial Buffer Size – how many pending hits the block holds at first. Default 256.
- Fixed Buffer – Off (the default): the buffer grows as hits are scheduled, and every one fires. On: it holds at most Initial Buffer Size hits, and a new one past that removes the oldest pending one, with a warning.
- Sampling Time (s) – not used: the block runs on every step of the model. It does not cross to Simulink, whose block has no rate parameter.
Rules
- A hit that lands while the enable is still true schedules the next one.
- Pending hits are kept in order; a later request never replaces an earlier one, and two requests for one time give one hit.
- The model must run under a variable-step solver (RK45, RK23 or TRBDF2): under a fixed step the run is refused, as Simulink refuses it, since a fixed step cannot land on a computed time.
When a run is refused
A fixed-step solver (does not support simulation with fixed-step solver), and, while the enable is true, a dt that is zero, negative or not finite (Invalid time delay value … must be positive and finite).
Code export
Not offered in any of the ten targets (Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text): an exported core runs a fixed step, which cannot land on a computed time, and Simulink's own block generates no code either. An export of a model holding one stops and names it.
Simulink bridge
Import and export, mapped to simulink/Messages & Events/Hit
Scheduler: Output Type ↔ HitSchedulerOutputType,
Initial Buffer Size ↔ InitialBufferSize and Fixed
Buffer ↔ FixedBuffer.
Notes
- Read on every step, an enable held true schedules as many hits as the solver takes steps while it is true, so that number depends on the solver. An enable wired straight from a discrete block is read at that block's rate, as Simulink's block inherits it, and gives the same hits under any variable-step solver: a Repeating Sequence Stair at 0.1 s, true at 0, 0.1 and 0.2, with dt 0.35, gives hits at 0, 0.35, 0.45 and 0.55, as R2026a does. A block with a Sampling Time that is not discrete-only, such as a Step, is stepped on every variable step and does not count.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Messages_And_Events/Hit_Scheduler |
| family | Control_Systems/Messages_And_Events |
| solver environment class | ICoreBlock_0_Control_Systems_1_Messages_And_Events_2_Hit_Scheduler |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Messages_And_Events/Hit_Scheduler/ICoreBlock_0_Control_Systems_1_Messages_And_Events_2_Hit_Scheduler.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Messages_And_Events/Hit_Scheduler/ICoreBlock_0_Control_Systems_1_Messages_And_Events_2_Hit_Scheduler.h |
| default size on canvas | 80 × 80 px |
| ports at insert | 2 in, 1 out |
| code generators implemented | none |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreBool | enable |
| 2 | in | ICoreDouble | dt |
| 3 | out | ICoreBool | — |
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 |
|---|---|---|
Output Type | Signal%~%Function-Call~~Signal | HitSchedulerOutputType |
Initial Buffer Size | 256 | InitialBufferSize |
Fixed Buffer | Off%~%On~~Off | FixedBuffer |
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/Messages\n& Events/Hit Scheduler |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Output Type | HitSchedulerOutputType | Signal → Signal, Function-Call → Function-Call |
Initial Buffer Size | InitialBufferSize | passes through |
Fixed Buffer | FixedBuffer | Off → off, On → on |
Caveat (shown to the user): Simulink's Hit Scheduler has no SampleTime and generates no code (codegen=No, measured); it needs a variable-step solver on both sides
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).
Hit Scheduler -- a step the solver must land on, scheduled from the block's own input Measured on R2026a (FEATURES_TO_ADD.md §F.BF21, BF21.1):
BlockType=HitScheduler, library pathsimulink/Messages\n& Events/Hit Scheduler, 2 in (1 the ENABLE, boolean; 2 the delay dt, double, seconds), 1 out;HitSchedulerOutputTypeSignal (default) or Function-Call,InitialBufferSize256,FixedBufferoff; no SampleTime. On EVERY major step its enable is true it schedules a hit at now + dt (level-sensitive, not an edge); the solver lands exactly on each hit with no approach step; a hit landing while the enable is still true schedules the next; pending hits are held in a buffer and a later request never replaces an earlier one; two requests for one time give one hit; dt <= 0 while enabled is HitSchedulerInvalidInput ("Invalid time delay value ... must be positive and finite"); a fixed buffer full drops its OLDEST ("Removing oldest value"); it fires at t = 0 whatever the enable; a fixed-step solver is HitSchedulerRequireVariableStep. Measured again for this row (2026-10-02): a discrete Step (Ts 0.1) true until 0.25 and dt 0.35 under ode45, MaxStep 0.1, to t = 1, gives true at [0 0.35 0.45 0.55], and as Function-Call the same four calls; so does a Repeating Sequence Stair [1 1 1 0 ...] at Ts 0.1. Simulink's block INHERITS its enable's rate, so it reads the enable (and schedules) on that rate's hits only. ICore does the same when the enable comes straight from a discrete-only block, the only kind that keeps its rate under a variable step.The landing is BF21.2's seam: setAnnouncesScheduledHits(true) and nextDiscontinuityTimeAfter, which the solver asks after the step's solve, so this block's input at
nowis already known.
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.