Bisher war der geklickte Punkt immer der KettenANFANG. Oft steht aber das
andere Ende fest - typisch der Anschluss an einen Kreisel. Modus 1 fragt
deshalb jetzt ganz am Anfang nach der Bau-Richtung:
vorwaerts = geklickter Punkt ist der Kettenanfang (alles wie bisher)
rueckwaerts= er ist das Kettenende, genauer das KS_AUS des ES-Elements
ABLAUF RUECKWAERTS
ES setzen? + Winkel + Seite + Fahrtrichtung (2. Punkt) in EINEM Dialog, dann
"Neue Linie: GF" und die Laengenfrage mit drei Optionen:
1 Kettenanfang klicken -> + Neigungswinkel, Anfangshoehe wird gerechnet
2 Anfangshoehe vorgeben -> + Neigungswinkel, Laenge wird gerechnet
3 Parallel zum Kreisel -> nur Abstand (nur mit ES waehlbar)
Danach ist die Kette fertig. Die Spiegelfrage "Ist das der Kettenanfang?"
mit optionalem AS und Weiterbauen ist bewusst NICHT enthalten (Nutzer-
Entscheidung: vorerst kleiner Umfang).
ANKER
Das ES wird mit insert-block-mixed-to-ks und xy-ref/z-ref="KS_AUS" EXAKT auf
den geklickten Punkt gesetzt; alles Weitere wird daraus zurueckgerechnet
(vfl-rueck-punkt) und dann normal vorwaerts platziert. Gleiches Ergebnis,
aber mit den erprobten Einfuege-Primitiven. Eine Rest-Ungenauigkeit landet
am Kettenanfang statt am Kreisel-Anschluss.
Option 3 spiegelt die Vorwaerts-Variante: Bogenseite = Gegenseite der
ES-Seite, Bogenwinkel hebt den gemessenen ES-Schwenk auf. Dafuer werden die
bereits getesteten Kerne vfl-par-bogen-waehlen/vfl-par-gf-laenge
wiederverwendet - die Zuordnung (ES 30 links -> 30-Grad-Bogen rechts usw.)
faellt daraus heraus, statt gepflegt zu werden.
ZWEI FEHLER, DIE DER ERSTE BRICSCAD-TEST GEFUNDEN HAT
1. vflw-gruppe-as-impl legt VIER Werte in die Pending-Queue (ja/nein,
Winkel, Seite, Punkt). Die Ja/Nein-Antwort wurde nicht konsumiert, alles
rutschte eine Position weiter - der Winkel bekam die "1" der Ja/Nein-
Frage, Blockname "ES_Element_1_links". Die Frage wird jetzt gestellt und
ausgewertet; "Nein" ist dabei sinnvoll belegt (Kette endet direkt am
geklickten Punkt, Richtung ueber vfl-frage-fahrtrichtung-p2).
2. insert-block-ks-to-ks richtet immer den EINGANG eines Blocks aus.
Rueckwaerts sitzt der Bogen VOR dem GF-Stueck, sein AUSGANG muss also auf
der GF-Achse liegen - der Eingang ist um den Bogenschwenk vorzudrehen
(hz-bogen = hz-ein - bogen-turn). Ohne das zeigte der Ausgang um genau den
Bogenwinkel daneben, KS_AUS und KS_EIN trafen sich nicht. Gilt fuer den
Probe-Bau UND das echte Einfuegen - waere nur eins gedreht, saesse der
Bogen richtig orientiert an der falschen Stelle.
BEDIENUNG
- Kurze Entscheidungen im Rueckwaerts-Ablauf als Radio-Buttons statt
Auswahlliste (vfl-menu-radio).
- Beim Klick auf den Kettenanfang haengt der Cursor auf der Kettenachse
(neuer Wrapper vfl-in-point-achse ueber das vorhandene
vfl-getpoint-achse): ab dort kann nur noch entlang dieser Achse gebaut
werden, ein frei schwenkendes Gummiband gaukelte eine Freiheit vor.
- Zahlen-Dialoge belegen ihr Feld jetzt mit der Vorgabe vor. Die Prompts
tragen sie ohnehin in Klammern ("[3]", "<2154.0>"), der Dialog hat sie nur
ignoriert - bewusst generisch geloest (vflw-vorgabe-aus-prompt), die
Luecke hatten alle Zahlen-Dialoge des Assistenten.
- vflw_as beschriftet Seite und Achse neutral, weil derselbe Dialog jetzt
AS (vorwaerts) und ES (rueckwaerts) bedient; die Punkt-Anzeige heisst beim
ES "Endpunkt".
ABWAERTSKOMPATIBILITAET
Die Richtungsfrage steht VOR der AS-Frage und journalisiert ihren WERT
("vor"/"rueck") statt eines Index - ein Index "1"/"2" waere von der
nachfolgenden AS-Ja/Nein-Antwort nicht zu unterscheiden. Fehlt der Eintrag,
ist es ein Alt-Journal und es wird vorwaerts gebaut. Dafuer der neue Wrapper
vfl-menu-strwert.
TESTS
12 neue file- und zeichnungsfreie Unit-Tests: vfl-rueck-punkt (Rundlauf
vorwaerts/rueckwaerts) und vflw-vorgabe-aus-prompt (gegen die echten
Prompt-Texte, inkl. der Stolperstellen "0 < Winkel <= 3" ohne schliessendes
">" und dem Nachsatz in runden Klammern). TEST_UNIT konnte noch nicht
laufen - BricsCAD war die ganze Sitzung geoeffnet. Der Rueckwaerts-Bau
selbst ist vom Nutzer in BricsCAD geprueft und bestaetigt.
SSG_LIB.cui ist das von BricsCAD neu erzeugte Kompilat zur Menue-Aenderung
des vorigen Commits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Konflikt in menu/SSG_LIB.cui (generiert): Stand von origin/master
uebernommen, nur der Menuepunkt "Testanlage test_system" (MM_00210)
ergaenzt. SSG_LIB.mnu ohne Konflikt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Fahrstrecke:
- Neuer Befehl OMNI_FAHRSTRECKE (+ _BESCHRIFTEN) im Omniflo-Menue,
Daten aus data/json/omniflo_fahrstrecke.json, Vorlage dcl/fahrstrecke.dcl
- Nutzt die Linien-Logik des Geruest-Traegers (geruest-linien-starten,
Dialog/Einfuegen/Beschriftung je Baugruppe parametriert)
- Muffen-Dummy wie beim Traeger, farbig nur wo in der JSON gesetzt
- Stueckliste: eigene Klasse "Omniflo Fahrstrecke" (GR_Fahrstrecke_*)
Geruest-Dialoge:
- DCL als statische Vorlagen mit //@NAME@-Platzhaltern
(ssg-dcl-vorlage-fuellen in ssg_core), dcl/geruest.dcl neu
- Ein Dialog je Bereich (keine Bereichsumschaltung mehr)
- Varianten als Radiobuttons mit Artikelnummern im Label,
"disabled": true graut Varianten aus
- Eine Befestigungsspalte (Gesamtanzahl) + Zeile "Sonstiges",
Art.-Nr. unter jedem Anbauteil
- Winkel Platte (0/90): Anbauteile gedreht eingefuegt
- Kennzeichnung geaenderter Konfiguration, Ueberspeichern per Enter
- Traeger: Querstreben nur bei "mit_querstrebe": true
Konfigurationen im alten Format (oben/unten) werden beim Laden
uebernommen. Unit-Tests ergaenzt (599 gruen).
Lisp/vf_core.lsp: fuenf eigene Menue-Wrapper (LinienzugVarioFoerdererManuell/-Zielhoehe/-Stueckweise, QcLinieMitGf/-UForm) ersetzen den alten interaktiven Modus-Dialog; vfc-dialog-linienzug-modus-waehlen entfaellt.
dcl/vf_linienzug_wizard.dcl + Lisp/vf_linienzug.lsp: "Neue Linie BIS Kettenende" ist kein Radio mehr, sondern eigener Button "OK und Abschliessen" neben "Ok Weiter"; GF-Optionen stehen vor VF-Optionen.
Menue (SSG_LIB.mnu/.cui), lang/*.json, doc/kommandos.md, doc/lisp_methods.md, doc/faq.md nachgezogen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- csv_leave_proxies ist der einzige Schalter, der Export-Hilfskopien
(Separator-/Element-Kopien, Einheiten-Proxies) stehen laesst; Standard
jetzt 0 = aufraeumen. Die zwei gleichwirkenden Dialog-Haken
(*csv-export-pruef-zuordnung*/*csv-export-elemente-behalten*) entfallen,
CSV_EXPORT_KONFIG schaltet mit einem Haken denselben Debug-Schalter.
- Unit-Test fuer csv:hilfskopien-behalten-p/-setzen
- Test-Menue: (load ...) (c:TEST_...) statt Befehlsname direkt nach dem
load - BricsCAD registriert den per load definierten Befehl erst nach
Rueckkehr zur Kommandozeile ("Befehl nicht erkannt" bei TEST_EXPORT_ALL)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
K1/K2 und Boundingbox je Export-Zeile folgen jetzt dem echten
Kettenbaustein statt seinem Stellvertreter:
- Separator (all_elements): KS + bbox des 300-mm-Trennstegs statt des
Sensor-Symbols; separator_track/group_vf_gf behalten das Symbol
- AS/ES (all_elements, group_vf_gf): KS + bbox des AS-/ES-Elements statt
des 200x200-Markers ohne K
- gemeinsamer Kern csv:ks-welt-punkte; VF/GF-Wrapper-K1/K2 = K1 des AS
bzw. K2 des ES
Gruppierter Export neu (sepliste-/XDATA-Algorithmus entfernt):
- Bausteine je Wrapper als Vektorkette K2 -> K1 ordnen (Start am AS)
- Foerdereinheit = Separator vor der Umlenkstation bis Motorstation,
alles dazwischen Gefaelleeinheit (csv:kette-einheiten, Unit-Tests)
- je Einheit ein temporaerer Proxy mit 3D-Boundingbox, K1/K2, Laenge und
Anzahl Boegen; wird nach dem Export geloescht (ausser csv_leave_proxies)
- IDs neuer Export-Objekte entlang der Kette AS -> ES aufsteigend
Weiteres:
- ssg-make-layer ohne _LAYER-Befehl fuer bestehende Layer (Konsole)
- einheitliche, zweisprachige Meldungen fuer behaltene Hilfskopien
- bin/show_exportcsv.bat: Export-CSV als Boundingbox-SVG (sps_skel)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lisp/vf_standard.lsp: berechne-alle-winkel um Parameter schon-flach
erweitert (Fussabdruck-Korrektur, wenn ein Frame flach statt bei 3 Grad
ankommt) - vf_linienzug.lsp rief die Funktion bereits mit diesem 5.
Argument auf, dieser Commit fehlte im letzten Commit und liess den
Zwischenstand mit Argumentzahl-Mismatch zurueck. tests/test_foerderer.lsp
und tests/test_mubea.lsp ziehen dieselbe Signatur nach (inkl.
berechne-horizontale-mitte, das schon-flach bereits erwartete).
tests/testdata/linienzug_tests*.json aktualisiert passend zum echten
Bau-Ablauf. menu/SSG_LIB.mnu/.cui: TEST_LINIENZUG_STUFE2 im Testmenue
ergaenzt.
Lisp/vf_spec.lsp + lib/vf_spec_export.py: *vsp-menu-start* auf die aktuelle
6-Optionen-Kettenanfang-Zuordnung umgestellt (vorher noch 4 Optionen) -
vsp-journal replayt gegen den LEBENDEN vf-linienzug-modus. Python-Tabelle
bewusst NICHT umgestellt (dekodiert eine eingefrorene Alt-Aufzeichnung).
TEST_HUNDM05 schlaegt trotzdem weiterhin fehl (separates, ungeloestes
Problem - siehe naechster Absatz).
Bekannter offener Fehler: TEST_HUNDM05 baut nach wie vor nicht korrekt -
der Menu-Code-Fix allein reicht nicht. Root Cause nicht abschliessend
geklaert, Uebergabe an Kollegen fuer Logik-Review vorgesehen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- lib/dxf_scan_components.py: erkennt ILS-/Omniflo-Komponenten in fremden
Projektzeichnungen und schreibt sie im Testdaten-JSON-Schema aus
- lib/dxf_abbild.py: getreue Abbildung der Bauteile einer Fremdzeichnung
(Attribute, Weltkoordinaten, Unterkomponenten) ohne Interpretation
- tests/test_hundm05.{lsp,py}, testdata/hundm05.json, conftest-Fixtures und
alltests.json-Eintrag fuer den Kreisel-Abschnitt aus ST500592_05.dxf
- menu: TEST_HUNDM05 im Testmenue, Connection_Insert/Edit in SSG_LIB.cui
- Doku: hartkodierte Pfade durch (getenv "DXFMAKRO") ersetzt
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
y.wang
s.hensch
s.ayadi
m.stangl