# Brücke Layout ↔ E-Planung über `*_positionsdraw.json`

Stand 2026-10-15. 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. Am 2026-10-15 mit dem neuen Mubea-Datensatz in `data/Mubea/`
(TIA-Import + Positionsdatei) nachgeprüft; Ergebnisse unter "Nachprüfung
2026-10-15".

## 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` (158 Feld-BMK, davon 157
in `mappings` unter UH01 — `BG0514` hat eine leere `KENNZEICHNUNG`),
`ST500592_ILS_positionsdraw.json` (~3100), `ST500592_10_5-10_Omniflo_…` (~900),
`ST-Fortna_positions_.json` (mit 38 Scannern `BX`).

`*_positionsconv.json` und `*_positionsdraw.json` sind bei Mubea byte-gleich;
eine von beiden genügt.

## Datenquelle TIA-Import `*_TIA.xlsx`

Die zweite nötige Quelle. Blatt **PLC Tags**: je Signal Name (`BG0542`),
Absolutadresse (`%E…`/`%A…`), Kommentar. Blatt **Constants**: je Signal eine
Index-Konstante `cIn<BMK>`/`cOut<BMK>` (laufender Index, **nicht** aus der
Adresse berechenbar).

| Nutzen | Warum |
|---|---|
| SCL übersetzbar | Sensoren stehen im SCL als `"DB_Inputs".Sensors["cInBG…"]`, Ventile als `"MB…"`; beides muss im TIA-Projekt existieren — der TIA-Import liefert genau diese Tags und Konstanten |
| Prüfliste | jeder Name im erzeugten SCL muss im TIA-Import stehen |
| `FB_CallSensors`, Größe `DB_Inputs` | alle `cIn…`-Konstanten mit Wert (noch nicht generiert) |
| Schrank- und Antriebssignale | `SF…` (Taster, Not-Halt), `PF…` (Leuchten), `MA…`/`FC…` (Motor/Motorschutz), `GF…` (Geber), `BP…`, `DI…` |

Mubea: 237 Tags (105 BG, 64 MB, 26 SF, 17 PF, 11 MA, 11 FC, je 1 BP/DI/GF) und
237 Konstanten (144 `cIn`, 93 `cOut`). Alle 158 Feld-BMK und 80 von 81
Schrankelementen (fehlt: `QA7000`) der Positionsdatei stehen im TIA-Import, die
Kommentare sind 1:1 gleich der `BEZEICHNUNG`.

**Nicht nötig** (Mubea): `*_EA.xlsx` (dieselben 237 Signale, nur Adresse und
Kommentar, keine Namen), `*_WSCAD.xlsx` (zusätzlich nur die E/A-Baugruppe je
Kanal, die `KENNZEICHNUNG` der Positionsdatei schon trägt, und 259 freie Kanäle),
`*_BOM.xlsx`, `*_cables.*`, `*_todraw.json`, `*_errors.json` (Kabel, Stückliste,
Trassen; die Qualitätswarnungen stehen auch in der Positionsdatei). Eingaben für
die Brücke also: **CSV + TIA-Import + eine Positionsdatei**.

## Test an Mubea

Eingaben: `data/mubea.csv` (Layout, 38 Separatoren) und
`kabellaengen/work/Mubea_positionsdraw.json` (E-Planung, alter Stand). Die Zahlen
in diesem Abschnitt stammen aus der ersten Untersuchung (Umkreis 700 mm, ohne
Regeln); das Ergebnis der Umsetzung und die Nachprüfung mit dem neuen Stand
`data/Mubea/Mubea_positionsdraw.json` stehen 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: diese (alte) E-Zeichnung lag im selben
Koordinatensystem wie die Layoutzeichnung. Zum Prüfen genügt also der
bestehende Mechanismus; als Schlüssel in `cfg/dxf_registration.json` dient
`<csv>|<positionsdraw.json>`.

