Der CAD-Lauf belegt die Schritte 0-4 jetzt auch EMPIRISCH:
results/test_hundm05.dxf entstand nach dem Umbau, das Ergebnis-JSON von
11:18 davor - fuer alle 5 Ketten sind ALLE 37 Attribute identisch,
inklusive der reihenfolgeabhaengigen Komma-Listen L_VF_m, L_GF_m, GF_WINKEL
und ANTRIEBFAHRTRICHTUNG. TEST_VF_SPEC: 28 PASS / 0 FAIL.
results/test_linienzug.dxf zeigt eine vollstaendige Kette (AS+ES, Motor,
Umlenkung, 2 Vario-Kurven, 22 Bausteine, HOEHE_VON = HOEHE_BIS = 4500 bei
DELTA_H 0).
Schritt 5a/5b - vfl-vf-eingang-bauen und vfl-vf-ausgang-bauen: beide Bloecke
(GF1 + Einlauf-Separator + Umlenkstation bzw. Motorstation + GF2) enthalten
keine Frage und sind zusammenhaengend, der Umzug ist wortwoertlich
(Zeilenvergleich: 0 Zeilen entfernt, nur zwei Koepfe, zwei Aufrufe und zwei
"frame)" neu). Die Auswahl gf2-eff (ziel-gf2 im Kettenende-Modus, sonst
L_GF2-bau) bleibt BEWUSST an der Aufrufstelle - genau dort entsteht sonst
still die falsche GF2 hinter dem Motor. Der Separator-Zaehler und die
vfl-acc-*-Aufrufe bleiben an derselben Stelle in derselben Reihenfolge.
Regressionsnetz, damit die restlichen Schritte nicht blind gemacht werden
muessen:
- lib/dxf_vf_abbild.py (neu): liest eine Testzeichnung streamend und bildet
je Kette Attribute, Bausteinzusammensetzung und Einfuegepunkt ab. Ketten
werden ueber den EINFUEGEPUNKT der Spec zugeordnet, nicht ueber den
Blocknamen - die VF-Nummer beginnt in jeder neuen Zeichnung wieder bei 1.
ID und Bezeichnung sind aus dem Vergleich heraus (pro Zeichnung neu).
--referenz vergleicht (Exit 1 bei Abweichung), --schreibe-referenz frischt
die Referenz nach einem GEPRUEFTEN Lauf auf.
- tests/reference/hundm05_attribute.json (neu): die Referenz, erzeugt aus dem
geprueften Lauf - also dem Stand, der attributgleich mit dem Zustand VOR
dem Umbau ist.
- tests/test_vf_geometrie.py (neu, 8 Tests): vergleicht automatisch, mit
einem eigenen Test nur fuer die Komma-Listen (das einzige, was eine
vertauschte vfl-acc-*-Reihenfolge sichtbar macht) und einer Gegenprobe,
dass eine verfaelschte Referenz auch erkannt wird.
Das faengt, was der Ergebnis-Record NICHT sieht: er sagt "executed, kein
Prompt, Journal aufgegangen", aber nichts darueber, ob dieselbe Geometrie
herauskam. Ablauf ab jetzt pro Schritt: umbauen -> TEST_HUNDM05 (save dxf)
-> pytest tests/test_vf_geometrie.py.
Offen bleiben 5c, 6, 8, 9, 10 (Schleifenrumpf der VF-Einheit, Daten-Executor,
Einheit-Abschluss, Kettenebene je Glied, vfl-spec-ausfuehren). Die vier
haengen zusammen: 6 und 10 brauchen den aufgeteilten Schleifenrumpf. Halb
umgebaut waere der Code schlechter dran als vor oder nach dem Umbau, darum
als ein Schritt mit CAD-Lauf davor und danach.
Verifiziert: 117 pytest-Tests gruen, vf_linienzug.lsp lint-sauber.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ergebnis des EXPORTCSV/EXPORTSIVAS-Laufs auf der Mubea-Zeichnung NACH dem
ID-/ZUORDNUNG-Fix (2168410), abgelegt nach der Konvention von
tests/reference/ (<basis>_export.csv + <basis>_sivas.csv, wie
foerderer_tests/gefaellestrecke_tests/kreisel_tests/omniflo_tests).
mubea_export.csv belegt beide reparierten Punkte:
- 119 Zeilen mit 119 unterschiedlichen TeileIds, lueckenlos 0001-0119.
Vorher teilten sich Gefaellestrecke/VF/Kreisel und die aus ihnen
erzeugten Separator-Kopien 26 IDs (0001-0026).
- Jeder der 20 Gefaellestrecken ist genau ein Separator zugeordnet
(0016-0035), den VF-Strecken 0013/0014/0015 sind es 2/5/4. Nur die 7
tatsaechlich freistehenden Separatoren haengen noch an einer
Kreiselhaelfte (0001-R, 0002-L, 0010-R). Vorher landeten 26 in VF/GF
VERPACKTE Separatoren bei einer Kreiselhaelfte, weil die Python-seitige
Boundingbox-Suche die bekannte Wrapper-Zuordnung ueberschrieb.
tests/test_export_ids.py laeuft gegen diese Datei gruen (gegen die alte,
fehlerhafte CSV meldete er alle 26 Dubletten).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nachbarschaft wird jetzt in drei getrennten Gruppen geprueft statt global
ueber alle Elemente: Kreisel/Eckrad gegeneinander, Kreisel/Eckrad gegen
Gefaellestrecke/Foerderer/Strecke-Modul (diese drei nicht gegeneinander),
und Omniflo-Elemente gegeneinander (rasterbasiert vorgefiltert nach x/y-
Koordinate). Ersetzt die bisherige shapely-STRtree-Loesung durch reines
Python, da die shapely-Abhaengigkeit den regulaeren CSV-Export in der von
BricsCAD genutzten Python-Umgebung brechen konnte.
Neue Spalte "Fehler" markiert Elemente mit zu wenigen Partnern
("unverbunden"/"nur ein Partner") je nach TeileArt-Mindestanzahl.
Ausserdem: SSG_RUN_ALL_TESTS-Absturz nach TEST_KREISEL behoben (ssg-start/
ssg-end nutzten flache globale Variablen statt eines Stacks, wodurch
verschachtelte Aufrufe den *error*-Handler dauerhaft korrumpierten) und
FILEDIA=0 um den DXFOUT-Kommandozeilenaufruf ergaenzt.
Neue Spalte "Nachbarn" (kommaseparierte TeileId-Liste) in export_csv.py:
zwei Elemente gelten als benachbart, wenn ihre Bounding-Boxes (x/y-Ebene)
sich ueberschneiden. Toleranz konfigurierbar in mm ueber cfg/export.cfg
[Nachbarschaft] -> toleranz_mm, siehe lib/export_neighbors.py.
Nur EXPORTCSV betroffen, EXPORTSIVAS bleibt unveraendert.
shapely als neue Abhaengigkeit in requirements.txt ergaenzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nur EXPORTCSV betroffen, EXPORTSIVAS bleibt unveraendert:
- Position/Boundingbox: Bounding-Box je Block per vla-getboundingbox
(Lisp/export.lsp, csv:get-bbox), Mittelpunkt und Ausdehnung x/y/z.
- Planquadrat: aus x/y-Koordinate berechnet nach cfg/export.cfg
[Planquadrate] (Schrittweite, numerisch/alphabetisch je Achse,
alphabetische Zaehlung mit Excel-Spalten-Umlauf Z->AA), siehe
lib/export_planquadrat.py.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
s.ayadi
m.stangl