Commit Graph

139 Commits

Author SHA1 Message Date
m.stangl c353c34f2c [FIX] Eckrad-Export: Sivas-Merkmalnummern 3992/3993 statt Klartext-Keys
Eckrad fuehrte "Geruest fuer Einzelmodul"/"Geruestoption fuer
Einzelmodul" als beschreibende Klartext-Keys statt echter
Merkmalnummern - details_mit_bezeichnung() loest aber nur numerische
Keys gegen den Merkmalstamm auf, die Texte blieben im JSON unaufgeloest.
Merkmalsstamm_in_Sivas.xlsx enthaelt beide Nummern bereits (dieselben
wie bei Kreisel), jetzt in cfg/sivas.cfg uebernommen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-09 14:14:35 +02:00
m.stangl 5aed90dd56 [CHANGE] doc/plan und doc/todo angelegt, interne Analyse-/TODO-Dokumente dorthin verschoben
doc/todo/: TODO-plan-vf-interactive.md -> plan-vf-interactive.md, TODO-modus2-achsenweise-bilanz.md -> modus2-achsenweise-bilanz.md (offene Fahrplaene/TODOs).
doc/plan/: KS-Frame-Architektur.md, vf-parameter-struct-analyse.md, translate.md, Entwicklungsplan.md (Architektur-Analysen und Planungsdokumente, kein Anwender-Material).

Alle internen Verweise (CLAUDE.md, Lisp/README.md, README.md, doc/variofoerderer.md, Lisp/vf_spec.lsp, lib/dxf_vf_abbild.py, lib/vf_spec_export.py, tests/test_hm_recformat.lsp, tests/test_vf_geometrie.py, tests/test_vf_headless_statisch.py) auf die neuen Pfade angepasst. Reine Pfad-Updates in Kommentaren/Docstrings, keine funktionale Aenderung - Python-Syntax nach dem Umbau geprueft.

Anwender-/Entwickler-Referenzdoku (faq.md, kommandos.md, tools.md, dbg2lsp.md, csv-export.md, json-input-lisp.md, lisp_methods.md, LispTests.md, variofoerderer.md, vf_linienzug_modus1_anleitung.md) bleibt direkt in doc/.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-09 10:56:54 +02:00
m.stangl aaf47ab3c1 [CHANGE] JSON-Testdaten-Feldnamen aus dxf_anlage_export.py in lib/testdata_schema.py zentralisiert
dxf_anlage_export.py und dxf_scan_components.py fuehrten dieselben Feldnamen (abstand, deltaL_mm, as_seite, ...) aus doc/json-input-lisp.md unabhaengig als lose String-Literale - ein Tippfehler oder eine Schema-Aenderung in nur einer Datei waere nicht aufgefallen. Neues Modul lib/testdata_schema.py buendelt die Feldnamen/festen Werte der dokumentierten Schemas (Kreisel, Einzelblock, VF Standard/Etage, Gefaellestrecke Modus 1) als benannte Konstanten; dxf_anlage_export.py nutzt sie jetzt durchgaengig.

dxf_scan_components.py bewusst NICHT mitumgebaut: deutlich grösser/komplexer, mit zusaetzlichen Sonderfaellen (z.B. "startpunkt"/"gerade"-Form), ein vollstaendiger Umbau haette den Rahmen dieser Aenderung gesprengt und mehr Risiko als Nutzen gehabt.

Verhaltensgleich: alle 9 Tests in tests/test_dxf_anlage_export.py laufen weiterhin gruen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-09 10:43:09 +02:00
s.ayadi 8ef7324032 [FIX] Kreisel-Umlauf (export_neighbors.compute_kreisel_umlauf): AS/ES, deren ZZ_ASES_MARKER-Box keinen Kreisel trifft, ueber den Ein-/Auslaufpunkt der Strecke (K1 = KS_EIN, K2 = KS_AUS) zuordnen - laeuft eine Strecke parallel zum Kreisel, liegt der Marker (Einfuegepunkt) ~560 mm neben der Kette, der Einlauf aber darauf (Dematic VF_5 an Kreisel1 fehlte in den TrackIds); bereits zugeordnete AS/ES unveraendert + Tests; [ADD] dxf_anlage_export.py: Kreisel-Drehrichtung (DREHRICHTUNG) ins Testdaten-JSON; [CHANGE] dematic_arvato.json aus dem aktuellen Dematic_TST.dxf (Kreisel 1/4 GUZ, BTMT Be-/Entladung, Scanner vor Separator 0048)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-08 11:35:12 +02:00
s.ayadi 8885b5c96a [ADD] dxf_scan_components.py: Separatoren/Scanner auf einer Kreisel-Kette uebernehmen dessen Anwender-Hoehe (sensor_hoehen_von_kreiseln, bei --kreisel-hoehe) + Tests; [FIX] GF-Winkel aus Kreisel-Hoehen (dematic_arvato:gf-winkel): Modus 1 haelt die horizontale Laenge fest - Abfall = (deltaL - aus-dx - ein-dx) * tan(w) statt asin-Naeherung von gf-winkel-berechnen, ES-Abfall beim aktuellen Winkel gemessen und iteriert (steile GF wie Showroom ~37 Grad endeten sonst weit unter dem Kreisel); [CHANGE] Showroom ILS: Testdaten und Treiber aktualisiert
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 15:23:39 +02:00
s.ayadi 4d0d689815 [ADD] Nachbau ILS-3.0-Showroom: tests/testdata/showroom_ils.json aus Showroom_ILS_3_0.dxf (6 Kreisel, 11 Gefaellestrecken, Separatoren/Scanner; Hoehen noch Platzhalter), Treiber tests/test_showroom_ils.lsp (TEST_SHOWROOM_ILS, Menue Tests -> ILS 3.0 Showroom), in alltests.json bis zu den Hoehen deaktiviert; [ADD] dxf_scan_components.py: --flach (waagrechte Staustrecken mit AS an genau einem Ende als GF), --kreisel-achse (Kreisel ohne AN8/SP8, z.B. Schleifen mit Weichenboegen), zerstueckelte Staustrecken-Linien werden vereint, ES am unteren Ende wird erkannt und verbraucht, AS/ES-Seite ohne Seitenangabe im Namen aus der Lage zur Fahrtrichtung, Kurznamen AE-*/EE-*; [FIX] Kreisel-Paarung: zwei Kreisel auf derselben Achse wurden ueber die Luecke gepaart (800 + 12832 statt 9033 + 3000) - Tausch-Nachbesserung auf minimale Abstandssumme; [CHANGE] test_dematic_arvato.lsp: Lauf als dematic_arvato:bau-datei herausgeloest (vom Showroom-Treiber mitgenutzt); [ADD] Tests in test_dxf_scan_gf.py
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 15:00:45 +02:00
s.ayadi ba20d63f63 [ADD] lib/dxf_anlage_export.py: gebaute und von Hand nachbearbeitete Anlage aus der Zeichnung zurueck in Nachbau-Testdaten (Kreisel, GF, VF standard/etage, VF-Linienzug als unveraendertes Journal, Einzelbloecke) - tests/testdata/dematic_arvato.json jetzt aus Dematic_TST.dxf; [ADD] dxf_scan_components.py: Gefaellestrecken aus Staustrecken-LINEs (Layer 6-SP), Start/Ende auf die Kreisel-Ketten verlaengert, AS-Element und Separator auf der Achse werden verbraucht, Steigfoerderer erkannt, --ohne-hoehen und --kreisel-hoehe; [ADD] vf_spec.lsp: Replay-Kern vsp-bau-journal aus vsp-bau-aus-spec herausgeloest (auch fuer aufgezeichnete Journale); [CHANGE] TEST_DEMATIC_ARVATO baut GF, VF standard/etage und Linienzug-Journale (mubea:gf-bauen/-vario-bauen wiederverwendet); [FIX] GF-Winkel aus Kreisel-Hoehen: AS/ES-Abfall mit falschem Vorzeichen an gf-winkel-berechnen uebergeben (3.79 statt ~2.49 Grad, GF endete 258 mm zu tief); [ADD] Tests test_dxf_scan_gf.py, test_dxf_anlage_export.py
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 13:36:32 +02:00
s.ayadi 1250864849 [ADD] Dematic/Arvato: Nachbau-Vorlage tests/testdata/dematic_arvato.json (Abschnitt Flowpuffer/Kreisel) + Treiber TEST_DEMATIC_ARVATO (Menue Tests, in alltests.json vorerst disabled); [FIX] dxf_scan_components.py: liest jetzt auch ASCII-DXF, Kreisel-Paarung global nach Abstand und nur auf gemeinsamer Achse (vorher klaute ein AN8 die SP8 des Nachbarn), Kreisel-Position aus der Radmitte statt dem Einfuegepunkt (AN8/SP8 Pinband haben das Rad ~15 m daneben), Kreisel als insert mit Mittenabstand statt connect (war an beiden Enden einen Radius zu kurz), AN8/SP8 Pinband erkannt, Projektkennung in den IDs per --projekt statt fest HundM05; [FIX] hundm05:bau-sensor brach bei Eintraegen ohne id mit bad argument type <NIL> ab
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 15:40:03 +02:00
s.hensch 6ec85905d4 [ADD] Gerüst Träger können nun über das Menü in Bricscad eingefügt werden wie durch die Bihler Bibliothek; Beschriftungsausrichtung nach Norm korrigiert; Nachträgliche Beschriftung über Makro für alle platzierten Träger möglich 2026-10-02 14:46:12 +02:00
s.hensch 7e98b85e5e [CHANGE] eine zusätzliche csv für den Sivas export wird erstellt, die alle identischen Zeilen summiert und in einer Zeile mit neuer Anzahl schreibt; [ADD] Neue Gerüstkomponenten für die Baugruppenerstellung on the fly durch hinzugefügt; [CHANGE] Testskripte angepasst 2026-09-29 17:08:14 +02:00
s.hensch 4e39c64ec1 [ADD] Geruest: Teile-DWGs (data/geruest/<artnr>.dwg) als Geometrie im GR_-Block; TEILEFARBE als Liste parallel zu ARTINR (Flag farbig in geruest.json), Sivas-Merkmal 108 aus cfg [Sivas]; Menue-Befehle GERUEST_SAEULEN/_ROHRABHAENGER/_WANDBEFESTIGUNG
[FIX] Sivas-Export las nicht existierendes Attribut FARBE
2026-09-29 12:07:00 +02:00
m.stangl e8c5cd0a63 Testrun-Export nach tests/output umbiegen, Sivas-Bezeichner-Datei optional, Sivas-Merkmalzuordnung in Config
SSG_RUN_ALL_TESTS_EXPORT setzte *export-test-override* nicht, dadurch
landeten CSV/Sivas-Exporte trotz Automatik-Modus in DXFM_RESULTS statt in
tests/output wie die DXF/DWG-Dateien selbst - jetzt analog zu
TEST_EXPORT_ALL behoben.

