- _weichen_aus_umlauf: ein Separator, auf den in Laufrichtung ein Ausschleuselement folgt (ohne Separator dazwischen), ist dessen Weiche - auch ohne CSV-Nachbarschaft (Dematic 0043 -> VF_5, Nachbarn nur Einschleuselemente); Speicherlinien ausgenommen
- Schritt 3b': weitere Ausschleuselemente bis zum naechsten Separator gehoeren zum selben Separator, zwei -> 1Sep2Swi (Dematic 0048 -> VF_4 + VF_6), Finding bei fehlendem Scanner bzw. mehr als zwei Weichen
- Weichenkante je Host; Weichen-TRO ohne Bahn-Nachfolger (einziger Separator seines Kreisels) zaehlt als praezise Quelle - entfernt die Contraction-Walk-Kanten an VF_4/VF_5/VF_6 vorbei
- keine gestrichelte "gleiche Bahn"-Notiz an Weichen-TROs (Host ist die Strecke, in die sie abzweigen, nicht ihre Bahn)
- HundM05 (28 Kanten) und Mubea (26) inhaltlich unveraendert, --use-cords-Ausgabe byte-identisch
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
material_flow.svg: der UZS/GUZ-Pfeil zwischen Bahn R/L eines Kreisels wird nach
dem Graphviz-Rendern durch einen 270-Grad-Kreispfeil mit dem Kuerzel in der
Mitte ersetzt (Graphviz kennt keine kreisfoermigen Pfeile/Labels).
Weiche zwischen zwei Kreiseln: neue _kreisel_touch_lane() bestimmt per
Boundingbox (Stadion-Form) und Weiche-Position geometrisch, ob der
Beruehrpunkt an einer Stirnseite oder an der Laengsseite jedes beteiligten
Kreisels liegt. Nur am reinen Stirnseiten-Treffer (Kreis/Kreis) ist der
Bahnwechsel L<->R eindeutig und wird weiterhin per Drehrichtung gerichtet
gezeichnet; an einer Laengsseite (Kreis/Gerade) kommt die betroffene Bahn
direkt aus der Geometrie, die Richtung bleibt aber unbestimmt, da sie vom
(unbekannten) Schaltzustand der Weiche abhaengt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- _speicher_bloecke: Schwerkraftlinien nach Umlaufreihenfolge in Bloecke schneiden (Separator dazwischen = neuer Block); der Weichen-Separator vor dem Block ist Steuer-Separator des PinStore_Auto statt eigener 1Sep1Swi (Dematic: 3 Speicher 10/7/10 statt einem mit 27)
- Umlauf schliessen bis zum ersten Element mit TRO, nicht nur ueber Stationen hinweg (Dematic Kreisel2 beginnt mit Einschleuselement: TRO01 -> Speicher fehlte; Mubea TRO06 -> TRO10 statt Fallback TRO06 -> TRO18)
- _weichen_nach_umlauf: Separator steuert ein Ausschleuselement nur als letzter Separator davor in Laufrichtung (Dematic 0047/0046 waren ueber den Ring-Schluss bzw. hinter dem Block "benachbart")
- _kreisel_bahn: Kreisel-Separator mit Gefaellestrecke als Zuordnung auf die Kreisel-Bahn haengen (Dematic 0046 zaehlte als Speicherlinie)
- HundM05 unveraendert, Mubea 26 Kanten (eine korrigiert)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TROs, Typen und Verbindungen kommen nur noch aus dem Layout. Fehler der
Ableitung werden im Code behoben, nicht in einer Korrekturdatei.
- tro_flow: Optionen --use-overrides/--no-overrides, --from-connect,
--geometry, --geo-tol-mm entfernt; analyse_tros/derive_tros ohne
overrides/resolve_host/count_exits-Parameter, Analysis.overrides entfernt,
Override-Schritte 4b/4c/5b, Doku-Abschnitt "6. Manuelle Korrekturen" und
die Override-Zeilen im Bericht entfernt; connect.ini ist reine Ausgabe
- lib/tro_geometry.py geloescht (nur von --geometry genutzt), shapely aus
requirements.txt
- tro_overrides: apply_splits/_merges/_connections/_overrides und
load_connect_ini entfernt - nur noch load_overrides fuer
material_flow.py --connect
- doc/Python_Scripts.md nachgezogen
Gegenprobe: DOT (beide Layouts) und connect.ini fuer HundM05 und Mubea
unveraendert (28 bzw. 26 Verbindungen), Doku nur ohne den leeren
Abschnitt 6.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- --max-residual: feste Grenze DEFAULT_MAX_RESIDUAL (600 mm), Meldung
verweist auf --offset
- --layer-prefix: Layer immer mit Praefix TRO_
- --use-overrides: cfg/tro_overrides.ini wird nie gelesen, Marker passen
damit immer zum TRO-Fluss
- damit toter Code entfernt: draw_open_points, Layer TRO_OPENPOINT,
Berichtszeilen Offene Punkte/Typkorrekturen (Daten kamen nur aus der INI)
- --emit-lisp bleibt (einziger Weg, tro_types.lsp fuer TRO_INSERT/TRO_EDIT
nach einem neuen Katalogtyp neu zu schreiben)
- doc/Python_Scripts.md nachgezogen
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
scl_skeleton.py brach mit KeyError ab, sobald der TRO-Fluss Stationen
(SYSn) enthielt. Stationen bekommen jetzt keine REGION/Instanz, der von
einer Station gespeiste TRO ist der Anfang der Reihenfolge, in den
Staubereich-Kommentaren sind sie als Station markiert.
tro_annotate.py liess Verbindungen unter 2,2 Markergroessen still weg
(HundM05 TRO03->TRO04, 500 mm) - sie fehlten dann in tro_extract.py und
in der SCL. Kurze Verbindungen werden jetzt Mitte-zu-Mitte gezeichnet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tro_flow:
- _station_positionen: Richtung des Zu-/Ablaufpfeils mit groesstem
Winkelabstand zu allen Kanten des Anker-TROs und zu bereits gesetzten
Stationspfeilen (15-Grad-Raster), echte Stationsrichtung nur bei
Gleichstand - vorher lag z. B. Mubea TRO02 -> SYS2 fast auf TRO02 -> TRO13
tro_annotate:
- Symbole mit typ-eigener Fuellfarbe (Solid-Hatch) unter der Gruppenkontur
- Kantenfarben/-layer wie im SVG: Uebergabe blau, Weiche orange,
Materialeingang gruen, Materialausgang rot (TRO_WEICHE/_EINGANG/_AUSGANG)
- Stationen als farbige Beschriftung am Pfeilende, Lage ueber
tro_flow._station_positionen (ohne CONNECTION_ARROW-Block)
- Legende wie im SVG: je vorkommendem Typ Fuellung/Rand/Form, dann Kantenfarben
- CONNECTION_ARROW: FROM_TRO/TO_TRO unsichtbar (Daten bleiben), KIND auch weiche
cfg/dxf_registration.json: mubea.csv|mubea.dxf und HundM05.csv|HundM05.dxf
mit Versatz 0 (CSV aus derselben dxfmakros-Zeichnung; Auto-Ermittlung sieht
die verschachtelten Separatoren nicht und war mehrdeutig);
mubea.csv|500573_60_1.dxf neu ermittelt (36/46 Punkte).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- link_tros: Systemgrenzen (Be-/Entladung, Eingang/Ausgang) sind kein
Kettenglied mehr - die Umlaufkette verbindet die TROs direkt an ihnen
vorbei. Entladung/Ausgang haengt am TRO direkt davor, Beladung/Eingang
am TRO direkt danach. HundM05: TRO19 -> TRO20, SYS1/SYS2 -> TRO20,
TRO19 -> SYS3. Mubea: TRO02 -> TRO13, TRO04 -> TRO03, TRO02 -> SYS2/SYS3,
SYS1 -> TRO03.
- Umlauf schliessen ueber Stationen am Listenanfang hinweg (HundM05 Kreisel1
beginnt mit den Beladungen, sonst fehlte TRO19 -> TRO20)
- render_dot: Station als farbige Beschriftung am Ende eines Pfeils (gruen
Eingang, rot Ausgang) statt Ellipse, Legende entsprechend; lagerichtig
feste Pfeillaenge ab dem angehaengten TRO, mehrere Stationen am selben TRO
aufgefaechert (_station_positionen ersetzt _anzeige_position)
- HundM05 28 Verbindungen, Mubea 26
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Je Achse bleiben Reihenfolge und echte Abstaende der Knoten bis
COORD_MAX_LUECKE (1500 mm) erhalten, groessere Leerstrecken (lange Foerderer
ohne TRO) werden darauf gekuerzt (_achse_kompakt/_kompakte_positionen,
_zeichen_positionen). Legende naeher an der Anlage. Reine Darstellung:
Knoten, Kanten, Labels und Tooltips (mit echten Koordinaten) unveraendert -
DOT ohne pos-Attribute fuer HundM05 und Mubea identisch. Mubea 2929x3333 ->
2212x2411 px. --true-scale zeichnet weiterhin masstaeblich.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Ausschleuselemente der Speicherlinien zaehlen in der Umlaufkette als
Glied des PinStore-TROs, die Einschleuselemente liefern - wie bei einer
Vario-Strecke - den Ablauf zum naechsten Halt. Ersetzt die Regel
"letzter Halt vor dem Speicher speist ihn" aus f9c9d88.
Mubea Kreisel3: TRO05 -> TRO18 -> TRO07 (keine direkte Kante TRO05 -> TRO07
mehr, TRO05 bleibt 1Sep - kein ILS Ausschleuselement einer Strecke),
TRO12 (VF_2 muendet direkt vor den Speicherlinien) -> TRO18,
TRO18 -> TRO10 jetzt aus den Einschleuselementen auf Kreisel2.
Im Review 2026-10-01 bestaetigt. HundM05 unveraendert (28), Mubea 26.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- _add_chain_pair: Be- und Entladestationen sind in der Umlaufkette
gewoehnliche Glieder - der Kreisel laeuft immer weiter. HundM05 Kreisel1:
TRO19 -> SYS3 -> SYS1 -> SYS2 -> TRO20 (vorher endete der Fluss an SYS3).
Mubea: TRO04 -> SYS1 statt der groben Fehlkante TRO04 -> TRO18.
- link_tros: der letzte Halt vor dem ersten Ausschleuselement einer
Speicherlinie speist den PinStore-TRO (Mubea Kreisel3: TRO05 -> TRO18)
- HundM05 28 Verbindungen, Mubea 26
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lagerichtig liegen TROs derselben Bahn/Strecke ohnehin sichtbar
nebeneinander - die Punktlinien waren dort nur Unruhe. Gezeichnet werden
nur noch echte Verbindungen (HundM05 27, Mubea 25). Die berechnete
Anordnung ohne --use-cords behaelt Linien und Legendenzeile.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- link_tros/_add_chain_pair: eine Materialausgang-Systemgrenze darf in der
Kreisel-Umlaufkette Quelle sein - was nicht entladen wird, faehrt weiter.
Mubea Kreisel2: TRO02 -> SYS3 -> SYS2 -> TRO13 (vorher endete der Fluss an
SYS3, TRO13 hatte keinen Vorgaenger). Beladung bleibt reine Quelle.
- Legende: Zeile "blau gestrichelt - Kreisel-Umlauf" entfernt
- HundM05 unveraendert (27 Verbindungen), Mubea 25 Verbindungen
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- _find_weiche_separators: ILS Weiche (TeileArt) ist ein echtes Weichen-
Bauteil -> 1Sep1Swi; steuernder Separator = CSV-Nachbar mit Scanner
(Mubea 0125 -> 0036), mehrdeutig -> Finding statt Raten
- _find_switch_separators: Separator mit Zuordnung auf eine Strecke, der in
der TrackIds-Kette eines Kreisels steht, gilt als Kreisel-Separator
(Mubea 0005 vor Ausschleuselement 0057)
- derive_tros 3d: Ausschleuselement-Weiche und ILS Weiche direkt
hintereinander in der TrackIds-Kette -> ein 2Sep2Swi (Mubea TRO10:
Sep 0005/0036, Scan 0006/0041); FB_ILS_MTRO_2Sep2Swi fehlt noch in der ILSLib
- --use-cords: feste Symbolgroesse je Form, nur TRO-Nummer im Symbol,
Typ/Separator als xlabel, Details als Tooltip, Massstab 0.1 statt 0.25 pt/mm,
Legende rechts mit nur den vorkommenden Typen, blasse Linien fuer
gleiche Bahn, Systemgrenzen dicht an einem TRO werden in der Zeichnung
beiseitegeschoben
- HundM05 unveraendert (27 Verbindungen), Mubea 18 TROs / 23 Verbindungen
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- tro_flow/tro_annotate: cfg/tro_overrides.ini nur noch mit --use-overrides
(die Abschnitte haengen an laufenden TRO-Nummern und am CSV-Namen und
veralten mit jedem Export; [export.csv.connections] ersetzte alle
abgeleiteten Kanten und liess TRO13-20 unverbunden)
- link_tros: Separatoren mit Zuordnung auf eine Strecke, die in keiner
TrackIds-Liste stehen, per Projektion AS->ES in die Strecken-Kette
einsortieren (Mubea VF_3: 0037/0038 erzeugten je 9 Fehlkanten;
mubea 38 -> 22 Verbindungen, HundM05 unveraendert)
- tro_catalog: typ-eigene Fuellfarbe je TRO-Typ, Mermaid-classDefs je Typ
- tro_overrides/tro_flow: connect.ini zurueck einlesen (--from-connect)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- neuer Wert fuer --show-bbs: 'flow' (Default, auch ohne Wert) blendet
die VF/GF-Einzelbausteine (Bogen, Streckenelement, Motor-/Umlenkstation)
aus, 'all' zeichnet jede CSV-Zeile
- eigene Farben fuer die Einzelbausteine, Legende mit Anzahl je Objektart,
Tooltip je Rechteck (Zeile, TeileId, TeileArt, Bezeichnung)
- genutzt von dxfmakros/bin/show_exportcsv.bat
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
_find_switch_separators() ermittelt Weichen-Separatoren jetzt topologisch
(Ausschleuselement unter den CSV-Nachbarn, gleiche Kreisel-Bahn) statt ueber
eine Distanzschwelle - die Fallback-Schwelle paarte an Mubea unbeteiligte
Separatoren faelschlich mit dem naechsten freien Ausschleuselement, u.a. 20
PinStore_Auto-Speicherlinien wurden so faelschlich als 1Sep1Swi erkannt.
Materialfluss: _sole_kreisel_neighbour() als Fallback in _apply_transfers()
fuer AS/ES-Elemente ohne eigenes Merkmal "Kreisel" (Mubea), aufloesbar wenn
die Strecke genau einen Kreisel-Nachbarn hat.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bisher wurde auf einer Streckengruppe nur der jeweils letzte Separator (in
TrackIds-Reihenfolge) auf 1Sep umgestuft, alle davor blieben pauschal Vario.
Eine Streckengruppe ist baulich aber meist eine alternierende VF/GF-Kette
(angetriebener Abschnitt, Vereinzeler, unbetriebener Abschnitt, Vereinzeler,
...), nicht nur am Ende - fuer 2 Separatoren macht das keinen Unterschied,
ab 3 schon. Die Umstufung laeuft jetzt vom letzten Separator rueckwaerts und
alterniert: letzter = 1Sep, davor Vario, davor wieder 1Sep usw.
Bestaetigt an HundM05 VF_1 (4 Separatoren): der neue Positions-Nachweis stuft
den dritten von hinten (0035) unabhaengig auf 1Sep ein - deckungsgleich mit
dem bereits vorhandenen (aber als moeglicherweise unkorrigierte CAD-Vorgabe
mit Vorbehalt behafteten) Hoehen-/Antriebsnachweis (_incoming_drop). Der
Hoehen-/Antriebsnachweis bleibt als unabhaengige Zusatzpruefung erhalten und
kann eine laut Muster erwartete Vario-Position auf 1Sep umstufen, wenn dort
tatsaechlich ein unbetriebenes Gefaelle gemessen wird - nicht umgekehrt.
TRO-Typenzahl auf beiden Referenzanlagen (HundM05, Mubea) unveraendert,
nur die Finding-Texte wurden praeziser.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Optional: findet tro_flow.py neben der CSV ein <stamm>_raw.json (dxfmakros-
Rohattribute), vergleicht es je Strecke/Gefaellestrecke-Host die aus der CSV
abgeleitete Separatorenzahl mit der Anzahl 'SEP'-Eintraege in dessen eigener
'sepliste' und meldet Abweichungen als Finding - ohne TRO-Daten zu aendern,
die CSV bleibt die massgebliche Quelle. Faengt an HundM05 sofort einen
echten Fall: VF_5 hat laut CSV 3 zugeordnete Separatoren, sepliste nennt nur
2 - passt zum bereits gemeldeten Separator 0018 ohne TrackIds-Mitgliedschaft.
Bewusst NICHT verwendet: die sepliste-Koordinaten (der jeweils erste
SEP-Eintrag jedes VF-Blocks traegt durchgehend eine kaputte Position, ein
Bug im DXF-Export) und das Attribut "ANZAHL_SEPARATOR" (weicht in beiden
bisher geprueften Anlagen von TrackIds UND sepliste ab, vermutlich veraltet/
doppelt gezaehlt). Fehlt die Roh-JSON-Datei, entfaellt die Gegenprobe
stillschweigend; ist sie vorhanden aber kaputt (z. B. unvollstaendig
geschrieben), gibt es eine Warnung statt eines Abbruchs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ein per Zuordnung einer Streckengruppe zugeordneter Separator, der nicht Teil
von deren eigener TrackIds-Kette ist, wird direkt als 1Sep eingestuft statt
ueber die Vario/letzter-Separator-Logik zu laufen - vor Ort bei Mubea
VF_1-VF_3 bestaetigt: jede Streckengruppe hat genau einen echten
Kettenseparator, alle weiteren Zuordnung-Treffer sind eigenstaendige
Vereinzeler ohne eigenes VF-Teilstueck. Damit ein solcher Separator nicht
zugleich faelschlich als Weichen-Indiz zaehlt (engster Treffer ueberhaupt bei
Mubea 0005, 163mm), werden echte VF-Kettenmitglieder vor der
Weichenerkennung (_find_switch_separators) ausgenommen - Naehe zum eigenen
Aus-/Einschleuselement ist bei ihnen der normale, erwartete Aufbau, kein
Weichenbeleg.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
_find_switch_separators: Regel 2 (naechster freier Separator <= 1500mm) lief
bisher nur auf einer Bahn, die Regel 1 (<=500mm) schon bestaetigt hatte. Bei
HundM05 lagen nach einer CAD-Aktualisierung alle 5 echten Weichen-Separatoren
gleichmaessig bei ca. 1013-1016mm - ausserhalb von Regel 1, wodurch die
Bahn-Sperre fuer jede Bahn zublieb und keine einzige Weiche mehr erkannt
wurde. Die Sperre entfaellt; SWITCH_FALLBACK_MM bleibt die alleinige Schranke
gegen Fehlzuordnungen (der eigentliche Schutz vor dem urspruenglichen
Mubea-Fehlfund, der 5-9m entfernte Separatoren betraf).
derive_tros, angetriebene Strecken (Schritt 2): zwei Faelle stufen einen
Separator trotz Host "Strecke" als 1Sep statt Vario ein:
- Letzter Separator vor dem Wiedereinschleusen auf die Kreisel-Bahn (in
TrackIds-Reihenfolge) - reiner Vereinzeler ohne eigene VarioDrive-Strecke,
die Kreisel-Bahn treibt ab dort selbst an (HundM05 VF_3 vor Ort bestaetigt).
- Ein nicht-letzter Separator, dessen vorangehendes Segment "horizontal"
(keine aktive Antriebsrichtung) gefuehrt wird, dabei aber tatsaechlich an
Hoehe verliert (> 30mm) - ein unbetriebenes Gefaelle-Teilstueck innerhalb
einer gemischten VF/GF-Streckengruppe (HundM05 VF_1/0035).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
BTMT Beladung/Entladung bzw. die generischen Eingang/Ausgang-Symbole waren
bislang von --chain-graph ausgenommen und wurden als Kantenziel einfach
uebersprungen. Die Anlage laeuft als Kreislauf, diese Stationen sind ihre
einzigen Materialquellen/-senken und gehoeren als eigene Knoten in jeden
Graphtyp (coarsebox/compound/subgraph).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
--chain-graph zeichnete bisher immer nur die groben Objekte (Kreisel-Bahnen,
Strecke/Gefaellestrecke). Neuer Schalter --graphtype waehlt die Methode:
coarsebox (bisheriges Verhalten, unveraendert), compound (dieselbe
massstabsgetreue SVG, zusaetzlich die Anbauteile - Separator, Scanner,
Ausschleus-/Einschleuselement, Weiche - verschachtelt im Container an ihrer
echten Position, verbunden ueber die bereits aufgeloesten TrackGraph-Kanten)
und subgraph (dieselbe Verschachtelung als geschachtelte Graphviz-Cluster,
schematisch statt lagerichtig, <name>_chain.dot / mit --tosvg auch .svg).
_container_children() liest die Anbauteile direkt aus Element.track_ids -
derselben Quelle, die build_track_graph()/--track schon nutzt - statt sie wie
im Prototyp data/gen_chain_svg.py erneut aus der Nachbarn-Spalte herzuleiten.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Seit der Weichenerkennung (c788647/fa96a6e) bekommt ein Weichen-TRO als Host
die gefuetterte Strecke statt die Kreisel-Bahn (derive_tros Schritt 3b) - fachlich
richtig fuer den Materialfluss, aber die Positions-Verkettung in link_tros()
gruppierte bisher rein nach Host: sobald nur noch ein einzelner "echter"
Separator auf einer Bahn uebrig blieb (HundM05 Kreisel1 Bahn L: 0020, nachdem
0008/0010/0012/0014 eigene Weichen-TROs wurden), verschwand die Reihenfolge
0008->0010->0012->0014->0020 komplett - im TRO-Flussdiagramm sah es aus, als
haenge jede der 5 Abzweigungen direkt und gleichrangig an genau diesem einen
TRO (Review 2026-09-21: "es gibt viele unnoetige Linien").
_tro_bahn() bestimmt die Kreisel-Bahn eines TROs jetzt zusaetzlich ueber die
Zuordnung seines eigenen Separators, wenn der TRO-Host selbst keine Bahn ist -
link_tros() verkettet danach alle TROs derselben Bahn per Position, nicht nur
die mit identischem Host. Die bestehenden Materialfluss-Kanten (Weiche/Vario
-> Ruecklauf-Bahn) bleiben unveraendert bestehen; die Verkettung ergaenzt nur
die bislang fehlende Reihenfolge der Abzweige.
Die Colocated-Markierung ("gleiche Bahn", gepunktete Linie) wird jetzt pro
Paar statt pro TRO unterdrueckt (verkettete_paare statt verkettet als TRO-Id-
Menge) - sonst waere z. B. TRO01 (Weiche, auf der Bahn verkettet) faelschlich
auch von seiner Colocated-Markierung mit TRO02 (Vario, gleiche Strecke)
ausgenommen worden, obwohl das zwei unabhaengige Beziehungen sind.
HundM05.csv: 24 -> 28 Kanten (4 neue Bahn-Kanten 0008->0010->0012->0014->0020).
Mubea unveraendert (13 TROs, 55 Kanten), keine Fehler in beiden Projekten.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Zwei Korrekturen zu c788647, beide durch Review gefunden (HundM05):
1. Ein Einschleuselement (Wiedereinschleusen in den Kreisel) ist keine
Weiche - das ist ein passiver Merge ohne Richtungsentscheidung, nur das
Ausschleusen (Verlassen der Bahn) legt die Fahrtrichtung fest.
_find_switch_separators() beruecksichtigt jetzt ausschliesslich
Ausschleuselemente; ein Separator an einem Einschleuselement (z. B.
HundM05 Separator 0018) wird nicht mehr als eigener 1Sep1Swi
herausgeloest, sondern zaehlt normal zum Vario-TRO seines Streckensegments.
HundM05.csv: 6 -> 5 automatisch erkannte Weichen (deckt sich jetzt mit den
5 Ausschleuselementen im Layout).
2. Beim Pruefen an Mubea (500573) fiel auf, dass Regel 2 (naechster freier
Separator, bisher ohne Obergrenze) dort mehrere Separatoren dem naechsten
noch freien Ausschleus-/Einschleuselement zugeordnet hatte, obwohl das
3.5-9m entfernt lag - eindeutig keine Weiche. Neue Konstante
SWITCH_FALLBACK_MM (1500mm) begrenzt Regel 2: grosszuegig genug fuer die
bei HundM05 beobachtete Kalibrierungs-Drift (bis 1139mm), zu eng fuer
Mubeas Fehlzuordnungen. mubea.csv: 9 -> 4 automatisch erkannte Weichen
(die beiden bestaetigten Handkorrekturen in tro_overrides.ini bleiben
unveraendert).
Beide Projekte weiterhin ohne Fehler, keine nicht verbundenen TROs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Korrektur zu 72d0a21: Regel 2 in _find_switch_separators() pruefte bisher,
ob ein Separator einen eigenen Scanner traegt, bevor sie ihn (ohne feste
mm-Grenze) einem Aus-/Einschleuselement zuordnete. Der Scanner ist aber nur
ein zusaetzliches Bauteil des TROs, kein Kennzeichen einer Weiche - viele
Separatoren tragen einen Scanner, ohne eine Weiche zu sein (siehe Docstring
und Hinweis in tro_flow.py selbst: "Ein Scanner am Separator aendert den Typ
NICHT").
Regel 2 ist jetzt reine naechster-freier-Nachbar-Zuordnung: jedes noch
unbelegte Aus-/Einschleuselement bekommt den naechstgelegenen freien
Separator derselben Rolle/Bahn, kleinste Distanz zuerst, jedes Paar nur
einmal - ohne Scanner-Kriterium und ohne feste mm-Grenze. Ein gewoehnlicher
Zwischenseparator ohne eigenes Uebergabeelement bleibt dadurch weiterhin
unbelegt, weil ihm kein Element mehr uebrig bleibt.
Ergebnis fuer HundM05.csv unveraendert (13 TROs, 6x 1Sep1Swi, keine Fehler) -
mit der zwischenzeitlich aktualisierten CSV liegen die echten Weichen jetzt
ohnehin wieder innerhalb der 500mm-Grenze aus Regel 1; Regel 2 bleibt als
Absicherung gegen erneute Kalibrierungs-Drift bestehen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
lib/tro_catalog.py: dot_shape_attrs()/SYMBOL_LABELS geben render_dot() eine
Graphviz-Form je TroSymbol (bisher nur fuer den CAD-Marker in tro_annotate.py
genutzt) - Farbe gruppiert weiterhin verwandte Typen, Form unterscheidet den
einzelnen Typ. Legende und Doku-Tabellen zeigen jetzt jeden Katalogtyp mit
Farbe+Symbol statt nur die 6 Farbgruppen.
lib/tro_flow.py: _find_switch_separators() bekommt einen zweiten Durchlauf,
der einen Separator mit eigenem Scanner (CAD-Merkmal "Naechster Separator")
als Weiche erkennt, wenn die reine Abstandsregel (SWITCH_PROXIMITY_MM) ihn
verfehlt - Rolle (Aus-/Einschleusung) wird aus einem bereits bestaetigten
Treffer auf derselben Kreisel-Bahn gelesen, keine neue feste mm-Schwelle.
Grund: bei HundM05 (5 Abzweige an einem Kreisel) lagen 3 der 5 echten
Weichen-Separatoren 727-1139mm von ihrem Ausschleuselement entfernt - ausserhalb
der auf einer aelteren Revision kalibrierten 500mm-Grenze - und wurden bisher
faelschlich als einfacher 1Sep statt 1Sep1Swi eingestuft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Python_Scripts.md war auf dem Stand von acht Modulen. Ergaenzt:
- neue Bibliothek lib/tro_geometry.py (STRtree-basierte Ableitung von
Separator-Host und Weichen-Fanout aus den Bauteil-Weltkoordinaten) als
eigenen Abschnitt 6b
- Schalter --geometry / --geo-tol-mm in der tro_flow.py-Tabelle
- shapely>=2.1 in der Paket-Uebersicht
- Kopf auf neun Module / vier Bibliotheken aktualisiert
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
--chain-graph zeichnet einen massstabsgetreuen Chain-/Lageplan der groben
Objekte (Kreisel-Bahnhaelften, Strecke/Gefaellestrecke) als <name>_chain.svg,
ohne Graphviz. BTMT-Stationen werden jetzt auch an "Eingang"/"Ausgang" statt
nur "Beladung"/"Entladung" erkannt und bevorzugt ueber TrackIds statt Nachbarn
verbunden. tro_flow.py erkennt bei Aus-/Einschleuselementen jetzt auch
"Foerderer" als Merkmal-Schreibweise fuer die Strecke, nicht nur "Strecke".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- _apply_transfers liest die andockende Strecke auch aus dem Merkmal
"Foerderer"/"Förderer" (nicht nur "Strecke"), damit VF/GF gerichtet
Kreisel->AS->..->ES->Kreisel gezeichnet werden (Ruecklauf = zwei Pfeile
auf die beiden Kreisel-Bahnen) statt "unbestimmt".
- _attach_stations haengt BTMT/Eingang/Ausgang an die Kreisel-Bahn, in
deren TrackIds-Umlauf sie liegen (Bahn aus der Drehrichtung); Nachbarn,
die keine Flussobjekte sind, werden uebersprungen - keine
Station<->Station-Kanten mehr.
- Eingang/Ausgang sind die generischen Symbole fuer Beladung/Entladung.
Liegt ein Symbol deckungsgleich (<= STATION_MERGE_MM = 600 mm) ueber
einer BTMT-Station gleicher Rolle, wird es verschluckt
(_merge_station_symbols) - nur ein Knoten, in grobem Graph UND --track
(dort auch aus den TrackIds gestrichen). Einzelne Symbole bleiben eigener
gruener/roter Knoten.
- drive_uphill: die Hoehe bestimmt die Richtung NUR bei einer reinen
Gefaellestrecke (Schwerkraft, bergab). Ein Foerderer/gemischte Strecke
kann hoch oder runter foerdern - dort zaehlt nur eine eindeutige
Antriebfahrtrichtung, sonst kommt die Richtung aus AS/ES.
Doku in doc/Python_Scripts.md und doc/track.md nachgezogen.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
build_track_graph baut die Fein-Adjazenz jetzt direkt aus der geordneten
TrackIds-Spalte je Container (Element.track_ids): Kreisel als zirkulaerer
Umlauf in Drehrichtung (Export-Sortierung), Strecke/Gefaelle als lineare
Kette AS -> SEP.. -> ES. Gemeinsame AS/ES-/Weiche-Knoten verketten die
Container automatisch - die Rueckmeldungs-/Rollen-Heuristik aus der
Nachbarn-Spalte (_transfer_kreisel_lane, _wire_weiche,
_orient_separator_links) entfaellt komplett.
_attach_track_symbols misst offene Bahnenden jetzt am feinen Graphen statt
am groben; das behebt die vereinzelten Falsch-Eingaenge an voll verketteten
Bahnen (HundM05: Bahn 0001-0004, 0006-R).
Doku in doc/Python_Scripts.md und doc/track.md nachgezogen.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
setenv.bat (and activate_venv/get_cmd/install_py.bat) had a UTF-8 BOM,
which cmd.exe read as part of the @echo off line, breaking every bin
script that calls setenv.bat via `call`. Stripped the BOM.
material_flow.bat/.sh and tro_flow.bat/.sh now check up front whether
the Graphviz engine --tosvg needs (dot, or neato with --use-cords) is
resolvable, and print an early WARNUNG with fix instructions if not -
before the CSV is even parsed. The Python scripts still run and report
the same failure in detail if the SVG step is actually reached.
A bank of gravity lanes between the same two Kreisel (same slope) was
drawn as one box per lane, making large storage banks unreadable.
render_dot now collapses such lanes into a single Gefaellestrecke-styled
block with a double border, labelled with the id range and combined
Separator/Scanner ranges. Purely visual - the graph, --doc report and
--connect output still list every lane individually.
lib/scl_skeleton.py and lib/tro_extract.py already run the pipeline
end-to-end (annotated DXF -> TRO-JSON -> FB_Main SCL skeleton), but
CLAUDE.md and README.md still described these as unwritten tools
(tro_export.py / scl_gen.py). Update the current-state docs:
- CLAUDE.md: project purpose, reading order, roadmap section, and
standard-template notes now describe the built pipeline plus the
parts still open (full layout JSON schema, other per-controller
blocks, timing defaults, --skip-json).
- README.md: bin/ tree and usage examples for tro_extract/scl_skeleton.
- doc/Python_Scripts.md: intro counts (8 modules / 5 CLI tools),
header date, pipeline diagram, and tro_overrides.py in the lib list.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a Roadmap section to README.md and CLAUDE.md describing the two
still-to-be-written lib/ tools (tro_export.py, scl_gen.py) that will
turn the annotated CAD drawing into a JSON layout model and then into
TIA-Portal-importable SCL, including the --skip-json shortcut.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
