E-Planung -> Layout: e_planning.py, scl_skeleton --eplan, Kapitel Daten

- doc/Klassenhierarchie.md: Kapitel "Daten" - alle Daten der SCL-Referenzen nach Quelle (Layout, E-Planung, Namenskonvention, Parameter) - doc/E-Planung_Bruecke.md: Bruecke ueber *_positionsdraw.json des Kabellaengen-Tools, Befunde an Mubea - lib/e_planning.py + cfg/e_planning.ini + bin/e_planning.bat/.sh: Lagebezug E-Zeichnung -> CSV, Zuordnung BMK -> Layout-Bauteil nach Regeln (Abstand, Sollabstand, Nummernregel MB = BG + 1), <csv>_eplan.json + Bericht - scl_skeleton --eplan: Separator-Sensor und Stopperventil eingesetzt, ohne Schalter unveraenderte Ausgabe (Golden-Files gleich) - tests/test_e_planning.py Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-11 09:30:56 +02:00
parent 5764df1ac8
commit c736288476
11 changed files with 1683 additions and 26 deletions
@@ -1,14 +1,16 @@
 # Python Scripts — CLI Tooling Overview

-**As of:** 2026-10-09
+**As of:** 2026-10-10

-`lib/` currently holds ten Python modules (five of them runnable CLI tools,
+`lib/` currently holds eleven Python modules (six of them runnable CLI tools,
 five supporting libraries), plus one documentation-generator script that lives
 under `doc/TRO_Katalog/tro_graphs/`. Together the CLI tools turn a CSV export
 of the mechanical layout (ILS 2.0) into a material-flow graph, a derived TRO
 list/diagram, a TRO-JSON (shared model `lib/model.py`), an `FB_Main` SCL
 skeleton generated from that JSON, and an annotated copy of the BricsCAD
-drawing for visual checking.
+drawing for visual checking. `e_planning.py` bridges to the electrical
+planning: it assigns the sensors/valves of the E-planning drawing to the
+layout parts, so the skeleton can carry their real names.

 This document is the practical "what does each script do and which switches
 does it take" reference. For the underlying domain model (TRO types, JSON
@@ -34,6 +36,11 @@ tro_flow.py       ──►  <name>_tro_flow.dot / .svg, _tro_doc.md, _tro_error
   │               scl_skeleton.py ──►  <name>_FB_Main.scl
   │                  (validates the JSON against model.py; one REGION per TRO;
   │                   E-planning values left as TODO(E-Planung) gaps)
+   │                  ▲
+   │                  │ --eplan <name>_eplan.json  (optional)
+   │               e_planning.py ◄── <drawing>_positionsdraw.json (kabellaengen)
+   │                  (assigns BG/MB of the E-planning drawing to the layout
+   │                   parts by position + numbering rule; see §5c)
   │
   └── same derivation ──► tro_annotate.py ──► <name>_annotated.dxf  (VIEWER ONLY)
          (also needs the BricsCAD DXF; uses dxf_registration.py for the CSV↔DXF
@@ -91,6 +98,8 @@ Each CLI tool is invoked through its `bin/<name>.bat` (Windows) / `bin/<name>.sh
 bin\material_flow.bat --file mubea.csv --tosvg --use-cords --doc
 bin\tro_flow.bat --file mubea.csv --tosvg --use-cords --doc --json
 bin\scl_skeleton.bat --json mubea_tro.json
+bin\e_planning.bat --file mubea.csv --eplan Mubea_positionsdraw.json
+bin\scl_skeleton.bat --json mubea_tro.json --eplan mubea_eplan.json
 bin\tro_annotate.bat --file mubea.csv --dxf 500573_60_1.dxf --flow --fb --legend
 ```

@@ -102,8 +111,9 @@ Conventions shared by the CLI tools:
 - `--file` / `--dxf` accept either a bare filename — resolved against
  `%SKEL_DATA%` — or a full path.
 - All generated output is written to `%SKEL_RESULTS%`.
- `tro_annotate.py` additionally persists the verified CSV↔DXF coordinate
-  offset to `%SKEL_CFG%\dxf_registration.json`.
+- `tro_annotate.py` and `e_planning.py` additionally persist the verified
+  coordinate offset (CSV↔DXF, CSV↔E-planning drawing) to
+  `%SKEL_CFG%\dxf_registration.json`.
 - Every run prints a `====` bordered report to stdout (counts, warnings,
  output file paths); non-fatal findings are printed as `?`/`!` lines and also
  do not stop the run.
@@ -460,7 +470,7 @@ than a guess.

 Switches: `--json NAME` (default `export_tro.json`, looked up in
 `%SKEL_RESULTS%`; written by `tro_flow.py --json`), `--out NAME` (default
-`<source>_FB_Main.scl`), `--start TRO`. The last one matters while the plant has
+`<source>_FB_Main.scl`), `--eplan NAME` (see below), `--start TRO`. The last one matters while the plant has
 no loading/unloading station: the flow is then a closed loop with no entry, so
 the order has to be broken somewhere arbitrary. The chosen start and the reason
 are recorded in the file header.
@@ -492,6 +502,16 @@ times 100/50 ms), and every value that is still open carries
 `TODO(E-Planung)`. `--strict` stops (exit `1`, no SCL) if any FB type has no
 template. Without `--templates` the output is unchanged.

