Merge branch 'master' of https://gitea.schoenenberger.de/Schoenenberger_Systeme_GmbH/sps_skel

doc/Python_Scripts.md

@@ -1,12 +1,13 @@
 # Python Scripts — CLI Tooling Overview
 
-**As of:** 2026-08-03
+**As of:** 2026-08-20
 
-`lib/` currently holds five Python modules (three of them runnable CLI tools,
-two supporting libraries), plus one documentation-generator script that lives
+`lib/` currently holds eight Python modules (five of them runnable CLI tools,
+three 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, and an annotated copy of the BricsCAD drawing.
+list/diagram, an annotated copy of the BricsCAD drawing, a TRO-JSON read back
+out of that drawing, and an `FB_Main` SCL skeleton generated from that JSON.
 
 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
@@ -27,8 +28,14 @@ tro_flow.py       ──►  <name>_tro_flow.dot / .svg, _tro_doc.md, _tro_error
    │   (derives TROs, using the type catalog in tro_catalog.py)
    ▼
 tro_annotate.py   ──►  <name>_annotated.dxf, <name>_registration.json
-   (also needs the BricsCAD DXF; uses dxf_registration.py for the CSV↔DXF
-    coordinate offset and tro_catalog.py for marker shape/color per TRO type)
+   │   (also needs the BricsCAD DXF; uses dxf_registration.py for the CSV↔DXF
+   │    coordinate offset and tro_catalog.py for marker shape/color per TRO type)
+   ▼   (drawing may be hand-edited in BricsCAD before the next step)
+tro_extract.py    ──►  <drawing>_tro.json
+   │   (reads only the drawing; resolves plant coords via the registration)
+   ▼
+scl_skeleton.py   ──►  <source>_FB_Main.scl
+   (one REGION per TRO; E-planning values left as TODO(E-Planung) gaps)
 ```
 
 - `material_flow.py` models the material flow of the **mechanical** objects only
@@ -47,6 +54,9 @@ 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_overrides.py`** — reads the hand-maintained
+  `%SKEL_CFG%\tro_overrides.ini` (type corrections, open points, TRO merges)
+  that survive re-runs of `tro_flow.py`. See §6a.
 
 Separate, documentation-only tool (not part of the generator pipeline):
 
@@ -74,7 +84,7 @@ bin\tro_annotate.bat --file mubea.csv --dxf 500573_60_1.dxf --flow --fb --legend
 (`--use-cords` lays both graphs out at the real plant coordinates; drop it for
 Graphviz's computed left-to-right arrangement.)
 
-Conventions shared by all three tools:
+Conventions shared by the CLI tools:
 
 - `--file` / `--dxf` accept either a bare filename — resolved against
   `%SKEL_DATA%` — or a full path.
@@ -88,7 +98,11 @@ Conventions shared by all three tools:
   `ezdxf>=1.4.0` for `tro_annotate.py` only) — run `bin\install_py.bat` once.
 - `--tosvg` needs Graphviz's `dot` (or `neato`, for `tro_flow.py
   --use-cords`) on `PATH`, or the `GRAPHVIZ_DOT` environment variable pointing
-  at the `dot` executable.
+  at the `dot` executable. `bin/material_flow.bat`/`.sh` and `bin/tro_flow.bat`/`.sh`
+  check for the right engine up front when `--tosvg` is passed and print an early
+  `WARNUNG` if it's missing (`GRAPHVIZ_DOT` only covers `dot`, not `neato`) — this
+  is just a heads-up before the CSV is even parsed; the Python script still runs
+  and reports the same failure in detail (exit code `2`) if the SVG step is reached.
 
 ## 3. `material_flow.py` — material-flow graph of the mechanical layout
 
@@ -122,6 +136,16 @@ Reads the CSV export and builds a directed graph of the mechanical objects:
 > will contain the 61 conveyor items but **no** BTMT rows, so no entry/exit nodes
 > appear. The recognition above is ready for when BTMT rows are present.
 
+In the rendered graph, **parallel Gefällestrecken between the same two Kreisel
+lanes with the same slope** (`Hoehe_Von_mm`/`Hoehe_Bis_mm`) — a typical
+line-storage bank — are drawn as a **single** Gefällestrecke-styled box with a
+double border (`peripheries=2`) instead of one box per line. Its label states
+the id range and count of the merged lines plus the combined Separator/Scanner
+id ranges, e.g. `Gefaellestrecke 0017 - 0036 (20x)` / `Separator (20): 0037 -
+0056`. This is purely a rendering simplification (`_group_parallel_gefaelle`
+in `lib/material_flow.py`) — the underlying graph, `--doc` report and
+`--connect` output are unaffected and still list every line individually.
+
 Flow direction between conveyor segments is derived from height change
 (`Hoehe_Von_mm`/`Hoehe_Bis_mm`) or, failing that, from `Antriebfahrtrichtung`
 ("Auf"/"Ab"); connections whose direction can't be determined are drawn