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

Modus-2-Solver: achsenweise Laengen-Bilanz

Status: ERLEDIGT 2026-10-29. Gefaltete Laeufe (U-Form) werden gebaut; am selben Pfad gemessen 0.56 mm (9 Grad) und 0.7 mm (12 Grad) quer, beide Regressionsketten weiter OK. Der Abschnitt "Stand 2026-10-29" und der "Nachtrag 2026-10-29" am Ende beschreiben Loesung und Herleitung.

Die Datei bleibt BEWUSST liegen, obwohl der Auftrag abgeschlossen ist: vier Kommentare in Lisp/vf_linienzug.lsp verweisen auf diesen Pfad (Suche nach modus2-achsenweise-bilanz). Sie dokumentiert damit nicht mehr einen Plan, sondern WARUM der Solver so bilanziert, wie er es tut - einschliesslich der fehlgeschlagenen Versuche, damit sie niemand ein zweites Mal unternimmt.

Alles unterhalb dieser Zeile ist der urspruengliche Plan von 2026-09-18 und seine Zwischenstaende. Die dort genannten Zeilennummern sind veraltet; Phase B von vf-linienzug-modus2 findet man per Suche nach climber-span. Die damals vorgeschlagene Zwischenloesung (gefaltete Laeufe mit Meldung abweisen) wurde NICHT umgesetzt und ist gegenstandslos - solche Laeufe funktionieren jetzt.

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.

---

Stand 2026-10-28: Fueller-Seite geloest, Solver-Seite offen

Geloest und gemessen

vfl-m2-eingang-fp: GF1 + Separator + Umlenkstation + Uebergangsbogen stehen auf dem Segment vf-start. Ist dieses Segment ein FUELLER (der Kletterer liegt hinter einer Kurve), bekam der Fueller bisher die volle Restlaenge, als staende dort nichts. Jetzt werden sie abgezogen.

Ist das Eingangs-Segment selbst der Kletterer - der gerade Normalfall -, gibt die Funktion hart 0.0 zurueck; der funktionierende Fall kann sich also nicht aendern. Gemessen am U-Form-Testfall: Querabweichung 8005 -> 1424 mm, Segment 1 danach auf 0,2 mm genau belegt.

Noch offen: der Solver rechnet GF und Stationen gegen die falsche Achse

Rest 1424 mm. Segment 5 (Kletterer) legt 6475,5 mm zurueck, verfuegbar waeren 7899,8 - der Solver reserviert dort Platz fuer Umlenkstation, Separator und den GF1-Anteil, die auf Segment 1 stehen.

Fehlgeschlagene Versuche (nicht wiederholen)

Drei Anlaeufe am 2026-10-27/28, jeder an einer anderen Kopplung gescheitert:

1. feste-vf kleiner uebergeben. Geht nicht: feste-hz fliesst in vf-winkel-AB (vf_standard.lsp:241/245) sowohl als feste*cos3 in die LAENGE als auch als feste*sin3 in die HOEHE. Die Hoehe ist real - die Teile senken die Kette ab, egal auf welchem Schenkel sie stehen. Nur der Laengenanteil darf verschoben werden.
2. Spanne vorab korrigieren und iterieren. Geht nicht direkt: vfl-zsolve-winkel-waehlen enthaelt die WINKELFRAGE an den Nutzer - eine Iteration wuerde mehrfach fragen. Und die Korrektur ist pro Winkel verschieden, weil jeder Winkel ein anderes L_GF ergibt.
3. Stiller Nachrechner nach der GF-Verteilungsfrage (Code vorhanden, per (setq nachrechnen-k 4) deaktiviert). Technisch sauber: kein Dialog, Fragenfolge und Journal unveraendert, Konvergenz in 4 Runden (3278 -> 4372 -> 4737 -> 4859 -> 4899 mm). ABER er kollidiert mit filler-A-len: dieser Fueller belegt im Kletter-Segment genau den Platz, den das halbe GF1 dort frei laesst. Nimmt man GF1 aus der Kletterer-Spanne heraus, wird Fueller-A trotzdem gebaut - zusaetzlich zum echten GF1 auf demselben Segment. Gemessen: Fueller nach der Umlenkstation -369 mm (auf 100 geklemmt), Kette 746 mm daneben. Kleinerer Endfehler, aber entartete Geometrie - deshalb zurueckgenommen.

Daraus fuer den naechsten Anlauf

Der Nachrechner ist vermutlich der richtige Weg, aber filler-A-len muss mitbehandelt werden: er gehoert zur Annahme "GF1 liegt im Kletter-Segment" und darf bei gefaltetem Lauf nicht mehr entstehen. Wer das angeht, sollte beide Mechanismen zusammen betrachten, nicht nacheinander.

