Stabile TRO-IDs: ID-Datei je Anlage, Wiederfinden ueber die Lage

- lib/tro_ids.py: cfg/<csv>_tro_ids.ini lesen/schreiben, TROs ueber die
  Lage ihrer Separatoren wiederfinden, neue IDs vergeben, Weggefallene melden
- tro_flow: Nummerierung entlang des Materialflusses, Schalter --ids,
  --renumber, --id-tolerance; Bericht der IDs
- tro_annotate: liest dieselbe ID-Datei (nur lesend)
- Tests tests/test_tro_ids.py, Doku Python_Scripts.md, Konzept (Stufe 1 erledigt)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

doc/Konzept_Layout_Hardware_SCL.md

@@ -220,26 +220,42 @@ stabil: Vergleich zweier Exporte derselben Anlage
 
 Stabil ist nur die **Lage** des Bauteils.
 
-**Vorschlag:**
+**Umgesetzt (2026-10-11, `lib/tro_ids.py`, Schalter in `tro_flow.py`;
+Einzelheiten in `doc/Python_Scripts.md` §4 "TRO-IDs"):**
 
-- Eine versionierte ID-Datei je Anlage, z. B. `cfg/<anlage>_tro_ids.ini`: je TRO
-  die ID und die Lage seines Anker-Separators (x, y in mm), optional ein Name.
-  Von `tro_flow` angelegt, von den SPS-Programmierern umbenannt.
+- Eine versionierte ID-Datei je Anlage, `cfg/<csv>_tro_ids.ini`, Abschnitt
+  `[tro]`: je TRO die ID und die Lage seines Anker-Separators (x, y in mm), der
+  Kommentar dahinter nennt Typ, Bezeichnung und Separatoren. Von `tro_flow`
+  angelegt, von den SPS-Programmierern umbenannt. Weitere Abschnitte (später
+  Separator- und Förderernummern) bleiben bei jedem Lauf erhalten. Ein anderer
+  Export derselben Anlage nutzt dieselbe Datei über `--ids`.
 
   ```ini
-  ; Beispiel, Werte erfunden
-  [mubea]
-  TRO107 = 12450.0, 3310.0   ; Kreisel 2 vor Beladung
-  TRO108 = 13250.0, 3310.0
+  [tro]
+  TRO01 = -400.0, 13920.0    ; 1Sep1Swi | Separator 0003 auf Kreisel2 Bahn L | Sep 0003
+  K0302_1 = 10310.0, -440.1  ; von Hand umbenannt
   ```
 
 - **Standard (IDs halten):** `tro_flow` liest die ID-Datei und findet jeden TRO
-  über die Lage des Anker-Separators wieder (Toleranz einstellbar). Gefundene TROs
-  behalten ihre ID. Neue TROs bekommen eine vorläufige ID (nächste freie Nummer
-  entlang des Materialflusses) und stehen im Bericht; weggefallene TROs stehen im
-  Bericht, ihre ID wird nicht automatisch wiederverwendet.
+  über die Lage seiner Separatoren wieder (Toleranz `--id-tolerance`, Standard
+  100 mm, nächster Treffer zuerst, je TRO ein Eintrag). Gefundene TROs behalten
+  ihre ID, auch umbenannte. Neue TROs bekommen die nächste freie Nummer und
+  werden an `[tro]` angehängt; weggefallene stehen im Bericht (mit dem TRO, der
+  ihren Separator jetzt enthält), bleiben in der Datei, ihre ID wird nicht
+  wiederverwendet. `tro_annotate` liest dieselbe Datei, schreibt sie aber nicht.
 - **Programmschalter `--renumber` (frühe Phase):** alle IDs neu entlang des
