🚧 Change module numbering
This commit is contained in:
@@ -303,14 +303,23 @@ sequence: # time-ordered script (or fully state-driven)
|
||||
- FR-4.3.11: **Module-based channel addressing** — aliases may be addressed
|
||||
as *module type + module number + channel number*, all components
|
||||
explicitly configurable: `{ type: di, module: 2, channel: 1 }` selects
|
||||
digital input channel 1 (0-based) on module slot 2 (0-based position in
|
||||
the node's module list), i.e. `DI2.1`. Both numbers are 0-based to match
|
||||
physical slot/channel labeling. The channel kind must match the module
|
||||
(`DO` on a DI-only module is a validation error). This is an alternative
|
||||
to pool addressing (`{ type: di, channel: 3 }` = 3rd DI channel across
|
||||
the whole node); both schemes are supported and may be mixed, but an
|
||||
alias uses exactly one. **Implemented** in v1.1 (`channel_by_module`,
|
||||
`Alias.module`, `alias_location`).
|
||||
digital input channel 1 (0-based) on DI-module 2 (0-based **number
|
||||
among the modules of the same type**, i.e. the third DI module in the
|
||||
node), i.e. `DI2.1`. Channel numbers are 0-based. The channel kind must
|
||||
match the module (`DO` on a DI-only module is a validation error).
|
||||
This is an alternative to addressing by physical slot; both pool
|
||||
addressing (`{ type: di, channel: 3 }` = 3rd DI channel across the
|
||||
whole node) and module addressing are supported and may be mixed,
|
||||
but an alias uses exactly one. **Implemented** in v1.1
|
||||
(`channel_by_module`, `Alias.module`, `alias_location`).
|
||||
**Changed in v1.5 (2026-10-04, breaking)**: module numbers previously
|
||||
counted physical slots (all modules in one sequence); they now number
|
||||
**within the module's type** — `DI0`/`DO0`/`AI0`/`AO0` start each kind's
|
||||
sequence (e.g. a node `[DI_8, DI_16, DO_8, DO_16, AI_2, AO_2]` numbers
|
||||
its DI modules `DI0`, `DI1` regardless of the DI/DO interleaving).
|
||||
This matches how channels are named on real WAGO benches and makes
|
||||
rearranging modules less disruptive to existing configs. Scenarios,
|
||||
channel names, and analog ranges use the per-type codes.
|
||||
|
||||
### 4.4 Example FAT flow
|
||||
|
||||
@@ -1126,6 +1135,14 @@ This feature request closes that gap.
|
||||
- FR-11.2.5: A reconfiguration event is logged (sim-time, change
|
||||
description, new image sizes) and visible in the web UI's I/O Config
|
||||
page, mirroring the WBM SAVE CONFIG flow.
|
||||
- FR-11.2.6: **Module reordering** (requested 2026-10-04): the web UI's
|
||||
I/O configuration pane supports rearranging modules — move up/down
|
||||
controls per module slot. Reordering triggers the same process-image
|
||||
rebuild as any module change (FR-11.2.1–11.2.3) and persists the new
|
||||
order. Because I/O codes number modules per type (FR-4.3.11 v1.5),
|
||||
moving a module past a module of a different kind does not renumber
|
||||
the other kind's channels — only the relative order within the same
|
||||
type affects addressing.
|
||||
|
||||
### 11.3 Requirements — address-selection DIP switch emulation
|
||||
|
||||
|
||||
Reference in New Issue
Block a user