fix: Laengenbilanz des gefalteten Modus-2-Laufs (U-Form)

Gefaltete VF-Laeufe wurden zu kurz gebaut, weil der Solver Posten dem
falschen Schenkel zurechnete. Vier Aenderungen, alle nach demselben
Leitsatz: die letzten freien Groessen folgen der GEMESSENEN Ist-Lage,
nicht einer vorab verteilten Gesamtplanung.

1. vfl-zsolve-schluss-ziel (neu): endet der Lauf auf einem flachen
   Fueller, werden RICHTUNG und LAENGE gemeinsam gegen den Zielpunkt
   geloest statt nur die Laenge. Geschlossene Loesung ueber
   A = sqrt(|D|^2 - P^2), hz = Winkel(D) - atan2(P, A); C und P sind
   von hz unabhaengig, daher ohne Iteration. Bisher uebernahm der
   Solve die Richtung aus dem gezeichneten Pfad - ein Querversatz der
   realen Eck-Bauteile war damit prinzipiell unerreichbar, weil eine
   Laenge die Kette nur entlang ihrer Achse verschiebt.

2. Eingangs-Hardware bei gefaltetem Lauf: Umlenkstation + Separator
   stehen auf dem Eingangs-Schenkel und verbrauchen die Kletterspanne
   nicht; ihr Laengenanteil wird der Spanne wieder zugeschlagen.
   feste-vf bleibt unveraendert - sein sin3-Hoehenanteil ist real.

3. kletter-ende-fp: endet der Lauf auf einem KLETTERER, gibt es keinen
   Schluss-Fueller, der Motorstation + Separator + ES abzieht - sie
   standen in keinem Budget. Nur bei flacher Zone, Pfadende und
   vorhandenem ES, sonst sind sie bereits anderweitig verbucht.

4. Nachrechner wieder aktiv (8 statt 4 Runden): GF1 steht im Budget,
   aber im Eingangs-Schenkel. Die Kollision mit filler-A-len, wegen
   der er abgeschaltet war, ist entfallen.

3 und 4 wirken NUR gemeinsam - die Betraege heben sich teilweise auf,
eine einzeln eingebaute Korrektur verschiebt den Fehler bloss in die
andere Richtung (GF1 1636.9 - (Motor+Sep+ES) 1235.1 = 401.8 mm).

Gemessen am selben Pfad: 9 Grad 0.56 mm, 12 Grad 0.7 mm quer (vorher
1424 bzw. 934 mm), dZ 0.1 mm. Beide Modus-2-Regressionsketten weiter
OK; TEST_UNIT 904/904 mit 7 neuen file-freien Tests.

doc/todo.md: Punkt "Modus-2-Solver: achsenweise Laengen-Bilanz" ist
damit erledigt. Die Detaildatei bleibt liegen, weil vier Kommentare in
vf_linienzug.lsp auf ihren Pfad verweisen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-10-29 11:41:35 +01:00
parent 9fb43b3881
commit 35ebee1e88
6 changed files with 746 additions and 53 deletions
-11
View File
@@ -11,17 +11,6 @@ Stand: 2026-10-26. Wird woechentlich (freitags) mit der Doku geprueft, siehe
## 1. VarioFoerderer / Linienzug
- **Modus-2-Solver: achsenweise Laengen-Bilanz.** Gefaltete VF-Laeufe (U-Form)
werden falsch gebaut (erste GF zu lang, Kletterstrecke zu kurz, Motor/ES
falsch), weil der Solver die festen Fussabdruecke skalar von EINER Spanne
abzieht. **Teilweise erledigt 2026-10-26** (ce4ad0f): AS-Element,
Abschlussbogen+Motorstation und die Eck-Differenzen werden seitdem dem
Segment zugeschlagen, auf dem sie physisch stehen (`vfl-eck-extra` je
Segmentindex, `as-along-fix` auf `vf-start`, `abschluss-fp` auf `vf-ende`) -
das ist die achsenweise Idee fuer diese Posten. SKALAR bleiben `feste-vf`
(Umlenkstation + Separator) und `gf-total` (GF1), und genau die verursachen
den U-Form-Fehler. Als Zwischenloesung zumindest gefaltete Laeufe mit
Meldung abweisen. -> `doc/todo/modus2-achsenweise-bilanz.md`
- **VF-Linienzug ohne GUI/Konsole, Stufe 2** (Funktionstrennung): eigener,
separat abzuarbeitender Auftrag mit Schritt-Tabelle. Schritte 5c, 6, 8, 9,
10 offen (u.a. `vfl-spec-ausfuehren`). Schritt 11 war zurueckgestellt, bis