State Charts
Event-driven logic with finite state machines: states, transitions, guards, actions, hierarchical superstates, and how charts execute inside the fixed-step solver.
Data flow is the right tool for continuous computation — but modes, sequences, and fault logic are naturally event-driven. For those, Modeloop provides state charts: finite state machines embedded directly in your diagram, with full support in validation, simulation, and code generation.
A State Chart is a composite block. From the outside it looks like any other block — typed inputs, typed outputs, executed on its diagram’s schedule. Inside, instead of a data-flow diagram, it contains states and transitions.
Building a chart
States
A state represents one mode of the machine. Exactly one state (per level) is active at any time. Each state can declare three actions — small statements that read the chart’s inputs and write its outputs or local variables:
| Action | When it runs |
|---|---|
entry/ | Once, when the state becomes active through a transition |
during/ | On every chart execution in which the state is already active at the start of the execution |
exit/ | Once, when the state is left through a transition |
Note the sampled semantics of during/: entering a state does not run its during/ action in the same execution — the first during/ runs on the next wake-up. This keeps single-execution behavior unambiguous.
One state per chart is marked as the initial state, active on the first execution.
Transitions
A transition connects a source state to a target state and carries up to four pieces of logic:
trigger [condition] / action (priority)- Trigger — an event name; omitted for automatic transitions evaluated every execution.
- Condition — a boolean guard over inputs and local variables (
speed > 10.0,mode == DriveMode.SPORT). Omitted means unconditional. - Action — a statement executed when the transition is taken.
- Priority — an integer (lower = higher priority) that makes the evaluation order between competing transitions explicit and reviewable.
On each execution, the active state’s outgoing transitions are evaluated in priority order; the first one whose trigger and condition hold is taken. At most one transition fires per level per execution.
Junctions
A junction is a stateless decision point (rendered as a diamond). Transitions through junctions compose into decision trees — one source state branching to different targets based on conditions — without introducing intermediate states.
The interface is inferred
You do not declare the chart’s inputs and outputs by hand. Modeloop parses your guards and actions and derives the inputs, outputs, and local variables automatically. If an expression references speed, the chart gets a speed input port. Enum types propagate too: a guard on mode == DriveMode.SPORT types the mode input as DriveMode.
Hierarchical state machines
States can nest. Marking a state as a superstate gives it an inner diagram with its own states, junctions, and history — UML-style hierarchical machines. Nesting is unlimited, but the validator warns beyond five levels: deeper charts are hard to review.
Entering and leaving a superstate
- Entry — entering a superstate activates its inner initial state (or the remembered state, with history — see below), running entry actions from the outside in.
- Exit — leaving a superstate runs exit actions from the innermost active state outward.
- Cross-level transitions — a transition may connect states at different nesting levels. Modeloop resolves the sequence for you: the source side exits level by level up to the point where the two branches meet, the transition action runs, and the target side enters level by level down to the target state.
History
A history node inside a superstate remembers the last active sub-state. When the superstate is re-entered through the history node, the machine resumes where it left off instead of restarting at the initial state. History is shallow: it records one level; deeper levels re-enter through their own initial states.
Validation
Charts are validated structurally when you save. Modeloop checks, among others, that:
- each chart level has exactly one initial state;
- state names are unique;
- every state is reachable from the initial state;
- cross-level transitions reference states that exist.
Errors block the save and point at the offending state or transition; warnings (such as excessive nesting depth) do not block.
Execution semantics
A state chart executes when the diagram around it executes — it is sampled at that rate, in line with the fixed-step solver. Each execution:
- Runs the active state’s
during/action (if it was active at the start of the execution). - Evaluates the active state’s outgoing transitions in priority order.
- If one fires: runs
exit/actions (inside-out), the transition action, andentry/actions (outside-in), then updates the active state.
Deterministic by construction: fixed evaluation order, at most one transition per level per execution, no hidden micro-steps between ticks.
In generated code, a chart becomes plain, reviewable logic with named state constants — the same machine you drew, verifiable line by line against the chart. See Code Generation.
When to use a chart vs. data flow
| Situation | Use |
|---|---|
| Continuous computation (filters, control laws, math) | Data-flow blocks |
| Discrete modes with different behavior per mode | State chart |
| Sequencing (init → run → shutdown) | State chart |
| Fault detection logic (debounce, latch, recovery) | State chart |
| Simple binary selection between two signals | If-Then-Else block — no chart needed |
A common and healthy pattern: a state chart computes the current mode, and downstream data-flow blocks consume that mode signal to select gains or paths.