Files

T

y.wang e1e5fbf0c1 feat: Modus 3 mit optionalem AS/ES, ES-Frage vor dem Bau; Helfer rollenbasiert benannt

WARUM MODUS 3 BLEIBT
Modus 2 und 3 arbeiten beide auf einem gezeichneten Pfad (LINE/ARC), aber sie
loesen verschiedene Aufgaben:
  Modus 2 = Randwertproblem - Start UND Ziel (je X/Y/Z) sind bekannt, die
            Zwischenhoehen werden gerechnet, die Zielhoehe wird exakt
            getroffen.
  Modus 3 = Anfangswertproblem - die Kette wird mit vorgegebenen Winkeln
            vorwaerts durchgebaut, die Endhoehe ist das ERGEBNIS.
Modus 3 kann damit etwas, was Modus 2 grundsaetzlich nicht kann: ohne
vorgegebene Zielhoehe arbeiten ("folge dieser Linie mit 3 Grad und lass uns
sehen, wo wir landen") - und er hat keinen Solver, der scheitern kann.
Dazu kommt ein harter Bestandsgrund: Modus 3 schreibt ein eigenes Journal
(Marker "linienzug3") und ist per Doppelklick editierbar. Faellt der Code
weg, verlieren alle bereits damit gebauten Ketten ihren Editier-Pfad.
Der Stempel "Legacy / wird umgebaut" war ueberholt und ist raus.

MODUS 3 - DREI AENDERUNGEN (Nutzer-Vorgabe 2026-10-22)
1. "AS bauen?" und 2. "ES bauen?" sind jetzt abfragbar (vorher wurden beide
   immer gebaut), zusammen mit Winkel und Seite in je EINEM Dialog - dasselbe
   Muster, das Modus 2 schon nutzt (vflw-gruppe-as-impl), kein neuer Code.
   Ohne AS beginnt die Kette direkt am Startpunkt (flacher Rahmen statt
   Block); die Fussabdruck-Trimmung der ersten Geraden rechnet dann von
   selbst 0, weil Rahmen und Startpunkt zusammenfallen.
3. Die ES-Frage steht jetzt VOR dem Bau. Das behebt einen echten Fehler: die
   letzte Gerade wird um "Separator + ein-dx" gekuerzt, ein-dx wurde aber
   gelesen, BEVOR es gesetzt war - beim ersten Lauf griff der Schaetzwert
   *vfk-as-es-fallback-dx*, bei jedem weiteren stand dort der Wert der
   VORHERIGEN Kette (falscher Winkel, falsche Seite). Jetzt traegt die
   Trimmung den echten Fussabdruck der gewaehlten ES-Variante; ohne ES
   entfaellt sie ganz.

ABWAERTSKOMPATIBILITAET
Das Verschieben der ES-Frage aendert die Journal-Reihenfolge. Bestehende
"linienzug3"-Ketten bleiben per Doppelklick nachbaubar: alt-journal erkennt
sie am WERT des ersten Antwort-Eintrags ("30"/"90" = alt, "1"/"2" = neu, die
Mengen sind disjunkt) und spielt sie in der alten Reihenfolge ab. Dafuer der
neue Helfer vfl-replay-peek-wert neben vfl-replay-peek-art.

DIALOG vflw_as
Die Seitenauswahl wurde bei 30 Grad ausgegraut und NICHT in die Pending-Queue
gelegt - eine reine Modus-1-Regel (dort ersetzte die Zufuehrungsachse die
Seitenfrage). Modus 1 hat seit 2026-10-21 seinen eigenen Dialog; uebrig
blieben ES-Element sowie Modus 2/3, wo die Seite IMMER gebraucht wird - dort
ging bei 30 Grad ein zweites Fenster nur fuer die Seite auf. Entfernt.

NAMENSSCHEMA (faellt in denselben Commit, weil dieselbe Datei)
Die Helfer-Praefixe vfl2-/vfl3- stammten aus einer Planungsphase vor der
endgueltigen Menue-Zuordnung und waren dazu VERTAUSCHT: alle vfl3-* gehoeren
zu Modus 2, die vfl2-* zu Modus 3 - und drei davon zu BEIDEN. Eine
Modus-Nummer war fuer diese drei also gar nicht richtig vergebbar. Sie heissen
jetzt nach ihrer Rolle: vfl-zsolve-* (rechnet die Hoehen durch, nur Modus 2)
und vfl-pfad-* (arbeitet am gezeichneten Pfad, Modus 2 UND 3). 18 Funktionen,
jede Aufrufstelle maschinell gegen die Definitionen geprueft. Die falsche
Block-Ueberschrift "MODUS 3: Pfad + Ziel-Hoehe" (gemeint war Modus 2) ist
korrigiert, beide Gruppen haben jetzt einen erklaerenden Kopf.
vfl-zsolve-bruecke (frueher vfl3-solve-bruecke) wird von niemandem aufgerufen
- bewusst stehen gelassen und markiert, Loeschen gehoert in ein
Tote-Code-Review.

MENUE
Die Modi heissen jetzt nach ihrem Unterschied statt nach der Bedienung:
"aus 3D Linie mit Zielhoehe" / "aus 3D Linie ohne Zielhoehe" (vorher
"3D Objekte stueckweise (in Arbeit)").

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-10-22 12:01:16 +02:00

5.9 KiB

Raw Blame History

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:

;; 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).

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.
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)
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)
Uebergangspaare pro Kurve statt pauschal eins. hor-pairs aus der tatsaechlichen Schenkel-/Kurvenzahl ableiten - behebt die dZ-Restabweichung. (9950, dH-adj-Bildung 9982-9989)
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.

5.9 KiB Raw Blame History