EXPORTSIVAS schrieb bisher immer zusaetzlich eine "_mit_bezeichnung.csv"
(Klartext-Kopie). Neuer Schalter "Sivas Export mit Bezeichner" im Dialog
CSV_EXPORT_KONFIG (Standard aus) macht das optional.

Die Attribut->Sivas-Merkmal-Zuordnung der build_*_details-Funktionen in
export_sivas.py (Gefaellestrecke/Kreisel/Eckrad/Geruest/VarioFoerderer,
soweit nicht von der Segmentanzahl abhaengig) liegt jetzt deklarativ in
cfg/sivas.cfg statt hartcodiert im Python - neuer Loader
lib/sivas_mapping.py. Ablauflogik (Gruppierung, Automation-Summenzeile,
Segment-Zaehlung) bleibt Code. Gegen den alten Code mit synthetischen
Testblöcken verifiziert: identische Ausgabe.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-28 16:39:18 +02:00
s.hensch 2ff4322d99 [MERGE] export Konflikt gelöst 2026-09-28 14:11:09 +02:00
s.hensch dabf9e4f8a [CHANGE] Sivas Export schaut nun nur noch auf die kommaseparierte Liste im Attribut ARTINR und fügt die Artikelnummern in die Export-Liste ein; [ADD] Menü und dwg für Omniflo Ladeschleifen 2026-09-28 13:53:46 +02:00
s.ayadi 1e6b152d72 export: jeden Wert nur an einer Stelle setzen (ZUORDNUNG, sepliste-IDs, Typen, K1/K2)
- ZUORDNUNG: ssg-id-check-all laeuft jetzt ZUERST, danach sind die
  Wrapper-IDs endgueltig - Separator-Kopien, AS/ES- und Einheiten-Marker
  bekommen ZUORDNUNG direkt beim Erzeugen. Entfallen:
  csv:sep-proxies-zuordnung-setzen, csv:asmark-ids-setzen,
  csv:unitmark-ids-setzen. zuordnung_fix/*cs-sep-fix-by-handle* bleibt
  (count_sep_scan rechnet eigenstaendige Sensoren bewusst neu).
- sepliste-IDs: Zuordnung ueber die KS-Kettenfolge je Typ
  (csv:sepliste-kette-paare) statt ueber die teils gespiegelten
  sepliste-Koordinaten (csv:sepliste-paare, csv:sepliste-ids-setzen
  entfallen). Die Kette wird je Lauf einmal berechnet (csv:kette-von);
  die ID liest csv:block-to-json erst beim Schreiben. Behebt vertauschte
  TrackIds/Nachbarn in HundM05 VF_1 (0031/0029).
- Element-Klassifizierung: eine Tabelle csv:element-familien (cfg-Muster)
  fuer Suche und Klassifizierung; csv:proxy-typ entfaellt.
- Einheiten-Marker: K1/K2 nur noch in *csv-baustein-by-handle*
  (csv:geometrie-merken), K1/K2-Attribute und
  csv:unitmark-k-kos-strings entfallen.

Geprueft: HundM05-Export alt/neu headless verglichen - einzige Abweichung
ist die korrigierte Reihenfolge in VF_1. LISP-Unit-Tests 303/303.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 12:10:16 +02:00
s.ayadi e67f7cc1aa export: Separator-Typ VF/GF aus der Ketten-Einheit statt Bau-XDATA
Der Typ (Merkmal "Typ") jeder Separator-Zeile kommt jetzt an EINER Stelle
aus der Einheiten-Schneidung csv:kette-einheiten (neu: csv:kette-sep-typen,
eingetragen in csv:ketten-verarbeiten) - dieselbe Quelle wie die
Einheiten-Boundingbox. VF = Separator direkt vor der Umlenkstation bzw.
zwischen Umlenk- und Motorstation, sonst GF.

Die bauzeitige XDATA SSG_SEP_TYP (ssg-sep-typ-xdata-schreiben/-lesen,
15 Einfuegestellen) entfaellt. Sie war teils falsch: der Separator vor dem
ES hinter einer Motorstation bekam "VF", und ein sep_nach-Separator einer
GF, den die folgende VF-Einheit als Einlauf nutzt, blieb "GF"
(HundM05: Sep1/5/7/9/11 und Sep2).

Unit-Tests csv:kette-sep-typen in tests/test_unit.lsp.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 11:23:27 +02:00
m.stangl 96ca43eff5 export: Hilfskopien nach dem Export loeschen, IDs stabil ueber reservierte IDs
AS/ES-Marker werden wie alle Hilfskopien geloescht (ausser csv_leave_proxies). IDs von AS/ES, Separator-Kopien und Einheiten bleiben ueber reservierte IDs (XDATA SSG_ID_RES) am VF_n/GF_n-Wrapper stabil: AS|n/ES|n, K|i, U|n.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 10:14:02 +02:00
m.stangl 394d476d56 export: Kettenbausteine ueber KS verketten, Einheiten neu gruppieren
K1/K2 und Boundingbox je Export-Zeile folgen jetzt dem echten
Kettenbaustein statt seinem Stellvertreter:
- Separator (all_elements): KS + bbox des 300-mm-Trennstegs statt des
  Sensor-Symbols; separator_track/group_vf_gf behalten das Symbol
- AS/ES (all_elements, group_vf_gf): KS + bbox des AS-/ES-Elements statt
  des 200x200-Markers ohne K
- gemeinsamer Kern csv:ks-welt-punkte; VF/GF-Wrapper-K1/K2 = K1 des AS
  bzw. K2 des ES

Gruppierter Export neu (sepliste-/XDATA-Algorithmus entfernt):
- Bausteine je Wrapper als Vektorkette K2 -> K1 ordnen (Start am AS)
- Foerdereinheit = Separator vor der Umlenkstation bis Motorstation,
  alles dazwischen Gefaelleeinheit (csv:kette-einheiten, Unit-Tests)
- je Einheit ein temporaerer Proxy mit 3D-Boundingbox, K1/K2, Laenge und
  Anzahl Boegen; wird nach dem Export geloescht (ausser csv_leave_proxies)
- IDs neuer Export-Objekte entlang der Kette AS -> ES aufsteigend

Weiteres:
- ssg-make-layer ohne _LAYER-Befehl fuer bestehende Layer (Konsole)
- einheitliche, zweisprachige Meldungen fuer behaltene Hilfskopien
- bin/show_exportcsv.bat: Export-CSV als Boundingbox-SVG (sps_skel)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-25 20:25:29 +02:00
m.stangl e7643bf181 export_csv: VF_n/GF_n-Einzelelemente zu Foerdereinheit/Gefaelleeinheit gruppieren
Die Einzelteil-Proxy-Zeilen (Boegen, Streckenelemente, Umlenk-/Motorstation)
aus der letzten Session sind fuer den Normalfall zu granular. Standardmaessig
(*csv-export-alle-elemente* = nil) fasst csv:unitmark-aktualisieren sie jetzt
zu je einer "Foerdereinheit"/"Gefaelleeinheit"-Zeile pro zusammenhaengendem
VF-/GF-Abschnitt einer Kette zusammen, mit einem persistenten Rechteck-Marker
(ZZ_UNIT_MARKER, analog ZZ_ASES_MARKER) auf der Bounding-Box-Vereinigung
aller enthaltenen Elemente. Der bisherige Rohdaten-Export bleibt ueber
(csv:export-alle-elemente-an) weiterhin verfuegbar.

Einheiten-Grenzen kommen rein export-seitig aus der sepliste (SEP/AS/ES in
echter Bau-Reihenfolge) plus dem bereits vorhandenen SSG_SEP_TYP je
Separator - eine bauzeitige Markierung in vf_linienzug.lsp/vf_standard.lsp/
vf_etage.lsp waere deutlich invasiver gewesen (3 unabhaengige Baupfade ohne
gemeinsamen Einstiegspunkt). csv:sepliste-partition (Lauflaengen-Kodierung
ueber die typisierte sepliste) und csv:element-unit-zuordnung (Zuordnung der
gesammelten Elemente per Kettenrichtungs-Projektion statt der nachweislich
unzuverlaessigen csv:nested-welt-records-Listenreihenfolge) sind reine,
dateifrei getestete Funktionen.

Korrigiert nebenbei eine falsche Annahme: L_VF_m/L_GF_m zaehlen pro Segment,
nicht pro Einheit - die tatsaechliche Einheiten-Anzahl kommt nur aus der
sepliste-Typfolge.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-24 23:46:41 +02:00
m.stangl f751a90076 export_csv: VF_n/GF_n-Einzelelemente (Boegen, Streckenelemente, Umlenk-/Motorstation) als Proxy-Zeilen exportieren
Bisher tauchten nur der Wrapper selbst, verpackte Separatoren und AS/ES-
Kettenenden als eigene CSV-Zeilen auf - die uebrigen Kettenbausteine
(Boegen, gerade Foerderer-/Gefaellestrecken-Segmente, Umlenk-/Motorstation)
blieben nur in der Wrapper-Blockdefinition verpackt. csv:element-proxies-
erzeugen (analog zu csv:sep-proxies-erzeugen) fuegt fuer jeden Fund eine
temporaere Kopie ein, K1/K2 kommen aus dem EIGENEN KS_EIN/KS_AUS jedes
Elements (nicht dem Gesamt-AS/ES der Kette) und bleiben leer, wo keines
existiert (z.B. das nie tatsaechlich eingefuegte Vario_Kurve_*).

Zusaetzlicher Fix: csv:get-k-kos-strings ignorierte bisher die Skalierung
des Top-Level-Inserts - fuer Staustrecke_SP_1000_mm (das per Laenge nicht-
uniform skaliert wird) waere K2 damit falsch gewesen, unabhaengig von der
tatsaechlich gebauten Segmentlaenge.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-24 13:08:35 +02:00
m.stangl 4f1a0e0b5b export_csv: sepliste-Koordinaten (x/y) entfernen, nur noch typ/lfdnr/id
Validiert (Nutzer-Befund): die sepliste-XDATA-Koordinaten sind der rohe
Gruppencode-10-Punkt des jeweiligen Bau-Primitivs und teils gespiegelt/um
mehrere 100mm verschoben (z.B. Separator 0037: x=-5070.1 statt 5070.1,
ausserhalb der VF_1-Boundingbox). Die eigene Export-Zeile jedes Bauteils
(x/y aus der echten Proxy-Kopie) ist dagegen verlaesslich und liegt korrekt
in der Boundingbox. sepliste dient nur noch der ID-Zuordnung/Reihenfolge,
nicht mehr als Koordinatenquelle.

Der Python-Faellback in map_sepliste_kette_items (nur fuer SEP-Eintraege
ohne aufloesbares "id"-Feld, Altbestand) matchte bisher per naechstem
sepliste-Punkt - jetzt erster unverbrauchter Kandidat je Zuordnung, da keine
Koordinate mehr vorliegt. lib/dump_vf_kette_inhalt.py zeigt Position/Typ
jetzt ueber die ID-Verknuepfung zur eigenen Bauteil-Zeile statt ueber die
entfernten sepliste-Felder.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-24 10:58:53 +02:00
m.stangl 2f56729308 export_csv: Separator-TYP (VF/GF) bauzeitig je Separator statt vom Wrapper-Blocknamen ableiten
csv:wrapper-strecke-typ (voriger Ansatz) las den Streckentyp aus dem
VF_n/GF_n-Wrapper-Blocknamen - falsch, weil ein einzelner Wrapper intern
mehrfach zwischen Foerderer- und Gefaellestrecke-Abschnitten wechseln kann
(HundM05 VF_1: 4 Separatoren, 2x VF, 2x GF). Jede Separator-Einfuegestelle in
vf_linienzug.lsp/Gefaellestrecke.lsp/vf_standard.lsp/vf_etage.lsp markiert
das frisch eingefuegte Staustrecke_Separator_SP_300_mm-Insert jetzt direkt
per XDATA (ssg-sep-typ-xdata-schreiben/-lesen, ssg_ks_insert.lsp). Der Export
liest den Marker am verpackten Original (nested-ent), nicht mehr am Wrapper.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-23 17:28:31 +02:00
m.stangl c95a94c175 Diagnose-Skripte fuer VF/GF-Kettenzusammensetzung ergaenzen
Zeigen die Spec- bzw. Blockdefinitions-Struktur einer VF-/GF-Linienzugkette
in der Konsole, um sichtbar zu machen, dass ein einzelner VF_n-Wrapper
intern zwischen VF- und GF-Abschnitten wechseln kann (Grundlage fuer den
noch ausstehenden Separator-TYP-Fix).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-23 17:14:03 +02:00
s.ayadi ab3958e0e4 export_csv: AS/ES direkt aus ZZ_ASES_MARKER klassifizieren, Kreisel<->Strecke-Kollisionserzeugung entfernen
Stufe 2 (Python-Seite von "sepliste: Bauteil-IDs eintragen"): AS/ES-Kettenenden
sind jetzt ganz normale Items, direkt aus dem dauerhaften ZZ_ASES_MARKER
klassifiziert (TeileId/Position/Boundingbox vom Marker-Block selbst) - keine
Kollisionsberechnung mehr, die sie erfindet.

- lib/export_neighbors.py: compute_strecke_kreisel_schleus entfernt (suchte
  bisher per Kollisionstest den anschliessenden Kreisel und erzeugte dabei bei
  JEDEM Export eine neue TeileId fuer denselben physischen Punkt). AUSSCHLEUS_/
  EINSCHLEUS_TEILEART sind jetzt Teil von KREISEL_UMLAUF_TEILEARTEN - ein AS/ES
  bringt seine eigene Bounding-Box vom Marker mit und wird dadurch, wie jeder
  freie Separator, ueber die normale BBox-Ueberschneidung einem Kreisel
  zugeordnet; die gesonderte "naechster Kreisel per sep_kette"-Suche in
  compute_kreisel_umlauf (dessen sep_kette-Parameter damit entfaellt) ist
  ueberfluessig geworden. compute_sep_kette gibt je Eintrag zusaetzlich das
  Feld "id" weiter (Bauteil-TeileId, siehe vorheriger Commit).
- lib/export_csv.py: process_blocks klassifiziert ZZ_ASES_MARKER direkt (TYP-
  Attribut waehlt Ausschleus-/Einschleuselement); build_strecke_schleus_items
  entfaellt komplett. map_separator_kette_items -> map_sepliste_kette_items:
  ordnet jetzt AS/SEP/ES exakt per ID-Gleichheit zu (sepliste-Feld "id" gegen
  die TeileId der klassifizierten Items) statt per Koordinaten-Naehe - SEP
  faellt bei fehlendem "id"-Feld weiterhin auf den alten Naehe-Abgleich zurueck
  (Altbestand), AS/ES ohne "id" bleiben unaufgeloest.
- Neu: pruefe_ases_in_beiden_containern prueft am Ende von process_blocks, ob
  jede AS-/ES-Zeile sowohl in den TrackIds ihrer eigenen Strecke als auch in
  denen mindestens eines Kreisels auftaucht, und traegt bei Abweichung eine
  Warnung ein (Spalte "Warnungen") - Konsistenzpruefung fuer genau die beiden
  "Container", zu denen ein AS/ES gehoert.
- Aufgeraeumt (tote Routinen): _strecke_ends, _closest_pt_on_segment,
  _distinct_kreisel_ids (nur von den entfernten Funktionen genutzt), sowie der
  temporaere Diagnose-Filter DEBUG_HIGHLIGHT_TEILEIDS/dbg_highlight (an die
  jetzt behobene Koordinaten-Matching-Ambiguitaet gebunden, in seinem eigenen
  Kommentar bereits als Wegwerf-Code markiert). LISP-seitiger Dead-Code-Scan
  (export.lsp, ssg_ks_insert.lsp - die diese Woche bearbeiteten Module):
  keine Funde.

Verifiziert an den echten HundM05-Daten (results/export_raw.json, 45 Bloecke):
TeileId-Bereich luecken- und duplikatfrei 1-45 (vorher 1-55 mit Luecke 24-33 +
Zusatz-IDs 46-55), alle 10 AS/ES-IDs korrekt in ihrer Strecke UND im Kreisel
06 TrackIds, keine Warnungen der neuen Pruefung. Zwei Testdateien auf die neue
Architektur umgestellt (test_export_kreisel_umlauf.py: AS/ES als Item statt
Kollisions-Erzeugung, neue Klasse TestAsEsImKreiselUmlauf fuer die BBox-
Teilnahme; test_export_separatorliste.py: id-basierte Zuordnung, Klasse
TestMarkerIdWiederverwendung durch TestMapSeplisteKetteItemsFallback ersetzt
- die alte testete inzwischen entfernte Mint-Logik). Volle Suite: 224 bestanden
(4 vorbestehende, unabhaengige Fixture-Failures unveraendert).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-22 14:48:45 +02:00
s.ayadi 719ffc2385 export_csv: AS/ES-Marker-ID wiederverwenden statt neu zu minten
build_strecke_schleus_items erfand bisher fuer jede AS/ES-Zeile eine neue
TeileId, obwohl der zugehoerige ZZ_ASES_MARKER (Lisp/export.lsp) laengst
eine stabile ID traegt (im sepliste-Eintrag als Feld "id" gespiegelt).
Ergebnis in der Praxis (HundM05): TeileIds 24-33 blieben ungenutzt
(Marker bekommt bis heute keine eigene CSV-Zeile), waehrend fuer dieselben
Punkte bei jedem Export zusaetzlich frische, hoehere IDs (46-55) minted
wurden - eine sichtbare Luecke plus unnoetige ID-Inflation.

Jetzt: liest die Marker-ID aus sepliste[0]["id"] (AS) bzw. sepliste[-1]["id"]
(ES) und uebernimmt sie unveraendert; fehlt sie (Altbestand ohne Marker),
bleibt das bisherige Mint-Verhalten unangetastet. Der laufende Zaehler wird
auf die wiederverwendete ID hochgezogen, damit ein spaeterer Mint in
derselben Kette sie nicht erneut vergibt. ZZ_ASES_MARKER selbst bekommt in
process_blocks jetzt einen expliziten, dokumentierten Skip (statt stillem
Durchfallen durch alle Muster).

Verifiziert an den echten HundM05-Daten: export.csv lief vorher 1-55 mit
Luecke 24-33, jetzt luecken- und duplikatfrei 1-45 (results/export.csv neu
erzeugt). 2 neue Tests in tests/test_export_separatorliste.py (Wiederver-
wendung + unveraenderter Fallback), volle Suite unveraendert bis auf 4
vorbestehende, unabhaengige Fixture-Failures (stale tests/output/*.dxf).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-22 13:41:35 +02:00
s.ayadi 618ff3d86c sepliste: Bauteil-IDs eintragen, AS/ES ueber dauerhaften Marker sichtbar machen
Stufe 1 (LISP-Export-Pfad): export_raw.json enthaelt jetzt fuer jeden
sepliste-Eintrag (AS/SEP/ES) einer VF_n/GF_n-Kette die ID des realen
Bauteils, das ihn vertritt.

- csv:sep-proxies-erzeugen (Separatoren) und die neuen AS/ES-Marker teilen
  sich csv:nested-welt-records/csv:block-einfuegen-welt zur Platzierung.
- csv:sepliste-paare ordnet sepliste-Eintraege ihrem Bauteil exklusiv nach
  Abstand zu (kuerzester zuerst, dann verbraucht) statt "jeder Eintrag
  nimmt sich das naechste" - ein einzelner fehlerhafter Koordinatenwert
  (bekannter Bug: gespiegeltes x bei lfdnr=2) verschiebt dadurch keine
  andere Zuordnung mehr.
- Neu: ZZ_ASES_MARKER - ein kleines Rechteck an jedem AS/ES-Kettenende,
  das nach dem Export STEHEN BLEIBT (anders als die temporaeren
  Separator-Kopien). Macht das sonst unsichtbare, in der Wrapper-
  Blockdefinition verpackte Kettenende in BricsCAD sichtbar/anklickbar
  und traegt seine ID unsichtbar am Attribut ID - dadurch behaelt ein
  AS/ES seine TeileId ueber Exportlaeufe hinweg. Wird bei jedem Export
  neu aufgebaut (Lage folgt der Kette), Wiederfund ueber ZUORDNUNG+TYP+
  LFDNR, verwaiste Marker werden entfernt.

In BricsCAD verifiziert (5 HundM05-Ketten, zwei Exportlaeufe: gleiche
Marker-IDs, korrekte sepliste-"id"-Felder). Dabei einen realen Bug
gefunden und behoben: die Blockdefinition des Markers uebernahm ueber
einen ungefilterten entnext-Walk versehentlich auch die Attribute des
zuletzt eingefuegten Blocks (VF_5 verlor dadurch alle Attribute inkl.
ID) - jetzt auf LWPOLYLINE/ATTDEF gefiltert.

9 neue zeichnungsfreie Unit-Tests (csv:sepliste-paare/*, csv:asmark-
finden/*, csv:proxy-typ/*), 4 neue de/en-Textschluessel (Paritaet
geprueft). bin\run_tests.bat --lisp: 257/257 bestanden.

Noch nicht enthalten (Stufe 2, Python): map_separator_kette_items nutzt
das neue "id"-Feld noch nicht, build_strecke_schleus_items synthetisiert
AS/ES-Zeilen weiterhin selbst statt die exportierten zu lesen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-22 13:09:05 +02:00
m.stangl 9671fe4e04 sprechender Sivas Export war noch eine key value Kombination 2026-09-22 10:55:37 +02:00
s.ayadi 0e4ea7e148 Kreisel-Umlauf: Abfolge ueber BB-Halbachsen statt Winkel um Mittelpunkt
compute_kreisel_umlauf sortierte Punkte bisher per atan2 um den
Kapsel-Mittelpunkt. Auf der langen Geraden (dx >> dy) liegen alle
echten Winkel in einem winzigen Band nahe 0 Grad - ein grosser,
asymmetrischer Block wie BTMT-Beladung/-Entladung hat einen Bbox-
Mittelpunkt, der deutlich weiter quer zur Achse absteht als der
Belt-Radius, was seinen Winkel unverhaeltnismaessig aufblies und ihn
mehrere eng benachbarte Punkte ueberholen liess, obwohl er entlang der
Achse klar der letzte ist (realer Fall: HundM05, BTMT-Entladung
"0023", landete zwischen 0039/0016 statt hinter 0018/0020).

Neu: Punkt in lokale Achsrichtung drehen und auf die BB-Halbachsen
(halbe Achslaenge, Radius) normieren; welche der beiden Komponenten
ueberwiegt, legt nur noch die Seite fest (Stirnseite/Langseite) - auf
den Langseiten bestimmt ausschliesslich die Achsrichtung die Position,
der quer abstehende Anteil kippt bestenfalls die Seiten-Zuordnung,
verzerrt aber nicht mehr die Reihenfolge selbst. Mit den realen
HundM05-Koordinaten verifiziert; test_export_kreisel_umlauf.py und
test_export_graph.py weiterhin gruen (20/20), keine neuen Regressionen
in der breiteren Suite.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-17 14:26:11 +02:00
m.stangl 1d082ccde7 feat: Eingang/Ausgang-Symbole als eigene CSV-Zeile + in TrackIds
Die Materialfluss-Ein-/Ausgangssymbole (Bloecke Eingang_<DIM>/Ausgang_<DIM>,
eingefuegt ueber ils-insert-station) erscheinen jetzt NUR im CSV-Export als
eigene TeileArt-Zeile ("Eingang"/"Ausgang", Merkmale wie BTMT). Wie
Separator/AS/ES nehmen sie als freie Umlauf-Punkte (KREISEL_UMLAUF_TEILEARTEN)
an der TrackIds-Spalte teil und tauchen so auch auf Kreiseln auf, auf deren
Bahn sie liegen. Der Sivas-Export schliesst sie bewusst aus.

- cfg/export.cfg: pattern_eingang/pattern_ausgang
- Lisp/export.lsp: csv:collect-export-blocks sammelt beide Muster
- Lisp/ssg_id.lsp: ssg-id-collect-blocks erfasst sie (ssg-id-check-all fuellt
  das nachgetragene ID-ATTDEF, dokumentiert in data/ils/allocations.json)
- lib/export_csv.py: Klassifikations-Zweige Eingang/Ausgang
- lib/export_neighbors.py: KREISEL_UMLAUF_TEILEARTEN um Eingang/Ausgang erweitert
- lib/export_sivas.py: Eingang/Ausgang uebersprungen (kein Sivas-Eintrag)
- Tests: test_export_eingang_ausgang.py + Kreisel-Umlauf-Test

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-16 11:55:57 +02:00
s.ayadi 6d569072ec Merge branch 'master' of https://gitea.schoenenberger.de/Schoenenberger_Systeme_GmbH/dxfmakros 2026-09-15 15:15:07 +02:00
s.ayadi 4a057862a8 fix: VF-Linienzug Journal-Reset, Spec-Grammatik (auf-ab/Linie-GF) und hz-Bug in HundM05
- vfl-journal-reset-lauf ans Funktionsanfang verschoben (Modus 1/2/3,
  Lisp/vf_linienzug.lsp): stand bisher nach der Startpunkt/Hoehe/AS-
  Praeambel und loeschte diese beim Reset selbst wieder - Journal begann
  mit dem ersten STEP-Marker statt PT, betraf jede Kette.
- Spec-Grammatik erweitert (Lisp/vf_spec.lsp, lib/vf_linienzug_grammatik.py,
  lib/vf_spec_export.py): "auf-ab" bei bereits flach ankommender Kette
  (Richtungswahl statt Zielhoehe) und neue Linie-GF-Fragereihenfolge
  (Kettenende direkt nach laenge_modus, inkl. vorgezogenem ES). Tests in
  tests/test_vf_spec.lsp/.py angepasst.
- lib/vf_linienzug_grammatik.py: _linie("kettenende_ziel") erwartete
  faelschlich ein hz-REAL nach der Distanz - der reale Bauablauf
  (vfl-body-abschluss) leitet die Richtung dort aus dem Frame ab und
  fragt sie nie. Fuehrte zu einem Token-Desync beim Dekodieren echter
  Kettenende-Journale.
- tests/testdata/hundm05.json (VF_hundm05_LZ_01): 5 ueberfluessige
  hz-Felder entfernt. vsp-linie injiziert bei JEDEM vorhandenen hz-Feld
  einen Richtungs-Token, unabhaengig vom tatsaechlichen Bauablauf - die
  Felder desyncten den Replay und liessen die Kette stumm mit der
  falschen (verkuerzten) Geometrie fertig bauen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-15 15:13:07 +02:00
y.wang 551f2808d7 refactor: Lesehilfe-CSV nutzt verschachtelte {bezeichnung, wert}-Struktur
details_mit_bezeichnung() liefert fuer die "*_mit_bezeichnung.csv" jetzt
{"<Nummer>": {"bezeichnung": "...", "wert": "..."}} statt eines
zusammengesetzten Schluessels "<Nummer> | <Bezeichnung>" - Merkmalnummer
bleibt dadurch ein sauberer JSON-Key, Bezeichnung/Wert sind eigene,
eindeutig benannte Felder. Die eigentliche Sivas-Import-Datei
(*_sivas.csv) ist davon nicht betroffen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-15 12:21:32 +02:00
y.wang 6f12cab86f refactor: Sivas-CSV-Export auf Merkmalnummern umgestellt, lesbare Zweitdatei
- ILS 2.0 Kreisel/Strecke(VF_N)/Gefaellestrecke/Automation: details-JSON
  nutzt jetzt Sivas-Merkmalnummern (z.B. "2952") statt beschreibender
  Klartext-Keys, abgeglichen mit dem Merkmalstamm in
  cfg/Merkmalsstamm_in_Sivas.xlsx.
- ILS 2.0 Zusatzmodul: BT-Beladung und Abwurfstationen laufen jetzt in
  einer gemeinsamen Zeile (Merkmale 3501-3504) statt zwei separaten
  Zeilen ohne details.
- Gefaellestrecke-Gruppe: Anzahl-Spalte bleibt fest 1, die reale
  Stueckzahl der Gruppe steht im Merkmal 4311 (anders als bei Kreisel,
  wo die Anzahl-Spalte die Stueckzahl traegt und 3511 fix "1" ist).
- Automation-Summenzeile: 4407 zaehlt jetzt echte Streckengruppen
  (VF_N-Bloecke) statt eines 0/1-Flags, 4408 (Motoren Vario-Foerderer)
  wird erstmals tatsaechlich berechnet (vorher nie inkrementiert), 4426
  steht fest auf "0" (Konzept "einzelner Variofoerderer" entfaellt).
- Neues Modul lib/merkmalstamm.py: liest Merkmalnummer->Bezeichnung aus
  der xlsx rein per Standard-Library (zipfile/xml.etree, keine neue
  pip-Abhaengigkeit fuer den ueber export.lsp aufgeloesten Interpreter).
- export_sivas.py schreibt bei jedem Lauf zusaetzlich eine zweite Datei
  "<name>_mit_bezeichnung.csv" (gleicher Inhalt, aber jeder
  Merkmalnummer-Key um "<Nummer> | <Bezeichnung>" erweitert) - reine
  Lesehilfe zur Pruefung, wird von Sivas nicht eingelesen.
- cfg/sivas_merkmal_zuordnung.md: Nachschlagetabelle Block-Attribut <->
  Merkmalnummer je Teileart, inkl. offener Punkte (Separator-/
  Scanner-Aufteilung Gefaelle-/Vario-Anteil noch Platzhalter).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-15 10:33:20 +02:00
m.stangl 865225f6f6 fix: LAYER-Attribut nicht mehr in Geruest-Sivas-Export schreiben
LAYER ist reine BricsCAD-Zeichnungsinformation ohne Sivas-Bedeutung.
export_csv.py (bricscad.csv) behaelt es weiterhin fuer die Zuordnung in der
Zeichnung.
2026-09-14 14:59:02 +02:00
m.stangl c5ae0bd769 fix: Geruest-Sivas-Export erzeugt eine Zeile je Artikelnummer statt Sammelzeile
Sivas kennt nur eine Sivasnr je Zeile - ARTINR (kommagetrennte Liste) wird
daher aufgesplittet. Gleiche Artikelnummern innerhalb derselben Baugruppe
werden zu einer Zeile mit Anzahl>1 zusammengefasst (wie bei Boegen/Weichen).
Jede resultierende Zeile traegt die volle LAENGE der Baugruppe.
2026-09-14 14:55:30 +02:00
m.stangl 1590f8f7ed feat: GR_-Geruest-Baugruppen in EXPORTCSV/EXPORTSIVAS aufnehmen
GR_-Bloecke werden jetzt wie BTMT eigenstaendig gesammelt (LISP: neues
pattern_geruest in cfg/export.cfg, csv:collect-export-blocks,
ssg-id-collect-blocks + ID-ATTDEF in *geruest-attrib-defs*) und in beiden
Python-Exporten als eigene TeileArt-Zeile ausgegeben: ARTINR/BEZEICHNUNG/
TEILEART/LAENGE in festen Spalten, restliche Attribute (FARBE/LAYER) im
Merkmale-/details-JSON.

Dabei zwei Bugs behoben, die beim ersten echten GR_-Export sichtbar wurden:
- csv:json-escape nutzte vl-string-subst (ersetzt nur das erste Vorkommen)
  statt des global ersetzenden ssg-str-replace-all - bei Attributwerten mit
  mehreren Anfuehrungszeichen blieb ein Zeichen unescaped und brach die
  JSON-Struktur beim Python-Parsen.
- Gradzeichen (°) in data/json/geruest.json durch "Grad" ersetzt, um das
  Encoding-Risiko (cp1252 vs. UTF-8 beim LISP-Export) zu vermeiden.
2026-09-14 14:22:45 +02:00
m.stangl c171bc44d6 docs: CSV-Export-Doku in doc/csv-export.md ausgelagert und mit Beispiel ergaenzt
Der lange Docstring in lib/export_csv.py wandert nach doc/csv-export.md
(inkl. durchgerechnetem Beispiel Kreisel+VarioFoerderer), der Docstring
verweist nur noch darauf.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-14 12:59:44 +02:00
s.ayadi 23d79ec354 feat: eingang_hoehe="auto" auf Python-Seite nachgezogen, hundm05.json bereinigt
Lisp (vf_linienzug.lsp/vf_spec.lsp):
- vsp-eingang-hoehe unterstuetzt jetzt "auto" (NIL-Token statt REAL) -
  bewusst keine Zahl vorgeben, der Bauablauf berechnet seinen eigenen
  Vorschlag, wie bei leerer Konsoleneingabe
- vfl-journal-reset-lauf: internes Reset innerhalb von vf-linienzug-modus/
  -modus2 loescht *vfl-replay-queue*/*vflw-pending* nicht mehr mit (Bug:
  REPLAY-getriebener Bau (vsp-bau-aus-spec) brach mitten in der Kette ab,
  weil eine noch unverbrauchte Queue verworfen wurde)