+**Names from the E-planning (opt-in, `--eplan NAME`).** Reads the assignment
+`<csv>_eplan.json` written by `e_planning.py` (§5c; bare name looked up in
+`%SKEL_RESULTS%`). For every separator it assigns, the separator sensor
+(`stSenInSep := "DB_Inputs".Sensors["cInBG0642"]`) and the stopper valve
+(`xOutStopper<n> => "MB0643"`) are filled in and lose their `TODO(E-Planung)`
+marker (`SclName.todo = False`); everything else stays open. The header names
+the E-planning file. An assignment made for a different CSV (`csv_file` ≠ the
+TRO-JSON's `source`) stops the run with exit `1` — separator numbers are only
+unique within one export. Without `--eplan` the output is unchanged.
+
 Tests: `tests/test_scl_context.py` (the derivations one by one),
 `tests/test_scl_templates.py` (each template rendered with the real values of
 its reference call site must equal that call site, comments and whitespace
@@ -500,6 +520,86 @@ HundM05 byte for byte against `tests/fixtures/scl/*_FB_Main.scl` and
 `*_FB_Main_templates.scl`, timestamp masked; an intended change is written
 back with `SKEL_UPDATE_GOLDEN=1`).

+## 5c. `e_planning.py` — assign the E-planning to the layout parts
+
+The bridge between layout and electrical planning (background and findings:
+[`E-Planung_Bruecke.md`](E-Planung_Bruecke.md)). The layout knows which
+separators, switches and outfeed elements exist and where; the E-planning knows
+what their sensors and valves are called. The I/O list alone has no topology —
+but the E-planning is drawn as a layer over the hardware layout, every sensor or
+actuator symbol sits next to its part, and the cable-length tool
+(`kabellaengen/lib/getpositions.py`) writes those symbols with position and
+attributes to `<drawing>_positionsdraw.json`.
+
+```
+<name>.csv (layout)  +  <drawing>_positionsdraw.json (E-planning)
+   │
+   ▼
+e_planning.py  ──►  <name>_eplan.json  (EplanDocument, schema sps_skel-eplan-v1)
+               ──►  <name>_eplan.md    (report: assignments, gaps, drives)
+   │
+   ▼
+scl_skeleton.py --eplan <name>_eplan.json
+```
+
+Steps:
+
+1. **Read** `sensors` (field devices) and `schaltschrank_elemente` (cabinet) of
+   the positionsdraw file into `EDevice` (BMK, `VERW`, `BEZEICHNUNG`,
+   `KENNZEICHNUNG` → controller `UH01` / I/O station `KF107`, position). A BMK
+   listed twice keeps the entry that has a `VERW`.
+2. **Registration** E-planning drawing → CSV with `dxf_registration.py`: the
+   E symbols matching `[Registrierung] anker` (default `IN SEP`, the sensor that
+   sits on the separator) against the CSV separators. Stored under the key
+   `<csv>|<positionsdraw>` in `%SKEL_CFG%\dxf_registration.json` and re-verified
+   on every run; `--re-register` forces a new derivation.
+3. **Rules** from `%SKEL_CFG%\e_planning.ini`, one section `<kind>.<role>` per
+   rule, applied in file order; each E device is given out at most once, each
+   role of a layout part filled at most once:
+
+   | key | meaning |
+   |---|---|
+   | `layout` | layout kind pattern (default: the part before the dot): `Separator`, `Ausschleus`, `Einschleus`, `Weiche`, `Scanner`, `Beladung`, `Entladung` |
+   | `verw`, `praefix` | pattern(s) for the E attribute `VERW`, BMK prefix (`BG`, `MB`) |
+   | `max_mm` | spatial: maximum distance after registration |
+   | `soll_mm`, `toleranz_mm` | spatial: the symbol always sits this far from the part; candidates are ranked by their deviation from it, not by the smallest distance |
+   | `nummer_von`, `nummer_versatz` | numbering rule: BMK number = number of the given role + offset (Mubea: valve = sensor + 1) — tried first, distance only for the rest |
+
+   Shipped rules (tuned on Mubea): `Separator.sensor`, `Separator.stopper`,
+   `Ausschleus.stau`, `Ausschleus.ventil`, `Weiche.ventil`. `VERW` texts and the
+   numbering rule are project-specific — in the reference SCL (UH01..UH05)
+   sensor and stopper share the number (BG3242/MB3242), i.e. offset `0`.
+4. **Drives**: motor `MAnnnn` ↔ motor protection `FCnnnn` (same number), for the
+   report.
+
+Uncertain cases stay open on purpose: a gap is better than a plausible wrong
+name. The report lists, per role, the layout parts without a match, the field
+devices without a match, and distance and runner-up distance of every match
+(close values = check by hand).
+
+Switches: `--file NAME` (CSV, default `export.csv`), `--eplan NAME`
+(positionsdraw JSON, required; bare name resolved against `%SKEL_DATA%`, or a
+full path), `--rules FILE` (default `%SKEL_CFG%\e_planning.ini`),
+`--re-register`. Exit `0` also when not everything was assigned; `1` on input
+errors or when the registration cannot be proven.
+
+**Today only separator sensor and stopper reach the SCL.** Jam sensors and
+outfeed/switch valves are assigned in the JSON/report, but the TRO-JSON does not
+yet say which outfeed element or switch belongs to which TRO exit, so
+`scl_skeleton` cannot place them. The same holds for the storage lines of a
+`PinStore` TRO (`arInSep[n]`): their sensors are assigned but the generator does
+not emit per-line parameters yet.
+
+Result on Mubea (`mubea.csv` + `Mubea_positionsdraw.json`): registration
+dx +50613.6 / dy +8555.8 mm; separator sensor 21/38, stopper 22/38 (all 20
+storage lines exact, 0–1 mm), jam sensor 20/23, outfeed valve 20/23, switch
+valve 1/1. The open separators are on the carousels K0102/K0104/K0105, where
+the E-planning drawing and the CSV apparently differ.
+
+Tests: `tests/test_e_planning.py` (reading, rules, numbering vs. distance on a
+storage-line grid, target distance, uniqueness, registration, drives, the path
+into `scl_context` and `scl_skeleton --eplan`).
+
 ## 6. `tro_catalog.py` — TRO type catalog (library, no CLI)

 The single source of truth for everything needed to generate or draw a TRO