From fed13fa07793e52194fcb78cea3beb084365f5a7 Mon Sep 17 00:00:00 2001 From: Michael Stangl Date: Mon, 6 Jul 2026 17:42:59 +0200 Subject: [PATCH] =?UTF-8?q?Erg=C3=A4nzte=20Doku?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- doc/EA-Listen-Analyse.md | 141 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 doc/EA-Listen-Analyse.md diff --git a/doc/EA-Listen-Analyse.md b/doc/EA-Listen-Analyse.md new file mode 100644 index 0000000..3e0ecc4 --- /dev/null +++ b/doc/EA-Listen-Analyse.md @@ -0,0 +1,141 @@ +# Analyse der Ein-/Ausgabelisten (doc/Eingaben) + +## Kontext + +In `doc/Eingaben/` liegen je Steuerung (ILS-1 bis ILS-5, entspricht UH01-UH05) drei Excel-Dateien mit denselben E/A-Punkten in drei Sichten: + +| Datei | Inhalt | +| --- | --- | +| `..._EA.xlsx` | Rohliste: Adresse (`E000.0`), Kommentar, Zeilenreferenz (Schaltplan) | +| `..._TIA.xlsx` | Import-Liste fuers TIA Portal: Blatt "PLC Tags" (BMK-Name, `Data Type`, `%E`/`%A`-Logikadresse, Kommentar, HMI-Flags) + Blatt "Constants" (`cIn`-Indexkonstanten) | +| `..._WSCAD.xlsx` | Import-Liste fuers WSCAD (E-CAD): Anschluss, Kommentar, **Bezug** (Ortskennzeichen, z.B. `=A01+UC2101-KF1DI1`) | + +Alle Signale sind **Bool** (reine Digital-E/A-Listen). Analogwerte (Tilt-/Distanzsensoren), PROFINET-Geraete (Cognex-Scanner BX, RFID) und Antriebsparameter sind **nicht** enthalten — diese werden anderweitig projektiert. + +Umfang: ILS-1 (UH01) 443 Tags, ILS-2 (UH02) 1578 Tags, ILS-3 (UH03) 1608 Tags, ILS-4 (UH04) 203 Tags, ILS-5 (UH05) 243 Tags. + +## Namenspraefixe (BMK-Schema) + +| Praefix | Bedeutung | Beispiel | +| --- | --- | --- | +| `BG` | Sensor / Geber (Eingang) | `BG0280`: in Separator LS1 | +| `SF` | Schalter / Taster / Sicherheitssignal (Eingang) | `SF0025`: Schluesselschalter LS1 | +| `DI` | Diagnose-/Feedback-Eingang (Sicherung, Schuetz) | `DI0011`: Feedback Hauptschuetze aktiv | +| `BP` | Druckschalter | `BP0004`: Druckschalter Druckluft OK | +| `MB` | Ausgang Separator-/Stopper-Ventil | `MB0280`: Separator LS1 | +| `MA` | Ausgang Motor (Contactor) | `MA0060`: Motor (ILS-KR-M0101) | +| `QA` | Ausgang Motor / Hauptschuetz | `QA0071`: Motor 1 Ausfahren LS1 | +| `DQ` | Digitalausgang Sonderfunktion (Fuss, RFID-Handshake) | `DQ0322`: Stuetzfuss aufwaerts LS1 | +| `FC` | Motorschutz-Feedback | `FC0060`: MSS ausgeloest (ILS-KR-M0101) | +| `PF` | Leuchtmelder / Signalsaeule | `PF0022`: Signalsaeule gruen "Betriebsbereit" | + +## Was daraus automatisch fuers JSON gewinnbar ist + +### Vollstaendig generierbar + +| JSON-Abschnitt / Zielbaustein | Quelle | +| --- | --- | +| `sensors[]` -> `FB_CallSensors`, Dimensionierung `DB_Inputs` | TIA "PLC Tags" (alle BG-Tags: id, hwInput, Kommentar) + "Constants" (`cInBG...` ist exakt der Sensor-Array-Index) | +| Konstanten-Tabelle (TIA-Konstantenliste) | Constants-Blatt 1:1 | +| PLC-Variablentabellen (Ordner `PLC-Variablen/Mewa`) | "PLC Tags" — das ist der eigentliche Importzweck der Datei | +| `outputs`-Felder der TROs/Conveyors/LoadingBooms | MB (Stopper/Separatorventile), MA/QA/DQ (Motoren), FC (Motorschutz), PF (Leuchtmelder) | + +### Teilweise generierbar — ueber Kommentar-Parsing + +Die Kommentare folgen einem erstaunlich systematischen Muster: + +```text + [] () +``` + +Beispiele: `in Separator 1 (ILS-CV M5003) WS1.1`, `AE Abzweig Str.3 (Block 1.1.1)`, `Pin Abfrage (KR-M1101) Block 1.1.1`. + +Daraus laesst sich je Foerdertechnik-Einheit (M-Nummer) ein **TRO-/Conveyor-Geruest** ableiten: + +- `sensorInSep` aus "in Separator n", Stopper-Output aus "Separator n", `sensorJam*` aus "Stausensor"/"Staumelder Einfahrt" +- Der **FB-Typ** ist heuristisch bestimmbar: + - "AE Abzweig" -> Weiche (`1SepNSwi`) + - "Mitnehmerfinger in Position" / "Foerderer voll" / "MT in Position" -> `Vario` + - "Pin Abfrage" / "Pruefung MT Pos.x" -> `PinStore` + - mehrere "Str.1"..."Str.8" unter einem Block -> mehrzeiliger Puffer/Block + - Anzahl der "in Separator n" (1 vs. 2) -> 1Sep vs. 2Sep +- `conveyors[]`-Grundgeruest: FC/MA-Paare je `KR-M...`/`CV-M...` -> `motorProtectName` + `powerContactor` + +Die M-Nummern tauchen unveraendert auch im SCL-Code auf (Beleg: `REGION Carousel KR-M5002` in UH05/FB_Main.scl, `TRO208 : "FB_ILS_MTRO_PinStore_Auto"; // Block 1.1.1` in UH02/FB_Main.scl) — die Zuordnung Liste <-> Code ist also nicht nur Vermutung, sondern nachweisbar identisch. + +### Nicht gewinnbar + +- Timing-Parameter (`trailingTime`, `handlingTime`, `senFree`/`senWait` etc.) +- Priority-Manager-Verdrahtung, Release-Ausdruecke +- `customCode`-Bloecke +- Scanner-Zuordnung (Cognex BX-Geraete sind PROFINET-Teilnehmer, nicht in den Digital-E/A-Listen) +- Vor allem die **Topologie**: `connections[]`, `jamAreas[]`, `routing`/`destinations[]`. Die Reihenfolge der M-Nummern liefert nur einen schwachen Hinweis auf Nachbarschaft, keine belastbare Verkettung. + +## Hoehere Ebenen in den Listen + +Die Listen enthalten eine durchgaengige **Anlagenhierarchie**, die im aktuellen JSON-Konzept noch nicht abgebildet ist: + +1. **Signal** — BG/MB/MA/FC/PF/SF/QA/DQ (unterste Ebene) +2. **Foerdertechnik-Einheit = M-Nummer** — `KR-M5002` (Kreisel), `CV-M5003` (Foerderer), `KR-K1101` (Kreisel-Einfahrt). Entspricht 1:1 einem Conveyor bzw. einer TRO-Instanz. +3. **Bereichs-/Funktionsgruppen = Gruppen von TROs**: + - **Block x.y.z** — PinStore-Bloecke, z.B. UH02: Block 1.1.1 – 1.3.4 (3 Gassen x 4 Ebenen = 12 Bloecke), deckungsgleich mit den Datenbausteinen `DB_Storage1.1.1` ... `DB_Storage1.3.4`; darunter je Block bis zu 8 Gassen ("Str.1"..."Str.8") + - **LS 1 / LS 2** — Ladeschleifen in UH01 (Boom-, Fuss-, Rad-Signale) + - **WS x.y** — Work Stations in UH04/UH05 (manuelle Arbeitsplaetze) + - **UZ0x0y** — Umzaeunungs-/Sicherheitszonen (Reset-/Freigabe-Taster je Zone) -> entspricht den `controlUnits` im JSON-Konzept +4. **Elektro-Topologie** (nur in den WSCAD-Listen, ueber das Feld "Bezug") — UC-Feldstationen mit Klemmenkarten (`KF1DI1`, `KF1FDQ2` = fehlersichere Karte, 8 oder 16 Kanaele). Die UC-Nummerierung spiegelt die logischen Bereiche: UH02 nutzt z.B. `UC21xx`/`UC22xx`/`UC23xx` fuer die drei PinStore-Bloecke 2.1/2.2/2.3; F-Karten markieren zugleich die Safety-relevanten Signale. +5. **Steuerung UH0x** — je Dateitripel eine SPS-Konfiguration, entspricht dem `plc`-Abschnitt im JSON. + +## Verwendung von Positionen + +Zusaetzlich zu den Excel-Listen liegen in `doc/Eingaben/` vier JSON-Dateien mit Positions- und Verkabelungsdaten, offenbar Exporte eines WSCAD/CAD-Auswertungstools: + +| Datei | Inhalt | +| --- | --- | +| `ST500592_10_5-9_ILS_positions.json` | Positionen (x/y in mm) aller Sensoren/Aktoren, Schaltschrankelemente und Verteiler des ILS-Systems (UH01–UH05) | +| `ST500592_10_5-9_ILS_todraw.json` | Kabelverbindungen (Verteiler ↔ Signal) mit Routing-Polylinie und -laenge, Kabeltrassen (`rack_geometry`), Fehlerprotokolle | +| `ST500592_Omniflo_positionsdraw.json` / `ST500592_10_5-10_Omniflo_todraw.json` | Gleiches Schema, aber fuer ein weiteres System ("Omniflo", `SPS` 6/7 = UH06/UH07) — **keine** SCL-Konfiguration dazu im Repository, also vermutlich eine benachbarte/zukuenftige Anlage ausserhalb des aktuellen Scopes | + +### Struktur + +- **`sensors`** / **`schaltschrank_elemente`**: Dict, Schluessel `@` (z.B. `BG3260@4`), da BMK-Namen ueber die SPSen hinweg wiederverwendet werden. Werte enthalten u.a. `pos` (x,y in mm), `BEZEICHNUNG` (Kommentartext, identisch zur TIA/EA-Liste), `KENNZEICHNUNG` (WSCAD-Ortskennzeichen), `SPS` und **`VERW`**. +- **`VERW`** ist ein kontrolliertes Vokabular fuer die Funktionsrolle des Signals, z.B. `Sep`, `In sep`, `Jam detector`, `ES branch` (Weichen-Abzweig!), `conveyor full`, `MT in Position`, `Finger in position`, `PIN query`, `Sync P1`–`P4`. Das ist eine **zuverlaessigere Quelle fuer die Rollenklassifikation** als das Parsen der freien Kommentartexte (siehe oben) — z.B. laesst sich eine Weiche (`ES branch`) oder ein Vario-Sync-Punkt (`Sync Px`) direkt am `VERW`-Wert erkennen statt ueber Text-Heuristik. +- **`mappings`**: Verteiler (`UC0401`, ...) -> Liste der daran angeschlossenen BMK — das ist die **belastbare** (aus der Verkabelung stammende) Zuordnung Signal -> Schaltschrank, nicht nur eine Namenskonvention wie in der WSCAD-Excelliste. +- **`distributors`**: Verteiler -> eigene Position (x,y). +- **`kabel`** (nur `_todraw.json`): je Verbindung `id` (`"-@"`), Routing-Polylinie (`coords`) und `length` (mm) — die tatsaechliche Kabelstrecke inkl. Verlegung ueber Kabeltrassen/Pritschen. +- **`rack_geometry`** / **`tunnels`**: Geometrie der Kabeltrassen bzw. Bodentunnel, auf denen die Kabel gefuehrt werden. +- **`not_found`** / `errors_*` / `warnings`: Validierungsprotokoll des Exporttools (fehlende Verteilerzuordnung, ungueltige Kennzeichnung, doppelte IDs, Attributsluecken) — kein Topologie-Input, aber wertvoll als **Datenqualitaets-Check** fuer einen Generator. + +### Lassen sich Topologie-Hinweise ableiten? + +Ein Abgleich der bekannten UH01-Kette (siehe [TRO_Graph_UH01-UH05.dot](TRO_Graph_UH01-UH05.dot)) gegen die Sensor-Positionen zeigt ein klares Muster: + +| TRO | Sensor | Position (x, y in mm) | Abstand zum vorherigen | +| --- | --- | --- | --- | +| TRO100 | BG3242@1 | (341906, 164862) | – | +| TRO103 | BG3271@1 | (331115, 163051) | ~10,9 m | +| TRO107 | BG3306@1 | (333164, 152428) | ~10,7 m (nach TRO105) | +| TRO104 | BG0280@1 | (370801, 187134) | ~46,4 m (Sprung!) | +| TRO105 | BG3280@1 | (334141, 159162) | ~46,1 m (Sprung zurueck!) | +| TRO109 | BG0340@1 | (376774, 187155) | liegt nahe bei TRO104 | + +Die TROs des Hauptkreislaufs (100, 103, 105, 107, ...) liegen raeumlich dicht beieinander (Abstaende im Bereich 5–15 m), waehrend TRO104/TRO109 (Vorstopper vor den Ladeschleifen LS1/LS2) einen grossen sprunghaften Abstand aufweisen — sie liegen physisch bei den Ladeschleifen, einem raeumlich getrennten Anlagenteil, zu dem die Carrier ausgeschleust und zurueckgefuehrt werden. Das deckt sich exakt mit der bereits aus dem SCL-Code extrahierten Topologie (TRO104 -> LoadingBoom1 -> TRO105). + +**Ergebnis:** Positionen liefern **keine eigenstaendige, vollstaendige Topologie** (dafuer fehlt die Information, in welcher Reihenfolge/Richtung Carrier durch nahe beieinanderliegende Elemente laufen — u.a. bei parallelen Foerderstrecken oder Bloecken mit identischen Abstaenden nicht eindeutig). Sie eignen sich aber sehr gut als: + +1. **Validierungswerkzeug** fuer die aus dem SCL-Code extrahierte `connections`-Topologie: kurze Abstaende zwischen verbundenen TROs bestaetigen Plausibilitaet, groessere Spruenge markieren bewusste Anlagenteile (Ladeschleifen, Storage-Gassen, AMR-Uebergabe) und lassen sich in der Analyse gezielt kommentieren. +2. **Raeumliche Clusterbildung**: TROs/Sensoren, die im selben Cluster von Koordinaten liegen, lassen sich automatisch zu den bereits identifizierten Bereichsgruppen (Block, LS, WS, UZ) buendeln oder solche Gruppen erst entdecken, falls die textuelle Kommentar-Zuordnung fehlt oder uneinheitlich ist. +3. **Massstabsgetreue Lageplan-Darstellung**: der bestehende TRO-Graph ([TRO_Graph_UH01-UH05.svg](TRO_Graph_UH01-UH05.svg)) nutzt eine automatische Graphviz-Anordnung ohne Bezug zur echten Anlage. Mit den `pos`-Koordinaten liesse sich zusaetzlich ein **massstabsgetreuer Lageplan** rendern (SVG/DXF mit echten x/y-Koordinaten je TRO/Sensor), der die abstrakte Topologie mit der realen Hallenlayout ueberlagert. +4. **Cabinet-/Verteilerzuordnung**: `mappings` + `distributors` liefern die **tatsaechliche** (aus der Verkabelung stammende) Zuordnung Sensor -> Schaltschrank/Verteiler samt dessen Position — praeziser als die Namenskonvention der WSCAD-Bezugsfelder, und direkt nutzbar fuer den `controlUnits`-Abschnitt im JSON. +5. **Kabel-/Trassendokumentation**: `kabel`, `rack_geometry` und `tunnels` erlauben es, Kabellaengen und -wege je Verbindung automatisch zu dokumentieren (z.B. fuer Stuecklisten/BOM oder Trassenauslastung) — fachlich getrennt von der SPS-Programmlogik, aber ein sinnvoller Zusatznutzen derselben Datenbasis. + +## Konsequenz fuer das JSON-Layout-Konzept + +Um Ebene 2–4 aus den Excel-Listen automatisch befuellen zu koennen, sollte das JSON-Schema (siehe [Json_Layout-Konzept.md](Json_Layout-Konzept.md)) um folgende Punkte erweitert werden: + +1. Ein Feld `unit` bzw. `mNumber` an jedem TRO/Conveyor als expliziter Schluessel zur E/A-Liste (z.B. `"unit": "M5003"`). +2. Eine neue Gruppierungsebene `areas`/`groups` (Block, LS, WS, UZ, UC-Station), die TROs/Conveyors buendelt und mit dem "Bezug"-Feld der WSCAD-Liste sowie der UZ-Nummerierung der TIA-Liste verknuepft. +3. Ein optionales Feld `pos: {x, y}` je Sensor/TRO/Conveyor (aus den `..._positions.json`), fuer massstabsgetreue Layout-Darstellung und als Validierungsdatum fuer die Topologie. +4. Ein Feld `controlUnit`/`cabinet` mit dem Verteiler-BMK (aus `mappings`), zusaetzlich zur bzw. anstelle der bisherigen Ableitung aus der WSCAD-Namenskonvention. +5. Nutzung des `VERW`-Vokabulars aus den Positions-JSONs als primaere Quelle fuer die Rollenklassifikation der BG/MB-Signale (statt bzw. ergaenzend zur Kommentar-Textheuristik) — reduziert Fehlklassifikationen bei uneindeutigen Kommentaren. + +Damit waeren die Ebenen Signal, Foerdertechnik-Einheit, Bereichsgruppe, Steuerung und — als Zusatznutzen — die raeumliche Lage vollstaendig aus den Eingabelisten ableitbar. Manuell zu pflegen blieben dann nur noch die eigentliche Verkettungsrichtung der Topologie (`connections`/`destinations`), Timings und projektspezifische Sonderlogik (`customCode`).