Python-Gegenstueck nachgezogen (lib/vf_linienzug_grammatik.py,
lib/vf_spec_export.py, lib/vf_journal_export.py):
- NIL-Token-Unterstuetzung fuer eingang_hoehe="auto" im gemeinsamen
  Parser-Kern, im Schreiber (SpecSchreiber) und in der Protokoll-Annotation
- gf_verteilung ist im Schreiber jetzt an der Feldpraesenz in der Spec
  festgemacht statt an einem Grammatik-Flag (selbstbeschreibend, deckt
  Specs mit und ohne diese Frage ab, ohne dass der Aufrufer die Grammatik
  kennen muss)
- Rundlauf-Pruefung (main(), test_verlustfrei) toleriert jetzt die bekannte,
  schon dokumentierte Erweiterung um drei neue Linie-GF-Pflichtfragen
  (ist_teilfolge statt exakter Gleichheit)
- test_gleiche_journale_wie_protokoll: alle 5 Ketten in hundm05.json weichen
  inzwischen vom Rohprotokoll ab (Kette 1 bewusst wegen eingang_hoehe,
  Ketten 2-5 schon laenger wegen Handkorrektur gegen echte DXF-Positionen)
  - expliziter Skip mit Begruendung statt leerem Loop

tests/testdata/hundm05.json:
- mm-Werte (dl, Start-/Stuetzpunkte, Koordinaten der Nachtrag-Objekte) auf
  eine Nachkommastelle gerundet
