dxfmakros/doc/todo/modus2-achsenweise-bilanz.md

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.

Pruefung 2026-10-26: weiterhin OFFEN - der Solver bilanziert noch skalar (climber-span, hor-pairs 0/1), auch die Zwischenloesung (gefaltete Laeufe abweisen) ist nicht eingebaut. Die Zeilennummern unten sind veraltet: Phase B von vf-linienzug-modus2 liegt inzwischen bei ca. vf_linienzug.lsp:11880-12100 (per Suche nach climber-span finden).

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:

;; vf_linienzug.lsp:9990 - Solver bekommt die SKALARE Spanne
(setq wahl3 (vfl-zsolve-winkel-waehlen 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.

---

Stand 2026-10-27 (nach Commit ce4ad0f)

Teilweise entschaerft, Kern bleibt offen.

Die Budget-Arbeit vom 26./27.10. hat genau das Prinzip eingefuehrt, das dieses Dokument fordert - aber nur fuer DREI Posten. Sie werden jetzt dem Segment zugeschlagen, auf dem sie physisch stehen, statt skalar von der Gesamtspanne abgezogen zu werden:

Posten	wie	Stelle
AS-Element	gemessener Fussabdruck, nur vf-start	as-along-fix
Abschlussbogen + Motorstation	nur vf-ende	abschluss-fp
Eck-Differenz (gezeichneter Bogen gegen Bauteil)	Alist je Segmentindex	vfl-eck-korrekturen / vfl-eck-extra

vfl-eck-extra ist dabei bereits die hier geforderte Form: ein Zuschlag je Segment, nicht ein Skalar fuer den ganzen Lauf. Er fliesst in alle vier Budgets (Spannweite, Kletterer, Fueller, Rueckanker).

Skalar geblieben sind genau die zwei Posten, die den U-Form-Fehler verursachen:

• feste-vf (Umlenkstation 500 + Separator 300, ggf. + Motor) - wird in vfl-zsolve-winkel-waehlen als EIN Wert uebergeben
• gf-total (GF1) - bei "alles am Einlauf" gross, und genau diese Summe fehlt dem Kletterer im anderen Schenkel

Das oben beschriebene Symptom (dY = +2645 mm) bleibt daher bestehen. Der naechste Schritt waere, diese beiden ebenfalls dem Segment zuzuordnen, auf dem sie stehen - also dieselbe Umstellung wie bei AS und Motorstation, nur fuer den Lauf-EINGANG.

Hinweis zur Fehlersuche: Seit ce4ad0f meldet die Konsole jeden Zuschlag namentlich (AS-Fussabdruck ... von Segment N abgezogen, Abschluss-Fussabdruck ..., Eck-Korrektur ... auf Segment N). Eine FEHLENDE Zeile ist das Warnsignal - so wurde ein 2,4-mm-Rest gefunden. Fuer die U-Form-Diagnose sind diese Zeilen der schnellste Einstieg.