diff --git a/doc/TODO-modus2-achsenweise-bilanz.md b/doc/TODO-modus2-achsenweise-bilanz.md new file mode 100644 index 0000000..d6dcca0 --- /dev/null +++ b/doc/TODO-modus2-achsenweise-bilanz.md @@ -0,0 +1,122 @@ +# TODO: Modus-2-Solver auf achsenweise Laengen-Bilanz umstellen + +Status: **Vorschlag / noch nicht umgesetzt** (2026-09-18). Mit dem Entwickler zu +besprechen, bevor der Solver angefasst wird. Reiner Plan - kein Code geaendert. + +## Kurzfassung + +Der Modus-2-Solver (`vf-linienzug-modus2`, Phase B, `Lisp/vf_linienzug.lsp` +ca. Zeile 9915-10145) modelliert den VarioFoerderer-Lauf als EINE gerade +Bruecke. Bei einer gefalteten Kette (U-Form: hoch, quer, runter) zieht er die +festen Fussabdruecke aus der falschen Achse ab: **die erste GF wird zu lang, +die Kletterstrecke zu kurz, Motor/ES landen falsch bzw. fehlen.** Der Fix: +Laengen pro Schenkelrichtung bilanzieren statt als eine skalare Spanne. + +Das ist ein **dokumentiertes v1-Naeherungs-Limit**, kein Regressionsfehler - +die Umbauten SEGS/Alert-Box/Mini-Filter haben Phase B nicht angefasst. + +## Symptom (echter Testfall: results/test_modus2.dxf, logs/vfl_modus2.dbg) + +U-Form-Kette, 6 Segmente, EIN VF-Lauf (Seg 2-6; die zwei Vario-Kurven zaehlen +als VF-Mitglieder): + +``` + ^ Seg2 VF (1500 mm) + | Seg1 GF (2500 mm) + start Seg4 VF (2257 mm) + | +-----------------------+ + | Seg3 Kurve Seg5 Kurve + | | + | Seg6 VF (3800 mm) + + v + Ziel (3520, 180) +``` + +Ergebnis: `SOLL-ENDE=(3520, 180, 2000)`, `IST-ENDE=(3333, 2825, 2080)` -> +`dY=+2645 mm`, `dZ=+80 mm`. Die erste GF wird zu lang erzeugt; die +Kletterstrecke (Seg 6) endet ~2645 mm zu frueh; Motorstation, das +VF-Kurven-Zwischenstueck und das ES-Element sitzen falsch bzw. fehlen. + +## Ursache, praezise lokalisiert + +Der Solver waehlt die laengste VF-Gerade (Seg 6, 3800) als Kletterer, der die +ganze Hoehe traegt, und rechnet die geneigte Laenge skalar: + +```lisp +;; vf_linienzug.lsp:9990 - Solver bekommt die SKALARE Spanne +(setq wahl3 (vfl3-waehle-winkel climber-span dH-adj feste-vf)) +;; feste-vf = Umlenk + Separator (+ Motor) -- ein fester Fussabdruck + +;; vf_linienzug.lsp:10070 - Kletterer bekommt br-lvf proportional +(setq this-lvf (max clamp (* br-lvf (/ (caddr seg) climber-span)))) +;; br-lvf = climber-span MINUS feste-vf +;; ABER: Umlenk/GF1/Motor sitzen physisch in ANDEREN Schenkeln +;; (GF1+Umlenk am Eingang entlang hz=90, nicht in Seg6/hz=-90) +``` + +**Der Modellbruch:** `br-lvf` = `climber-span` minus die festen Fussabdruecke +(Umlenk 500 + Separator 300 + GF1 `gf-total` + Motor). Diese Teile liegen aber +in den ANDEREN U-Schenkeln - nicht in Seg 6. Der Solver zieht sie trotzdem von +Seg 6s 3800er-Spanne ab. Weil GF1 = "alles am Einlauf" gewaehlt war, ist +`gf-total` gross -> Seg 6 wird um genau diese Summe (~2645 mm) zu kurz. Bei +einer GERADEN Bruecke liegen alle Teile auf derselben Achse - dann stimmt die +skalare Rechnung. Bei der U-Form nicht. + +Zusaetzlich: die flache Zone nimmt GENAU EIN Uebergangspaar an +(`hor-pairs = 1`, Zeile 9950), obwohl die U-Form zwei 90-Grad-Kurven plus +Kletterstrecke mischt -> daraus die Rest-dZ von +80 mm. + +## Beleg: dokumentiertes Limit, kein Regressionsfehler + +| Kommentar-Fundstelle | Aussage | +|---|---| +| `vf_linienzug.lsp:9073-9075` | "v1-Naeherung Laenge ... feinere Laengen-Reservierung -> spaeter" | +| `vf_linienzug.lsp:9923-9926` | Modell explizit "EIN Vario mit Horizontal-Mitte" - eine gerade Bruecke ist die Design-Annahme | +| `vf_linienzug.lsp:9948-9950` | "flache Zone hat GENAU EIN Uebergangspaar ... unabhaengig von der Zahl der Fueller/Kurven" | + +Verifiziert: SEGS-Umbau, Alert-Box und Mini-Filter haben Phase B (den Solver) +nachweislich nicht veraendert. Die Abweichung ist vorbestehend. + +## Vorgeschlagener Umbau in sicheren Etappen + +Nach jeder Etappe eine BricsCAD-Sichtpruefung (Geometrie ist nur interaktiv +pruefbar). + +1. **Regressionsnetz zuerst.** Eine bekannt-gute GERADE Modus-2-Kette + (GF...VF...GF, eine Achse) bauen und mit `lib/dxf_vf_abbild.py + --schreibe-referenz` als Referenz einfrieren. Schuetzt den funktionierenden + Normalfall, bevor die Bilanz umgebaut wird. +2. **Schenkel erkennen.** Den VF-Lauf (Seg `vf-start`..`vf-ende`) an den + Vario-Kurven in Schenkel aufteilen - jeder Schenkel eine Fahrtrichtung (hz). + Pro Schenkel: Summe der VF-Geraden-Laengen, welche festen Teile darin liegen. + Neue Datenstruktur statt der skalaren `climber-span`. (ersetzt die + climber/nonclimber-Schleife 9935-9947) +3. **Fussabdruecke dem richtigen Schenkel zuordnen** (Risiko-Kern). Umlenk/GF1 + nur vom Eingangs-Schenkel abziehen, Motor/GF2/ES nur vom Ausgangs-Schenkel - + nicht pauschal von der Kletterstrecke. Reicht ein Schenkel nicht, verteilt + sich die Restneigung auf weitere Schenkel. (feste-vf/dH-adj 9978-9989, + this-lvf 10070, fill-len 10094-10104) +4. **Uebergangspaare pro Kurve** statt pauschal eins. `hor-pairs` aus der + tatsaechlichen Schenkel-/Kurvenzahl ableiten - behebt die dZ-Restabweichung. + (9950, dH-adj-Bildung 9982-9989) +5. **Verifikation.** Regressionsnetz aus Schritt 1 muss gruen bleiben (gerader + Fall unveraendert). U-Form interaktiv: erste GF korrekt kurz, + Kletterstrecke trifft den Zielpunkt, Motor + Kurven-Zwischenstueck + ES an + der richtigen Stelle. SEGS-Journal bleibt formgleich. + +## Risiko-Einschaetzung + +- Der GERADE Fall funktioniert heute - er ist der Normalfall, fuer den der + Solver gebaut ist. Ein Umbau der Kern-Bilanz kann ihn brechen -> Schritt 1 + (Referenznetz) ist nicht optional. +- Geometrie nur interaktiv in BricsCAD pruefbar -> mehrere Runden noetig. +- Gut eingegrenzt: der Umbau bleibt in Phase B von `vf-linienzug-modus2` + (~9915-10145). Klassifizierung, SEGS-Journal, Doppelklick-Replay und die + anderen Modi bleiben unberuehrt. + +## Zwischenloesung (falls der Umbau nicht sofort kommt) + +Gefaltete VF-Laeufe (mehr als eine Achsenrichtung im VF-Bereich, z.B. U-Form) +erkennen und mit klarer Meldung abweisen, statt still falsche Geometrie zu +bauen - analog zur bereits vorhandenen "nur EIN VF-Lauf"-Abweisung +(`vfl-m3-vf-lauf-alert`). Macht das Limit ehrlich sichtbar, kleiner Eingriff.