- nicht abgefragte Kopf-Metadaten entfernt (beschreibung, sivas_id,
  sivas_bezeichnung, planquadrat, block, dxf_handle) - nur quelle bleibt

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-14 12:54:30 +02:00
s.ayadi 6d15c6be13 refactor: VF-Linienzug-Journal-Grammatik in lib/vf_linienzug_grammatik.py gebuendelt
lib/vf_journal_export.py (Journal.dekodiere) und lib/vf_spec_export.py
(SpecLeser) implementierten denselben Tokenwalk (Praeambel, Sektions-
schleife, Glied-Dispatch, VF-Einheit-Unterschleife) sowie dieselben
Code-Tabellen (SEITE/VARIANTE/VERTEILUNG/IM_VF/ENDPUNKT/ENDE2/ENDE3/
GEFAELLE/GF_LAENGE_MODUS, MENU_START/MENU_START_AKTUELL/MENU_WEITER,
Grammatik) unabhaengig voneinander - Aenderungen an der Grammatik (wie
im vorigen Commit) mussten von Hand synchron gehalten werden und sind
bereits einmal auseinandergelaufen.

Neuer gemeinsamer Parser-Kern (Kern/lies_journal) plus Sink-Schnittstelle
(SpecSink in vf_spec_export.py, ProtokollSink in vf_journal_export.py)
ersetzt die doppelte Implementierung; Code-Tabellen/Grammatik-Objekte
leben jetzt nur noch in lib/vf_linienzug_grammatik.py. Journal behaelt
nur noch die reine XDATA/DXF-Zerlegung, SpecSchreiber (Spec -> Journal,
Gegenstueck zu Lisp/vf_spec.lsp) bleibt unveraendert in vf_spec_export.py.

