Ergänzte Doku
This commit is contained in:
@@ -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<Name>`-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
|
||||
<Funktionsrolle> [<lfd.Nr.>] (<Einheit>) <Bereich>
|
||||
```
|
||||
|
||||
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 `<BMK>@<SPS>` (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` (`"<Verteiler>-<BMK>@<SPS>"`), 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`).
|
||||
Reference in New Issue
Block a user