Das gilt **nicht allgemein**: der neue Stand in `data/Mubea/` liegt in einem
anderen Koordinatensystem (dx −151.4, dy −696.6, siehe "Nachprüfung
2026-10-15"). Der Lagebezug ist je Datei neu zu ermitteln, nicht von der
Layoutzeichnung zu übernehmen.

### 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" | **räumlich**, nicht über Text: das CSV nennt die Kreisel `Kreisel1/2/3`, die E-Planung `K0102/K0104/K0105`. Alle Symbole, deren `BEZEICHNUNG` einen Kreisel nennt, per Mehrheit dem nächsten CSV-Kreisel zuordnen (siehe Nachprüfung) |
| 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: Scanner-Hardwarekennungen, Weichenbauart (`xNewSwitch`).

Auch nicht aus den E/A-Daten, aber **je Projekt nur ein Wert**: `xInSftyOk`,
`stInOutMachineState`, `xInAutomatic`, `xInErrorQuit`. Der TIA-Import enthält
zwar die Not-Halt-Kanäle (`SF5000…SF6006`) und `SF0001` "ANLAGE EIN" / `SF0002`
"START NACH STÖRUNG", die Referenz-SCL verdrahtet diese Parameter aber nicht mit
E/A-Signalen, sondern mit dem Sicherheitsprogramm
(`"DB_InterfaceSafety".stFromSafety.EStopMain….Q`) bzw. der Schrank-Struktur
(`#stInOutControlUnitCabinet…`). Sie gehören als Projektkonstanten in eine
Konfiguration (bei Mubea ~39 der offenen Stellen), nicht in die Brücke.

## 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 (alter Stand) 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.

## Nachprüfung 2026-10-15 (neuer Stand `data/Mubea/`)

Lauf: `e_planning --file mubea.csv --eplan <voller Pfad>\data\Mubea\Mubea_positionsdraw.json`,
dann `tro_flow --json` und `scl_skeleton --eplan --templates`.

| | alter Stand | neuer Stand |
|---|---|---|
| Lagebezug | dx +50613.6, dy +8555.8 | **dx −151.4, dy −696.6**, Drehung 0, 23/38 Punkte, Restfehler max 541 mm |
| Separator-Sensor | 21/38 | 21/38 |
| Stopper | 22/38 | 22/38 |
| Stausensor | 20/23 | **21/23** |
| Ausschleusventil | 20/23 | **19/23** |
| Weichenventil | 1/1 | 1/1 |
| Antriebe | — | 11, alle mit Motorschutz |

Im erzeugten `FB_Main` (18 TROs): 43 Namen aus der E-Planung, 440 Stellen
`TODO(E-Planung)`. Alle 21 Konstanten und 22 Tags im SCL stehen im TIA-Import.

Befunde:

- **Pfad:** `--eplan Mubea/Mubea_positionsdraw.json` (Unterordner relativ zu
  `%SKEL_DATA%`) wird nicht gefunden; nur ein Dateiname direkt in `%SKEL_DATA%`
  oder ein voller Pfad geht.
- **Gespeicherter Lagebezug:** der Schlüssel `<csv>|<positionsdraw.json>` in
  `cfg/dxf_registration.json` enthält nur den Dateinamen. Ein neuer Stand mit
  gleichem Namen übernimmt ohne `--re-register` still den alten Bezug — beim
  Mubea-Wechsel wären das ~51 m Versatz gewesen.
- **Kreisel-Zuordnung räumlich möglich:** die Symbole, deren `BEZEICHNUNG` einen
  Kreisel nennt (nach dem Lagebezug, Abstand zur Boundingbox), liegen eindeutig
  auf einem CSV-Kreisel — **K0102 = Kreisel3 (0010)**, **K0104 = Kreisel2 (0002)**,
  **K0105 = Kreisel1 (0001)**; ein Ausreißer (`BG0725` "BANDBRUCHÜBERWACHUNG
  KR-K0105" an Kreisel2). Damit erhält jeder Kreisel seinen Antrieb
  (`MA0202`/`FC0202`, `MA0205`/`FC0205`, `MA0206`/`FC0206`) und K0102 seinen Geber
  `GF20000`.

Was sich mit TIA-Import + Positionsdatei noch schließen lässt:

| Offene Stellen (Mubea) | Anzahl | Weg |
|---|---|---|
| `stInSenJam<n>` | ~17 | schon zugeordnet; fehlt nur TRO-Ausgang → Ausschleuselement (siehe "Offen") |
| `xInCarouselRun` | ~13 | Kreisel-Zuordnung oben + Motorpaar |
| Vario-Sensoren (`stSenLastPos`, `stSenJam`, `stSenFinger`, `stSenCarrInPos`), `xOutVarioMotor`, `xInMotorProtection` | ~18 | wahrscheinlich, neue Regeln über `VERW` (`SYNC P1..4`, `ZAPPLER`, `ABFR.FINGER`, `BT BELADEN`) und die Motorpaare; zu prüfen |
| `xInSftyOk`, `stInOutMachineState`, `xInAutomatic`, `xInErrorQuit` | ~39 | Projektkonstante (oben), nicht aus diesen Dateien |
| `nSeparatorNo`/`nSwitchNo`, Zeiten, Staubereichs-Verdrahtung | Rest | weder TIA noch Positionsdatei |

Die 17 nicht zugeordneten Separatoren an den Kreiseln sind ein Standunterschied
Layout ↔ E-Zeichnung, keine fehlenden Daten.

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.
- ~~TIA-Import einlesen~~ — **erledigt** 2026-10-15: `lib/hw_import.py`
  (`<projekt>_hw.json`); `FB_CallSensors` daraus steht noch aus.
- ~~Kreisel ↔ E-Kreisel (`K01xx`) räumlich zuordnen~~ — **erledigt** in
  `lib/merge_hw_layout.py` (Mehrheit, nur Förderer der genannten Art); in die SCL
  (`xInCarouselRun`) kommt es mit der Umstellung von `scl_skeleton` auf die
  Anlagen-JSON.
- ~~Gespeicherten Lagebezug absichern~~ — **erledigt**: SHA-256 der
  Positionsdatei im Eintrag von `cfg/dxf_registration.json`.
- ~~Unterordner in `--eplan`~~ — **erledigt** (`material_flow.resolve_input`).

## Abgleich Layoutzeichnung ↔ CSV ↔ E-Planung (2026-10-15)

Zeichnung `data/mubea_layout.dxf` (aus `mubea_layout.dwg`), gelesen über alle
Blockebenen mit vollständiger Blocktransformation (die `Staustrecke…`-Blöcke
der Gefällestrecken sind mit gekippter Extrusionsrichtung eingefügt; ohne
OCS liegen ihre Separatoren falsch).

| Vergleich | Ergebnis |
|---|---|
| DXF ↔ `mubea.csv` | **gleiches Koordinatensystem, kein Versatz.** 38/38 Separatoren je 60–70 mm (Einfügepunkt `Separator_SP_3D` gegen CSV-Punkt, in Blockrichtung), 8/8 Scanner je 360 mm, Aus-/Einschleuselemente 22/23 bzw. 22/23 auf 0 mm (`0061`, `0064` und die Weiche `0125` sind keine eigenen Blöcke) |
| E-Planung ↔ DXF | (−211, −697) mm; Speicherlinien 20/20 auf **1 mm** |
| E-Planung ↔ CSV | (−151, −697) mm; 23/38 im Toleranzband |

Die 20 Separatoren der Gefällestrecken passen mit dem Versatz exakt (ohne ihn
liegt jeder Sensor eine Speicherlinie daneben, 235 mm). Die 12 Separatoren an
Kreiseln/Strecken und die 6 Vario-Separatoren passen in **keiner** Lage
(155–3438 mm, mit und ohne Versatz). Es gibt also keine starre Transformation
für die ganze Anlage: der Speicher ist in der E-Zeichnung als Ganzes
verschoben, der Bereich um die Kreisel ist ein anderer Planungsstand.
Folge: die Kreisel-Separatoren bleiben offen, bis E-Zeichnung und Layout zum
selben Stand gehören; `merge_hw_layout` warnt deshalb (23/38 = 61 %).

Nebenbefund für `tro_annotate` (Kontrollansicht): es liest nur die
Modellbereichs-Blöcke (12 der 38 Separatoren, die übrigen stecken in
`GF_n`/`VF_n`), und der Lagebezug übernimmt den 60-mm-Einfügeversatz als
scheinbare Verschiebung (dx +59.8).