Zusaetzlich: pruefe_flachen_freitext schlaegt jetzt hart fehl, wenn
generierter Freitext (quelle/beschreibung) ein rohes Anfuehrungszeichen
enthaelt - der Lisp-seitige Flach-JSON-Leser (ssg-cfg-parse-value) kennt
keine Escapes und wuerde daran die Zeichenkette (und damit die gesamte
restliche Datei) falsch zerlegen.

Byte-identischer Output gegen die Baseline geprueft (beide CLIs, echte
Eingaben); pytest tests/test_vf_spec.py + test_vf_journal_grammatik.py
unveraendert: 2 bekannte, vorbestehende Fehlschlaege, 38 bestanden.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-14 11:59:22 +02:00
y.wang 4418840d5e fix: berechne-alle-winkel Signatur-Nachzug (schon-flach) + HundM05-Menu-Fix nachgezogen
Lisp/vf_standard.lsp: berechne-alle-winkel um Parameter schon-flach
erweitert (Fussabdruck-Korrektur, wenn ein Frame flach statt bei 3 Grad
ankommt) - vf_linienzug.lsp rief die Funktion bereits mit diesem 5.
Argument auf, dieser Commit fehlte im letzten Commit und liess den
Zwischenstand mit Argumentzahl-Mismatch zurueck. tests/test_foerderer.lsp
und tests/test_mubea.lsp ziehen dieselbe Signatur nach (inkl.
berechne-horizontale-mitte, das schon-flach bereits erwartete).
tests/testdata/linienzug_tests*.json aktualisiert passend zum echten
Bau-Ablauf. menu/SSG_LIB.mnu/.cui: TEST_LINIENZUG_STUFE2 im Testmenue
ergaenzt.

