989ee398ce0bd49164ff6dcbba625b54c139ac24
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 y.wang
|
b709f89404 |
test: U-Form-Faelle, Formkriterium laengs und Reihenanordnung der Linienzug-Tests
Drei neue Modus-2-Testfaelle aus echten Laeufen, ein Kriterium, das eine
heute eingebaute Fehlgeometrie gefunden haette, und ein aufgeraeumtes
Layout der Testketten.
1. Drei U-Form-Faelle (tests/testdata/linienzug_modus2_uform_*.json),
aufgezeichnet mit lib/vf_journal_export.py. Gefaltete Laeufe: der Pfad
wechselt ueber zwei 90-Grad-Vario-Kurven dreimal die Fahrtrichtung, die
Kletterstrecke liegt in einem ANDEREN Schenkel als der Lauf-Eingang -
genau der am 2026-10-29 korrigierte Fall. Variiert werden GF-Verteilung
(alles am Einlauf vs. 1/2+1/2) und Winkel; beides ist noetig, weil die
Verteilung entscheidet, ob ueberhaupt GF im fremden Schenkel steht, und
der Restfehler der alten Bilanz mit L_GF skalierte.
c:TEST_LINIENZUG_MODUS2 ist dafuer tabellengesteuert - ein weiterer Fall
ist jetzt eine Zeile in *tlz-m2-faelle*.
2. RUECKNAHME des Schluss-Solves (vfl-zsolve-schluss-ziel, heute frueh
eingebaut). Er loeste den letzten Fueller gegen Richtung UND Laenge und
traf den Zielpunkt dadurch in X und Y exakt - um den Preis, dass er die
letzte Gerade um 6.15 Grad verdrehte (hz-plan -90 -> -96.15), in der
Zeichnung als schiefer Schenkel sichtbar. Das widerspricht der
Entscheidung vom 2026-10-26: quer MUSS 0 sein, LAENGS DARF ABWEICHEN -
der Hauptstrang bleibt gerade, der seitliche Versatz des ES-Elements ist
dessen Bauform. Die Messwerte von heute (0.56 / 0.7 mm quer) stammen
nicht von dieser Aenderung, sondern von der Laengenbilanz des gefalteten
Laufs (
|
||
|
y.wang
|
cf626d721e |
test: Linienzug Modus 2 als Journal-Replay, Richtungsfrage in den Modus-1-Skripten
Neu: TEST_LINIENZUG_MODUS2 spielt zwei echte Laeufe DERSELBEN Strecke ab -
einmal mit der 90-Grad-Ecke als Vario-Kurve (waagerecht, mit flacher Zone),
einmal als GF-Bogen (geneigt, ohne flache Zone). Beide muessen quer zur
ES-KS_AUS-Achse ~0 und dZ ~0 erreichen; laengs darf um die Ausladung des
ES-Elements abweichen (Leitsatz, doc/VarioFoerderer_Linienzug_Prinzipien.md
Abschnitt 0). Gemessen am 2026-10-27: beide 0.2 mm quer, dZ 0.
Das Paar ist Absicht. Die beiden Varianten laufen durch VERSCHIEDENE Zweige,
und erst ihr Vergleich hat die Fehler dieser Woche sichtbar gemacht - der
ES-Fussabdruck wurde vom falschen Segment abgezogen, was sich nur in der
GF-Bogen-Variante zeigte (878 mm). Einen der beiden zu loeschen nimmt dem
Test seinen Wert.
Anders als die Modus-1-Faelle braucht Modus 2 KEINE Mocks und KEINEN
gezeichneten Pfad: sein Journal traegt einen SEGS-Eintrag mit der kompletten
Segment-Essenz, ist also von den Original-Objekten unabhaengig. Der Test
spielt daher das echte, mit lib/vf_journal_export.py aus der Zeichnung
gelesene Journal ab. Jeder Eintrag fuehrt seine Art mit (PT/STR/REAL/SEGS),
womit die Verschiebe-Anfaelligkeit des Mock-Replays entfaellt.
Dazu: vf-linienzug-modus2 legt die gemessene Abweichung in
*vfl-m2-abweichung* ab (laengs quer dz). Sonst muesste ein Test sie aus der
Konsolenausgabe zurueckparsen.
Ausserdem behoben: beide Modus-1-Testskripte brachen mit
"bad argument type <\"5\"> expected <CONS> at [cdr]" ab. Commit
|
||
 m.stangl
|
399728c7f9 |
fix(tests): Linienzug-Testdaten, HundM05-Zusatzobjekte, Nummernzaehler je Testzeichnung
- TEST_LINIENZUG: seit 1cc163d/cccd362 fragt Modus 1 nach der AS-Seite die optionale Zufuehrungsachse ab. Der Test mockt get* direkt (keine Replay-Queue), die neue Punktfrage verschluckte die naechste Antwort und der Lauf desynchronisierte (FEHLER, 21 Schritte offen). Neuer Schritt-Typ "point_none" (getpoint -> nil) und in beiden Linienzug-Testdaten nach der AS-Seite eingetragen. - test_hundm05.py: Zusatzobjekt-Ergebnisse filterten nur kind "kreisel" - Separatoren/Scanner/BTMT (kind "sensor") fehlten, test_je_objekt_ein_ ergebnis schlug faelschlich fehl. - SSG_RUN_ALL_TESTS: #VF/#GF/#Kreisel/#Eckrad_LetzteNr vor jedem Test auf 0. Der Lauf bleibt im Namensraum des Startdokuments, die Zaehler liefen sonst ueber alle Tests weiter (VF_5/Kreisel12 in frischer Zeichnung) und machten jeden Referenz-Diff von der Testreihenfolge abhaengig. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
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> |
||
|
y.wang
|
23d653c4b3 |
feat: VF-Linienzug Linie-GF - Separator VOR/NACH, Endpunkt/Zielhoehe-Vorwahl, steigende GF (Sonderfall bis 3 Grad)
Auf der neuen Kollegen-Architektur (Stufe 0-2: Spec/Journal/Replay-System
in vf_spec.lsp, Frage-Schale/Bauteil-Trennung) neu aufgebaut, nachdem der
urspruengliche Stand (Commit
|