- 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>
162 lines
9.0 KiB
Markdown
162 lines
9.0 KiB
Markdown
# Brücke Layout ↔ E-Planung über `*_positionsdraw.json`
|
||
|
||
Stand 2026-10-10. Erst Machbarkeitsprüfung, inzwischen umgesetzt als
|
||
`lib/e_planning.py` (Regeln `cfg/e_planning.ini`, Aufruf `bin/e_planning.bat`,
|
||
`scl_skeleton --eplan`); Bedienung in `doc/Python_Scripts.md` §5c, Stand der
|
||
Umsetzung unten.
|
||
|
||
## Problem
|
||
|
||
Das Kapitel "Daten" in `doc/Klassenhierarchie.md` zeigt: das Hardwarelayout (CSV)
|
||
liefert die **Struktur** (welche TROs, welche Separatoren/Weichen, wer mit wem), die
|
||
E-Planung die **Namen und Adressen** (`BG…`, `MB…`, `MA…`, `FC…`). Die EA-Liste allein
|
||
kennt aber keine Topologie. Es fehlt die Zuordnung **Layout-Bauteil (CSV-`TeileId`) →
|
||
Betriebsmittelkennzeichen (BMK)**.
|
||
|
||
## Idee
|
||
|
||
Die E-Planung wird als Layer über der Hardwareplanung gezeichnet: Sensor- und
|
||
Aktorsymbole liegen in der Zeichnung neben dem Bauteil, zu dem sie gehören. Das
|
||
Kabellängen-Tool (`C:\10-Develop\gitrepos\kabellaengen`, `lib/getpositions.py`)
|
||
schreibt diese Symbole mit Position und Attributen nach `<zeichnung>_positionsdraw.json`.
|
||
Damit ist die Brücke eine **räumliche Zuordnung**: E-Symbol → nächstes Layout-Bauteil
|
||
passender Art.
|
||
|
||
## Datenquelle `*_positionsdraw.json`
|
||
|
||
| Schlüssel | Inhalt | Nutzen für sps_skel |
|
||
|---|---|---|
|
||
| `sensors` | je BMK (`BG0642@UNKNOWN`): `pos` [x, y], `VERW` (Verwendung), `BEZEICHNUNG` (Klartext), `BESCHR`, `ARTINR`, `KENNZEICHNUNG` (`=A1+UH01-KF107`) | Hauptquelle: Sensoren/Ventile/Motoren im Feld |
|
||
| `schaltschrank_elemente` | Elemente im Schrank (Motorschutz `FC…`, Taster, Leuchten, `QA…`) mit `VERW`, `BEZEICHNUNG`, `KENNZEICHNUNG`, ohne Feldposition | Motorschutz ↔ Motor, Bedienelemente |
|
||
| `mappings` | Steuerung → Liste ihrer BMK (`UH01: [...]`) | Steuerungsaufteilung, Nummernkreis |
|
||
| `racks`, `distributors`, `tunnels` | Kabeltrassen, Verteiler | für sps_skel ohne Belang |
|
||
| `double_ids`, `warnings` | doppelte BMK, fehlende Attribute | Qualitätsprüfung der E-Daten |
|
||
|
||
Die Erdungs-Beispiele (`PR500501_…_Erdung_…`, `ST500652_…`) enthalten nur
|
||
Potentialausgleich (`POT…`) und taugen nicht für die Brücke. Brauchbar sind
|
||
Dateien mit `BG`/`MB`/`MA`: `Mubea_positionsdraw.json` (157 Feld-BMK),
|
||
`ST500592_ILS_positionsdraw.json` (~3100), `ST500592_10_5-10_Omniflo_…` (~900),
|
||
`ST-Fortna_positions_.json` (mit 38 Scannern `BX`).
|
||
|
||
## Test an Mubea
|
||
|
||
Eingaben: `data/mubea.csv` (Layout, 38 Separatoren) und
|
||
`kabellaengen/work/Mubea_positionsdraw.json` (E-Planung). Die Zahlen in diesem
|
||
Abschnitt stammen aus der ersten Untersuchung (Umkreis 700 mm, ohne Regeln); das
|
||
Ergebnis der Umsetzung steht unten.
|
||
|
||
### 1. Lagebezug
|
||
|
||
Die Ermittlung aus `lib/dxf_registration.py` (`derive_transform`) funktioniert
|
||
unverändert, wenn man die E-Symbole mit `VERW` `SEP`/`IN SEP` als Rolle "Separator"
|
||
einsetzt:
|
||
|
||
```text
|
||
mubea.csv <- Mubea_positionsdraw.json: dx +50613.6 mm, dy +8555.8 mm, Drehung 0
|
||
26/38 Separatoren im Toleranzband
|
||
```
|
||
|
||
Das entspricht dem schon gespeicherten Bezug `mubea.csv|500573_60_1.dxf`
|
||
(dx +50833.7, dy +8414.5) bis auf ~250 mm: die E-Zeichnung liegt im selben
|
||
Koordinatensystem wie die Layoutzeichnung. Zum Prüfen genügt also der
|
||
bestehende Mechanismus; als Schlüssel in `cfg/dxf_registration.json` kann
|
||
`<csv>|<positionsdraw.json>` dienen.
|
||
|
||
### 2. Was sich zuordnen lässt
|
||
|
||
| E-Symbol (`VERW`) | Layout-Partner | Abstand | Ergebnis |
|
||
|---|---|---|---|
|
||
| `IN SEP` (BG, Sensor im Separator) | Separator | **0–1 mm** im Pin-Speicher (20/20), sonst 200–500 mm | Anker: das Symbol sitzt auf dem Separator |
|
||
| `SEP` (MB, Stopperventil) | Separator | konstant **~270 mm** daneben | eindeutig über Nummernregel (unten), nicht über Abstand |
|
||
| `AE ABZWEIG` (MB, Ausschleusventil) | Ausschleuselement | konstant **1414 mm** (20/20, Versatz (−1405, −159)) | eindeutig, wenn der Versatz je Symbolart bekannt ist |
|
||
| `STAU_REF-LT` (BG, Stausensor) | Ausschleuselement | konstant **1391 mm** (20/20) | wie oben |
|
||
| `ABZWEIG-K104` (MB, Weiche) | Weiche | 783 mm | eindeutig (nur eine Weiche) |
|
||
| `BANDBRUCH`, `KETTENBRUCH`, `ÜBERGABE`/`ÜBERNAHME`, `SYNC P1..4`, `ZAPPLER` | Kreisel/Strecke/Station | uneinheitlich, teils > 50 m (Symbol an Konvejoren außerhalb des CSV-Ausschnitts) | nicht über Abstand, nur über `BEZEICHNUNG` |
|
||
|
||
Nebeneinander liegende Separatoren (Pin-Speicher, Raster 800 mm) machen den
|
||
Abstand allein mehrdeutig: das MB von Strecke n liegt 270 mm von Separator n und
|
||
530 mm von Separator n+1. Eindeutig wird es erst mit der Nummernregel.
|
||
|
||
### 3. Nummernregel der E-Planung
|
||
|
||
Ventil = Sensor + 1, gleiche Funktionsgruppe:
|
||
|
||
| Paar | Treffer (von 58 MB) |
|
||
|---|---|
|
||
| `MB(n)` `SEP` ↔ `BG(n−1)` `IN SEP` (z. B. BG0642 / MB0643) | 31 |
|
||
| `MB(n)` `AE ABZWEIG` ↔ `BG(n−1)` `STAU_REF-LT` (z. B. BG0542 / MB0543) | 21 |
|
||
| sonstige Paare (`VEREINZ(CP)`, `STOPPER (CP)`, `AE ABZW.`) | 3 |
|
||
| ohne BG-Partner | 3 |
|
||
|
||
Damit reicht es, den **Sensor** räumlich zuzuordnen (der `IN SEP` liegt auf dem
|
||
Separator); das Ventil folgt aus der Nummer. Die SCL-Referenzen zeigen dasselbe
|
||
Muster (`stSenInSep := …["cInBG3242"]`, `xOutStopper1 => "MB3242"`) — dort sogar
|
||
mit gleicher Nummer; die Regel ist also projektabhängig und gehört in eine
|
||
Konfiguration, nicht in den Code.
|
||
|
||
Gleiches gilt für Motor ↔ Motorschutz: `MA0200` "PIN CONVEYOR#100" ↔
|
||
`FC0200` "MOTORSCHUTZ CONVEYER #100" (gleiche Nummer, `schaltschrank_elemente`),
|
||
wie in der SCL `xOutVarioMotor => "MA0145"`, `xInMotorProtection := "FC0145"`.
|
||
|
||
### 4. Was nicht passt
|
||
|
||
12 von 38 Layout-Separatoren (vor allem an den Kreiseln K0102/K0104/K0105) haben im
|
||
Umkreis von 700 mm kein `IN SEP`/`SEP`; umgekehrt liegen mehrere `IN SEP` des
|
||
Kreisels K0102 neben Aus-/Einschleuselementen statt neben einem Separator. Vermutlich
|
||
ist die CSV (aus `500573_60_1.dxf`) ein anderer Planungsstand als die E-Zeichnung
|
||
`Mubea.dxf` des Kabellängen-Tools, oder Kreisel-Separatoren sind im CSV anders
|
||
modelliert. Das muss mit zueinander passenden Ständen geprüft werden, bevor man
|
||
eine Quote angibt.
|
||
|
||
`Mubea_positionsdraw.json` enthält **keine Scanner** (`BX`). Für Scanner-Zuordnung
|
||
ist ein anderes Projekt nötig (`ST-Fortna_positions_.json`, `ILS-Baugruppe`).
|
||
|
||
## Was die Brücke für das Kapitel "Daten" liefert
|
||
|
||
| SCL-Datum | aus `positionsdraw.json` | Regel |
|
||
|---|---|---|
|
||
| `stInSeparator<n>.stSenInSep` | BG mit `VERW` `IN SEP` | räumlich am Separator (Anker) |
|
||
| `xOutStopper<n>` | MB mit `VERW` `SEP` | Nummernregel ab dem BG |
|
||
| `stInSenJam<n>`, `Settings.xPluggedJam` | BG `STAU_REF-LT` | räumlich, Versatz je Symbolart; vorhanden ⇒ `xPluggedJam := TRUE` |
|
||
| `xOutSw<n>ExTo3/4` | MB `AE ABZWEIG` / Weichen-MB | Nummernregel ab dem Stausensor bzw. räumlich an Weiche/Ausschleuselement |
|
||
| `Settings.xPluggedPart`, `stSenPart` | BG `BT BELADEN` | räumlich; vorhanden ⇒ `TRUE` |
|
||
| `xInMotorProtection`, `xOutVarioMotor` | MA im Feld + FC in `schaltschrank_elemente` | gleiche Nummer |
|
||
| `xInCarouselRun` (welcher Antrieb) | FC/MA-`BEZEICHNUNG` "KREISEL-K0102", "CONVEYOR #100" | Textabgleich mit dem Host-Kreisel des TRO |
|
||
| Steuerung, TRO-Nummernkreis, `stInOutMachineState` | `KENNZEICHNUNG` `=A1+UH01-KF107`, `mappings` | `UH01` = Steuerung, `KF107` = E/A-Station |
|
||
| Plausibilisierung | `BEZEICHNUNG` "SEPARATOR STR. 14", "KR-K0102 VOR BT-BELADUNG" | Strecken-/Kreiselnummer gegen Layout prüfen |
|
||
|
||
Nicht aus dieser Quelle: Not-Halt-Kreis (`xInSftyOk`), Taster für Automatik/Quittieren
|
||
(stehen nur als Schrankelemente ohne Bezug zum TRO), Scanner-Hardwarekennungen,
|
||
Weichenbauart (`xNewSwitch`).
|
||
|
||
## Umsetzung (Stand 2026-10-10)
|
||
|
||
1. **`lib/e_planning.py`**: liest `*_positionsdraw.json` in `EDevice` (BMK, VERW,
|
||
Bezeichnung, Kennzeichnung → Steuerung/E/A-Station, Position).
|
||
2. **Lagebezug** über `dxf_registration.derive_transform` mit den `IN SEP`-Sensoren
|
||
als Rolle "Separator"; abgelegt in `cfg/dxf_registration.json` unter
|
||
`<csv>|<positionsdraw.json>`.
|
||
3. **Regeln in `cfg/e_planning.ini`** (projektabhängig): je Rolle Layout-Art, VERW,
|
||
Höchstabstand, **Sollabstand** (für die konstanten Versätze von Stausensor und
|
||
Ausschleusventil — sonst gewinnt bei 0080/0084 ein näherer, fremder Stausensor
|
||
des Kreisels K0102) und die Nummernregel (`MB = BG + 1`).
|
||
4. **Ausgabe** `<csv>_eplan.json` (`EplanDocument`) und Bericht `<csv>_eplan.md`.
|
||
`scl_skeleton --eplan` setzt Separator-Sensor und Stopperventil ein
|
||
(`SclName.todo = False`); alles andere bleibt `TODO(E-Planung)`.
|
||
|
||
Ergebnis Mubea mit den ausgelieferten Regeln: Separator-Sensor 21/38,
|
||
Stopper 22/38, Stausensor 20/23, Ausschleusventil 20/23, Weichenventil 1/1. Den
|
||
Separator-Sensor nimmt die Regel nur bis 300 mm; die Kreisel-Fälle mit 470–540 mm
|
||
(z. B. BG0532 an 0044) bleiben bewusst offen.
|
||
|
||
Offen:
|
||
|
||
- Stausensoren und Ausschleus-/Weichenventile stehen in JSON und Bericht, kommen
|
||
aber noch nicht in die SCL: die TRO-JSON sagt nicht, welches Ausschleuselement
|
||
bzw. welche Weiche zu welchem TRO-Ausgang gehört.
|
||
- Die Lagerlinien eines `PinStore`-TRO (`arInSep[n]`) sind zugeordnet, der
|
||
Generator erzeugt die Linienparameter aber noch nicht.
|
||
- Scanner (`BX`) fehlen in den Mubea-Daten; Regel und Test mit
|
||
`ST-Fortna_positions_.json` stehen aus.
|
||
- Ein Abgleich mit passenden Ständen von CSV und E-Zeichnung für die Kreisel.
|