Lisp/vf_spec.lsp + lib/vf_spec_export.py: *vsp-menu-start* auf die aktuelle
6-Optionen-Kettenanfang-Zuordnung umgestellt (vorher noch 4 Optionen) -
vsp-journal replayt gegen den LEBENDEN vf-linienzug-modus. Python-Tabelle
bewusst NICHT umgestellt (dekodiert eine eingefrorene Alt-Aufzeichnung).
TEST_HUNDM05 schlaegt trotzdem weiterhin fehl (separates, ungeloestes
Problem - siehe naechster Absatz).

Bekannter offener Fehler: TEST_HUNDM05 baut nach wie vor nicht korrekt -
der Menu-Code-Fix allein reicht nicht. Root Cause nicht abschliessend
geklaert, Uebergabe an Kollegen fuer Logik-Review vorgesehen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-14 08:43:54 +02:00
y.wang 0a1d21d8c5 fix: VF-Linienzug 100%-Wiederherstellung aus e76e24e abgeschlossen
Restauriert alles aus e76e24e, das nach dem Reset auf master fehlte oder nur
teilweise wiederhergestellt war, und mit dem Kollegen-Umbau abgeglichen:

- vf_core.lsp: Radio-Button-Dialoge fuer Anlagen-Typ/Linienzug-Modus
  (vfc-dialog-typ-waehlen/-linienzug-modus-waehlen) + Zurueck-Schleife im
  c:VarioFoerderer-Dispatcher