-  Materialflusses vergeben und die ID-Datei neu schreiben.
+  Materialflusses vergeben (Tiefensuche ab den Beladestationen, auf Kreisel und
+  Strecke in `TrackIds`-Reihenfolge) und `[tro]` neu schreiben. Ohne ID-Datei
+  geschieht dasselbe beim ersten Lauf.
+- **Geprüft** mit `mubea.csv` → `mubea_export.csv` (andere TeileIds): 18 TROs
+  wiedergefunden, darunter eine umbenannte ID; `TRO14` als weggefallen gemeldet,
+  weil der Export die Separatoren 0005 und 0036 zu einem `2Sep2Swi` (`TRO13`)
+  zusammenfasst.
+- **Noch offen:** die Abschnitte `[mubea.csv.tro.TRO03]` usw. in
+  `cfg/tro_overrides.ini` hängen an der alten Nummerierung und passen schon
+  heute nicht mehr (`TRO03` ist dort Sep 0010, im aktuellen Lauf Sep 0011).
+  Sie werden auf die IDs der ID-Datei umgestellt, sobald `tro_flow` die
+  Overrides wieder liest.
 - Dadurch werden auch die Abschnitte `[<csv>.tro.<TRO-ID>]` in
   `cfg/tro_overrides.ini` und die Zuordnungen von `hw_assign` stabil.
 
@@ -317,6 +333,7 @@ unverändert.
 
 1. **TRO-IDs stabil machen:** ID-Datei, Wiederfinden über die Lage,
    `--renumber`. Darauf bauen Overrides, Staubereiche und Zuordnungen auf.
+   **Erledigt** (2026-10-11).
 2. Slots und `jamAreas` in die TRO-JSON (Umbau 1), ein Eingangs-Staubereich je
    TRO — ohne Slots hat die Zuordnung kein Ziel.
 3. `hw_import` mit dem TIA-Import als erster Quelle.
@@ -335,7 +352,8 @@ erzeugen, `doc/Python_Scripts.md` ergänzen.
 - **Staubereiche:** woher die Separatornummer (`Sep1024` → `J1024`) stammt; wo auf
   einem Kreisel die Zählung `<k>` beginnt (Referenz K0102 prüfen). Das SCL-Schema
   ist festgelegt (UH01–UH05).
-- **Toleranz** beim Wiederfinden der TROs über die Lage; Verhalten, wenn ein
-  Separator weiter verschoben wurde (Vorschlag: als "neu" + "weggefallen" melden,
-  der Programmierer übernimmt die ID von Hand).
+- **Toleranz** beim Wiederfinden der TROs über die Lage: vorläufig 100 mm
+  (`--id-tolerance`). Ein weiter verschobener Separator wird als "neu" und
+  "weggefallen" gemeldet, der Programmierer übernimmt die ID von Hand in der
+  ID-Datei. Mit echten Layoutänderungen prüfen, ob der Wert passt.
 - **Korrekturen in BricsCAD oder in der JSON:** zurückgestellt.

doc/Python_Scripts.md

@@ -73,6 +73,10 @@ Supporting libraries (no CLI of their own, imported by the tools above):
 - **`lib/dxf_registration.py`** — derives, verifies and persists the rigid
   (rotation + offset) transform between the CSV export's coordinate system and
   the DXF drawing's.
+- **`lib/tro_ids.py`** — the per-plant ID file `%SKEL_CFG%\<name>_tro_ids.ini`:
+  reads it, finds each TRO again by the position of its separators, assigns
+  new IDs, writes/extends the file. Used by `tro_flow.py` (read and write) and
+  `tro_annotate.py` (read only). See §4, "TRO-IDs".
 - **`lib/tro_overrides.py`** — reads the hand-maintained
   `%SKEL_CFG%\tro_overrides.ini`; only `material_flow.py --connect` still uses
   it. See §6a.
@@ -305,16 +309,44 @@ colors all come from `lib/tro_catalog.py` — nothing is hard-coded here.
 | `--connect` | — | off | Also write the TRO topology as `<name>_tro_connect.ini` (nodes, connections, system boundaries, predecessors/successors per TRO). Pure output, never read back. |
 | `--true-scale` | — | off | Only with `--use-cords`: draw to scale. By default empty stretches longer than 1500 mm between nodes are shortened (order and neighbourhood are kept). |
 | `--json` | — | off | Also write the TRO-JSON `<name>_tro.json` (schema `sps_skel-tro-v3`, model `TroDocument` in `lib/model.py`): TROs, system boundaries (`SYSn`), connections with their kind, findings. Input for `scl_skeleton.py`. |