Testfall vorhanden: U-Form 5855 / 270 / 7806 mm (Kletterer hinter zwei 90-Grad-Kurven), Soll-Querabweichung ~0, Stand heute 1424 mm. Die beiden geraden Referenzketten in c:TEST_LINIENZUG_MODUS2 schuetzen den Normalfall.

---

Stand 2026-10-29: Eingangs-Segment exakt, Kletterer-Segment offen

Zusaetzlich geloest (gegenueber dem Stand vom 2026-10-28)

Fueller-A entfaellt bei gefaltetem Lauf, und vfl-m2-eingang-fp zieht seitdem br-gf1 ab statt gf-total. Beides gehoert zusammen:

filler-A-len fuellt den Platz, den ein halbiertes GF1 auf DERSELBEN Achse frei laesst - er gehoert zur Annahme "GF1 und GF2 liegen auf einer Geraden". Bei gefaltetem Lauf wurde er auf dem Eingangs-Segment ZUSAETZLICH zu GF1 gebaut; zusammen mit GF2 im Kletterer-Schenkel entstanden damit 1.5 x gf-total Gefaellestrecke bei einem Budget von gf-total.

Ergebnis, am U-Form-Testfall nachgerechnet (9 Grad, Verteilung 1/2+1/2):

Segment 1: AS 425,8 + GF1 1370,3 + Sep 299,6 + Umlenk 499,3
           + Bogen 199,9 + Fueller 3153,7           = 5948,6 mm
Budget:    5855 + 93,8 (Eck-Korrektur)              = 5948,8 mm

Das Eingangs-Segment ist damit auf 0,2 mm exakt belegt, und im Protokoll steht nur noch EIN Fueller statt zwei.

Was offen bleibt

Das KLETTERER-Segment. Gemessen im selben Lauf: Segment 5 belegt 6965,8 mm, verfuegbar waeren 7899,8 - es fehlen 934 mm, exakt die Endabweichung.

Der Solver bekommt als Spanne 7704,16 mm und verplant darin u.a. GF1 (1370,3) sowie Umlenkstation + Separator (798,9) - Teile, die auf Segment 1 stehen. Umgekehrt enthaelt seine Spanne NICHT den Abschluss-Fussabdruck (ab_3 + Motorstation, 695 mm), weil dieser nur von FUELLER-Segmenten abgezogen wird (fill-len) und das Kletterer-Segment keines ist.

Der Restfehler skaliert mit L_GF und damit mit dem gewaehlten Winkel - unabhaengig bestaetigt durch zwei Laeufe auf demselben Pfad:

Winkel	L_GF	Querabweichung
6 Grad	1093	90 mm
9 Grad	2744	934 mm

Praktische Folge: Mit flachem Winkel ist der gefaltete Lauf heute brauchbar, mit steilem nicht.

Hinweis zur Methodik fuer den naechsten Anlauf

Zwei Laeufe sind nur vergleichbar, wenn Winkel UND GF-Verteilung gleich sind. Mehrere Messreihen dieser Sitzung waren nicht deutbar, weil sich zwischendurch der Winkel geaendert hatte und der Restfehler mit L_GF skaliert. Vor einer Aenderung also eine feste Kombination festlegen (Vorschlag: 12 Grad, Verteilung 1/2+1/2) und nur die vergleichen.

---

Nachtrag 2026-10-29: Loesungsansatz vom Nutzer

Der Abschnitt darueber beschreibt den Stand VOR dem folgenden Umbau; er bleibt als Herleitung stehen.

Nutzer-Vorgabe: "nach der zweiten VF-Kurve den passenden Winkel neu aus dem KS_AUS der Kurve und dem Zielpunkt rechnen" und "da GF2 feststeht, steht auch die fuer Auf/Ab verbleibende Laenge fest - passender Winkel plus eine ausgleichende GF".

Das ist die Umkehrung der bisherigen Logik und trifft den Kern: bisher wurde ALLES vorab global verplant und der aufgelaufene Fehler landete am Kettenende. Richtig ist, die letzten freien Groessen aus der GEMESSENEN Ist-Lage zu bestimmen. Je nachdem, was das letzte Segment ist, sind das verschiedene Groessen:

Letztes Segment	feste Groesse	freie Groessen
flacher Fueller	-	Richtung + Fuellerlaenge
Auf/Ab-Koerper (U-Form)	Laenge (aus dem Pfad)	Winkel (diskret) + GF-Ausgleich

Umgesetzt