- Vario-Kurve/GF-Bogen-Erkennung am Kettenanfang: vfl-eingang-modus-bestimmen
  threaded durch vfl-vf-eingang-bauen/vfl-vf-einheit/vfl-vf-einheit-abschluss,
  inkl. Punkt-7-Winkel/Hoehen-Tabelle fuer reduzierten Eingang
- Modus 2: Lauf-Anfang/Lauf-Abschluss (offener Anfang/Ende, GF-Verteilung
  "alles Auslauf", Kletter-zu-kurz-Fallback) + Separator VOR/NACH bei
  GF-Geraden
- Systemischer Bug behoben: mehrere Wizard-Dialogfunktionen nutzten noch
  start_list/add_list (Dropdown) gegen laengst auf boxed_radio_column
  umgestellte DCL-Dialoge (vflw-gruppe-as/-gefaelle/-variokurve/
  -winkel-seite-impl, vflw-seg-linie-m2/-m3/-bogen-impl,
  vfl-glied-gf-bogen/-vario/-as-es-dialog)
- Zentraler Abbruch-Trigger in vfl-in-value/-value-p wiederhergestellt (ohne
  ihn wirkte der Zurueck/Abbrechen-Button in keinem Wizard-Dialog)
- vfl-frage-ist-endpunkt/-ist-kettenende als eigene Funktionen mit
  Wizard-Dialog extrahiert (vorher Konsolen-Duplikate ohne Dialog-Hookup)
- 3 vfs-vf-entry-Aufrufe mit falscher Argumentzahl gefixt (akute
  Absturz-Bugs in Modus 2/3)
- Tote Funktion vflw-gruppe-horizontal-impl entfernt (Tiles nicht mehr im
  DCL vorhanden)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-11 18:26:48 +02:00
y.wang 4a444b4858 feat: vf_spec_export.py (Python-Vorwaerts-Emitter) fuer Linie-GF nachgezogen
Spiegelt die drei neuen Felder (laenge_modus/sep_vor/sep_nach/steigend_modus)
aus Lisp/vf_spec.lsp im Python-Pendant (SpecSchreiber.sektion) - haelt die
"zwei unabhaengige Implementierungen pruefen sich" Architektur des Kollegen
fuer den Schreib-Pfad synchron. tests/test_vf_spec.py: LISP_FAELLE um die
2 neuen Testfaelle ergaenzt, Faelle-Zaehler 7 -> 9.