+| `--ids` | `DATEI` | `<name>_tro_ids.ini` | ID file of the plant (name in `%SKEL_CFG%`, or a path). Use it to run another export of the same plant against the same IDs, e.g. `--file mubea_export.csv --ids mubea_tro_ids.ini`. |
+| `--renumber` | — | off | Number all TROs afresh along the material flow and rewrite the `[tro]` section of the ID file (early project phase). Renamed IDs are lost; other sections of the file are kept. |
+| `--id-tolerance` | `MM` (float) | `100.0` | Maximum distance between an ID-file entry and a separator of a TRO for the TRO to count as found again. |
 
 TROs, types and connections always come from the layout alone;
 `cfg/tro_overrides.ini` is not read. Errors in the derivation are fixed in
 `lib/tro_flow.py`, not in a correction file.
 
+**TRO-IDs** (`lib/tro_ids.py`). The IDs belong to the SPS programmers and must
+survive a new layout export; the layout `TeileId` changes between exports, the
+position does not. So every run reads `%SKEL_CFG%\<name>_tro_ids.ini`:
+
+```ini
+[tro]
+TRO01 = -400.0, 13920.0    ; 1Sep1Swi | Separator 0003 auf Kreisel2 Bahn L | Sep 0003
+K0302_1 = 10310.0, -440.1  ; renamed by hand
+```
+
+- Each entry is `ID = x, y` (mm, CSV coordinates) of the TRO's anchor
+  separator. An entry finds the TRO with a separator within `--id-tolerance`
+  (closest first, one entry per TRO), and that TRO keeps the ID — renamed IDs
+  included. An ID must be unique and a valid SCL identifier; `SYSn` is
+  reserved for system boundaries.
+- No file yet: the TROs are numbered along the material flow (depth-first from
+  the loading stations over the material-flow graph, on a carousel or Strecke in
+  `TrackIds` order) and the file is created.
+- A TRO not found gets the next free `TRO<n>` and is appended to `[tro]`;
+  an entry without a TRO is reported ("weggefallen", with the TRO that now
+  holds its separator, e.g. after two TROs merged into a `2Sep2Swi`) and stays
+  in the file; its ID is not reused.
+- The console report lists found / new / dropped IDs.
+
 **Output** (in `%SKEL_RESULTS%`): `<name>_tro_flow.dot` (always, with `pos`
 attributes when `--use-cords` was used), `<name>_tro_flow.svg` (with
 `--tosvg`), `<name>_tro_doc.md` (with `--doc`), `<name>_tro.json` (with
 `--json`), `<name>_tro_errors.md` (only if TROs are unconnected or of an
-unknown type).
+unknown type). In `%SKEL_CFG%`: `<name>_tro_ids.ini` (created, extended or,
+with `--renumber`, rewritten — see above).
 
 **Exit codes:** `0` ok · `1` input/CLI error · `2` SVG rendering failed
 (Graphviz) · `3` TRO validation errors found (error file written).
@@ -365,6 +397,7 @@ overridden.
 | `--legend` | — | off | Draw a legend of the color groups. |
 | `--marker-size` | `MM` (float) | `300.0` | Marker radius in mm. |
 | `--text-height` | `MM` (float) | `220.0` | Text height in mm. |
+| `--ids` | `DATEI` | `<csv-stem>_tro_ids.ini` | ID file as for `tro_flow.py`, **read only**: the markers carry the same IDs as the TRO-JSON. Without the file the TROs are numbered along the material flow, as `tro_flow.py` would. |
 | `--offset` | `DX,DY` | — | Set the CSV↔DXF offset by hand instead of deriving/loading it. For a drawing built with dxfmakros (CSV exported from the same drawing) this is `0,0`. |
 | `--re-register` | — | off | Re-derive the coordinate offset even if a verified one is already cached in `%SKEL_CFG%`. |
 | `--check` | — | off | Dry run: only analyze and report, write no output file. |