1. Flacher Fueller als Schlussstueck - neue Funktion vfl-zsolve-schluss-ziel. Bisher loeste vfl-zsolve-es-fueller nur die LAENGE und uebernahm die Richtung aus dem gezeichneten Pfad. Eine Laenge verschiebt die Kette aber nur ENTLANG ihrer Achse - steht der reale Kurvenausgang seitlich NEBEN der gezeichneten Geraden, laeuft die gebaute Achse parallel zur Zielachse und der Querversatz ist unerreichbar. Gibt man die Richtung mit frei, stehen zwei Unbekannte zwei Gleichungen (X und Y) gegenueber, geschlossen loesbar:

D    = Ziel - KS_AUS(letzte Kurve)
A    = sqrt(|D|^2 - P^2)      ; P = Querversatz des ES-Fussabdrucks
fill = A - C
hz   = Winkel(D) - atan2(P, A)

C und P sind von hz unabhaengig, weil vfl-zsolve-es-vektor Vektor und Bezugsrahmen um denselben Winkel dreht - deshalb ist keine Iteration noetig. Scheitert der Solve (Ziel naeher als P), bleibt der bisherige Weg. Unit-Tests: tu-tests-vfl-schluss (file-frei ueber es-block = nil).

2. Eingangs-Hardware bei gefaltetem Lauf - der am 2026-10-28 zurueck- genommene Spannen-Zuschlag ist wieder da. Begruendung fuer die Ruecknahme war die Kollision mit filler-A-len; dieser Blocker ist entfallen, seit Fueller-A bei gefaltetem Lauf gar nicht mehr entsteht. Zugeschlagen wird weiterhin NUR der Laengenanteil (entry-fixed * cos3), nie feste-vf selbst - dessen sin3-Hoehenanteil ist real.

3. Abschluss-Hardware auf dem Kletterer (kletter-ende-fp) - endet der Lauf auf einem FUELLER, zieht vfl-zsolve-es-fueller Motorstation + Separator + ES beim Loesen der Fuellerlaenge selbst ab. Endet er auf einem KLETTERER, gibt es diesen Fueller nicht: die drei Teile werden dort gebaut, standen aber in keinem Budget. Abgezogen wird dasselbe wie in dessen Konstante cc, OHNE den ab_3-Bogen (der steckt in diesem Fall schon in uebergang-fp).

4. GF1-Fremdanteil (Nachrechner wieder aktiv, 8 statt 4 Runden) - gf-total ist ein ERGEBNIS des Winkel-Solves, sein auf dem Eingangs-Schenkel stehender Teil laesst sich dort noch nicht abziehen (Henne-Ei). Der Nachrechner loest bei UNVERAENDERTEM Winkel neu und konvergiert mit Faktor ~1/3.

Der entscheidende Punkt: 3 und 4 wirken nur GEMEINSAM

Posten	im Budget des Solvers	steht real auf dem Kletterer
GF1	ja	nein - liegt im Eingangs-Schenkel
Motor + Separator + ES	nein	ja

Die beiden Betraege heben sich TEILWEISE auf. Wer nur einen davon korrigiert, verschiebt den Fehler bloss in die andere Richtung - genau das war der 746-mm-Befund vom 2026-10-28, der damals wie eine Verschlechterung aussah. Gemessen am 9-Grad-Lauf: GF1 1636.9 - (Motor+Sep+ES) 1235.1 = 401.8 mm, exakt die damalige Restabweichung von 401.7 mm.

Messergebnis

Lauf	vorher	nachher
U-Form 9 Grad	1424 -> 934 mm	0.56 mm
U-Form 12 Grad	-	0.7 mm
Variante A (Vario-Kurve)	OK	OK
Variante B (GF-Bogen)	OK	OK

Zwei verschiedene Winkel auf demselben Pfad - der Restfehler skaliert also nicht mehr mit L_GF, die Bilanz selbst stimmt.

Regression auf dem Weg dorthin (Lehrstueck)

kletter-ende-fp schlug zunaechst auch in Variante B zu und verkuerzte deren Segment 1 um 798.9 mm. Dort ist vf-start = vf-ende = 0: der VF-Lauf besteht aus EINEM Segment, die Segmente 2..5 sind Back-Lauf. Damit ist der Kletterer zugleich Laufende, der Abzug griff - obwohl ohne flache Zone die Motorstation bereits in feste-vf steckt und Separator + ES vom Back-Lauf reserviert werden. Die drei Bedingungen am if (hor-pairs > 0, vf-ende = n-1, es-vorhanden) sind deshalb keine Vorsichtsmassnahme, sondern benennen genau die Faelle, in denen sonst doppelt gebucht wird.

Auffindbar war die Ursache nur, weil Segment 1 von Variante B bei hz=0 liegt: eine Verkuerzung dieses Segments uebersetzt sich 1:1 in dX, und IST - SOLL = (-799.11 | -104.68) aus logs/vfl_modus2.dbg zeigte die reine X-Verschiebung.