Bewusst NICHT angefasst: der Rueckwaerts-Decoder (SpecLeser, spec_aus_journal)
- die 5 echten HundM-Ketten (hm_recformat.json) wurden vor dieser Erweiterung
aufgezeichnet und haben daher keine Separator-Antworten fuer ihre Linie-GF-
Sektionen. Der Rundlauf-Test TestRundlauf.test_verlustfrei wird fuer Ketten
mit Linie-GF dadurch rot - eine inhaerente, bewusst in Kauf genommene Folge
der neuen Pflichtfragen im interaktiven Ablauf, kein Fehler im Schreiber
(ausfuehrlich kommentiert direkt an der Aenderung in vf_spec_export.py).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-11 14:25:50 +02:00
m.stangl 90bfbd89b6 BTMT Beladung/Entladung als Ein-/Ausgang des Materialfluss-Graphen erkannt
export_graph.py behandelte BTMT-Stationen bisher wie ein generisches
Durchlaufelement mit zwei Achs-Enden - dadurch entstanden mehrere,
teils widerspruechliche Kanten und die Rolle blieb "Element" statt
"Eingang"/"Ausgang". BTMT hat aber physisch nur EINEN Anschluss zum
Foerdersystem (sitzt als dritter Zweig einer Weiche auf der Kreisel-
Durchgangsbahn, der Kreisel bleibt dabei ein einzelner Verteiler-Knoten):
Beladung speist fest Material ein (kein Vorgaenger im Fluss), Entladung
nimmt es fest raus (kein Nachfolger).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-10 15:29:08 +02:00
m.stangl 47724fcfe2 TrackIds von VF/GF-Strecken um AS-/ES-Kettenenden ergaenzt
write_separatorliste_merkmale liess bisher nur "SEP"-Eintraege der
sepliste in die "TrackIds"-Spalte einfliessen; die AS-/ES-Ausschleus-
/Einschleuselemente an Anfang und Ende der Kette fehlten dadurch,
obwohl sie beim Kreisel (compute_kreisel_umlauf) bereits Teil von
dessen TrackIds sind. Jetzt werden alle sepliste-Eintraege (AS, SEP,
ES) in Baureihenfolge aufgeloest.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-10 15:18:55 +02:00
m.stangl 28dc3b4301 list_trackids aus Merkmalen in eigene CSV-Spalte "TrackIds" verschoben
Statt eines JSON-Merkmals bekommen VF_n/GF_n/Kreisel jetzt eine eigene
CSV-Spalte "TrackIds" (nach "Nachbarn", vor "Fehler") mit der Reihenfolge
der Separator-/BTMT-/AS-ES-/Weichen-TeileIds entlang der Strecke bzw. um
den Kreisel - analog zur bestehenden "Nachbarn"-Spalte statt versteckt im
Merkmale-JSON. Referenz-CSV fuer den Omniflo-Test an den neuen Header
angepasst.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-10 15:07:31 +02:00
m.stangl 3c0900a02b CSV-Bezeichnung von VF/GF/Kreisel/Eckrad nutzt Anwender-Attribut statt nur Nummerierung
Die Spalte "Bezeichnung" verwendet jetzt das in BricsCAD frei editierbare
Attribut "Bezeichnung" des Blocks, falls gesetzt - sonst wie bisher die
generierte Standardbezeichnung ("VarioFoerderer :3" usw.). Damit laesst
sich ein in der Zeichnung umbenanntes Element im CSV-Export wiedererkennen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-10 14:52:03 +02:00
m.stangl bfd95ea725 Kreisel-Separatorliste (list_trackids) im CSV-Export ergaenzt
Kreisel bekommen wie VF_n/GF_n ein Merkmal mit der Reihenfolge aller
Separator-/BTMT-Beladung-/BTMT-Entladung-TeileIds entlang der Bahn,
sortiert nach Winkel um die Kreiselachse (Start bei 0 Grad in
Drehrichtung DREHRICHTUNG) - nutzt dieselbe Umlauf-Logik, die bisher
nur die "Nachbarn"-Spalte gespeist hat. Merkmal-Schluessel einheitlich
auf "list_trackids" umbenannt (vorher "Separatorlist" bei VF/GF).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-10 14:41:25 +02:00
s.ayadi 061a878346 Separatorliste wird in jedes json Attribut der ILS Strecke geschrieben, um die Liste der Ids in der richtigen Reihenfolge aus Bricscad direkt zu erhalten 2026-09-10 11:30:40 +02:00
m.stangl 27ae3df056 CSV-Export: Nachbarschaft/bbox fuer Kreisel-Kreisel-Weichen, sepliste-Ketten und Separatoren repariert
Kreisel-Kreisel-Weichen fehlten bisher im Kreisel-Umlauf (compute_kreisel_umlauf),
wodurch angrenzende Separatoren auf falsche/fehlende Nachbarn zeigten. Die
kreisel_bounds-Matching-Box ignorierte ausserdem die tatsaechliche Kreiseldrehung
(faelschlich als achsparallel angenommen), was bei gedrehten langen Kreiseln
(Mubea Kreisel 0002) zu falschen Nachbarschaften fuehrte.

Die sepliste-XDATA (AS/SEP/ES-Reihenfolge je VF_n/GF_n) wurde nie ans Python-Item
durchgereicht - die gesamte Ketten-Nachbarschaftserkennung lief dadurch ins Leere.
Nach dem Beheben entstand eine Doppelzaehlung: die in einer Kette verpackten
Separatoren existieren bereits als echte Proxy-INSERTs (csv:sep-proxies-erzeugen);
build_separator_kette_items erzeugte zusaetzlich eigene Zeilen aus der sepliste.
Umgebaut zu map_separator_kette_items: ordnet die sepliste-Reihenfolge den
vorhandenen Proxy-Items zu (Match ueber Wrapper-ID + INSERT-Punkt) statt neue
Zeilen zu erzeugen - keine Doppelzaehlung mehr, Nachbarn korrekt gesetzt.

Ausserdem: vla-getboundingbox scheiterte in einem realen Export bei ALLEN
Bloecken (fehlende bbox ueberall), der Fehler wurde bisher still verschluckt.
REGENALL vor der Export-Schleife behebt das; eine neue Diagnose (exp-bbox-fail)
meldet kuenftige Ausfaelle statt sie zu verschlucken. Freie/eingebettete
Separatoren ohne bbox bekommen zusaetzlich einen Fallback aus einer konfigurierbaren
Symbol-Groesse (cfg/export.cfg [Boundingbox] separator_box_*).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-10 09:41:02 +02:00
m.stangl 3698c8982c Sepliste-XDATA fuer Separator/AS/ES-Reihenfolge + Unit-Tests, makunbound-Fix
Sammelt beim Bau von VF_n/GF_n-Ketten die Baureihenfolge der Separator-/
AS-/ES-Sub-Bloecke vor dem Block-Sweep und schreibt sie als XDATA auf den
fertigen Wrapper (ssg_ks_insert.lsp); export.lsp liest sie fuer das neue
"sepliste"-Feld im CSV-Export, export_neighbors.py nutzt es als Fallback
zur BBox-Kollisionspruefung. Dazu Unit-Tests fuer die reinen Serialisierungs-
funktionen (Chunking, Roundtrip) in test_unit.lsp.

Ausserdem: makunbound (existiert nicht in BricsCAD-AutoLISP) aus
test_run_all.lsp entfernt - verursachte Laufzeitfehler bei
SSG_RUN_ALL_TESTS_EXPORT/_OFFEN.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 20:36:42 +02:00