Neues Modul KettenFoerderer.lsp: baut aus KF_UM_<winkel>, KF_LAENGE und
KF_AN_<winkel> (je KS_AUS auf KS_EIN) plus der Draufsicht KF_2D einen Block
KF_<n>. Die Bausteine werden aufgerichtet eingebaut (Rz*Rx(90)*Rz), die Hoehe
laeuft in Z; KF_2D liegt deckungsgleich mit der Kette. Der Einbauwinkel jedes
Folgebausteins wird aus der Richtung des KS_AUS seines Vorgaengers gemessen,
KF_LAENGE ueber die Einbauhoehe skaliert.
- Dialog (DCL-Vorlage, Typ als Radiobuttons), Hoehe per Zahl oder aus zwei
Punkten, Doppelklick auf KF_n oeffnet KF_EDIT mit Neuaufbau
- eigenstaendiges Attribut-Schema, Auswahllisten mit Sivas-Optionstexten in
data/json/kettenfoerderer.json
- Sivas-Export: Merkmale 350, 353-357, 359-361, 391, baugleiche Foerderer
werden zu einer Zeile zusammengefasst (Artikelnummer 6120)
- ssg_ks_insert.lsp: neue Primitiven ks-xy-winkel, ks-block-messen,
insert-block-ks-skaliert und insert-block-ks-matrix (freie 3x3-Rotation);
ensure-block-loaded nimmt Bloecke ohne Dimensionssuffix unveraendert
- Menueeintrag KettenFoerderer aktiviert, toter Dummy OMNI_KettenFoerderer
entfernt; KF_* im Export-Pattern, in der ID-Vergabe und im Dispatcher
SSG_BLOCKEDIT (vor dem Omniflo-Zweig)
- Unit-Tests tu-tests-kf fuer die reinen Rechenkerne; Modul wird in der MNL
vorgeladen, dbg-Schalter kf-zeit zur Laufzeitmessung
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
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>
Die AS-Praeambel in Modus 1 fragt jetzt Winkel, Seite UND eine optionale
Zufuehrungsachse (2. Punkt) - im Assistenten alles in einem Fenster
(vflw_as_achse). Beide Angaben zusammen legen das AS vollstaendig fest: der
2. Punkt gibt die KS_EIN-Achse (Zufuehrung/Fahrtrichtung), links/rechts die
AS-Variante und damit die KS_AUS-Richtung der Kette. Bisher galt die Achse
nur beim 30-Grad-Element und ERSETZTE dort die Seitenfrage.
Darauf setzt die neue 5. Option der gf-laenge-modus-Frage auf, intern
"parallel" (vfl-gf-parallel-kreisel): AS -> GF-Stueck -> GF-Bogen aus EINEM
Abstandswert, gemessen senkrecht zur Zufuehrungsachse von AS-KS_EIN bis
Bogen-KS_AUS. Kein Separator dazwischen, damit der Abstand exakt getroffen
wird; die Kettenende-Frage stellt der Zweig selbst NACH dem Bau. Waehlbar
nur am Kettenanfang mit AS UND Achse.
Der Bogen ist nicht verdrahtet: gewaehlt wird der, der den gemessenen
Grundriss-Schwenk des AS-Blocks aufhebt (vf-element-plan-turn) - mit den
vorhandenen Bausteinen AS 30 -> 30-Grad-Bogen, AS 90 -> 90-Grad-Bogen,
immer zur Gegenseite. Querversatz von AS und Bogen wird gemessen statt
gerechnet; die Bogen-Probe laeuft dabei auf dem IDEALISIERTEN 3-Grad-Rahmen,
auf dem der echte Bogen spaeter sitzt (auf dem AS-Rahmen gemessen lag der
Abstand im BricsCAD-Test um 0.5 mm daneben).
Journal: [STR winkel][STR seite][PT p2 | NIL]. Welche Fragen gestellt wurden,
wird nicht journalisiert, sondern beim Replay an der Eintragsart erkannt -
alte Ketten bleiben ohne Sonderbehandlung editierbar. Die Journal-Werkzeuge
(vf_linienzug_grammatik.py, vf_spec_export.py, vf_journal_export.py,
vf_spec.lsp, test_hm_recformat.lsp) kennen das optionale Achsen-Token.
Tests: 11 neue Unit-Tests fuer die reinen Kerne vfl-par-bogen-waehlen und
vfl-par-gf-laenge (tu-tests-vfl-parallel), TEST_UNIT 701/701 gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Themen, die dieselben Dateien beruehren und daher zusammen gehen.
1) VF_HOEHE_m - Hoehe je VF-Segment, Sivas-Merkmale 4433-4437
Sivas erwartet je Streckengruppe bis zu fuenf Variofoerderer-Hoehen.
Neues Block-Attribut VF_HOEHE_m: kommagetrennte Liste in Metern mit 3
Nachkommastellen, Eintrag fuer Eintrag parallel zu L_VF_m/VF_WINKEL.
Je Eintrag der Mittelwert aus KS_EIN und KS_AUS DES GERADEN VF-Abschnitts.
Zwischen Umlenk- und Motorstation koennen mehrere Abschnitte liegen
(auf/ab/horizontal), jeder bekommt einen eigenen Wert.
SONDERFALL Standard/Etage: dort gibt es nur einen Motor und nur einen
geraden Abschnitt - gemessen wird die GANZE Kette (AS-KS_EIN bis
ES-KS_AUS, vf-vfhoehe-kette). Das ersetzt den Segmentwert; der Linienzug
laeuft nicht durch vf-dialog-berechnen-einfuegen und behaelt seine Liste.
WICHTIG - vollstaendige Erfassung: die VF-Segmente entstehen NICHT alle in
vfs-vf-koerper. Horizontale Zwischenstuecke, das "schon flach"-Segment und
die Modus-2/3-Fuellstuecke bauen direkt mit insert-inclined-scaled-block,
die Kette-Merge-Rekonstruktion liest sie aus bestehenden Bloecken. Ein
erster Fix nur in vfs-vf-koerper lieferte darum zu wenige Werte (realer
Befund: L_VF_m hatte drei Eintraege, VF_HOEHE_m einen). Jetzt sind alle 14
Stellen erfasst, die vfl-acc-vf-seg aufrufen - dafuer das Paar
vf-vfhoehe-merke/-schliesse, das ohne lokale Variable auskommt.
REGEL (im Code dokumentiert): Jede Stelle, die vfl-acc-vf-seg aufruft,
MUSS auch eine Hoehe erfassen - sonst verschiebt sich die Liste gegen
L_VF_m und im Export landet eine Hoehe beim falschen Foerderer.
Formatierung ueber vf-meter-3: (rtos x 2 3) allein kuerzt je nach DIMZIN
nachfolgende Nullen ("2.5" statt "2.500", "-1" statt "-1.000") - im
Testlauf real aufgetreten.
Attribut-Schema *strecke-attr-gruppe* (ssg_core.lsp) ergaenzt, sonst
verschluckt ssg-attrib-set-on den neuen Tag stillschweigend.
export_sivas.py verteilt die Liste auf VF_HOEHE_MERKMALE (4433-4437);
ueberzaehlige Abschnitte werden weggelassen statt zusammengefasst, fehlende
lassen das Merkmal ganz weg.
2) AS-Element 30 Grad: Zufuehrungsachse statt Seitenwahl
Der Startpunkt einer Kette mit AS-Element ist geometrisch keine Position,
sondern eine ACHSE: das AS sitzt an einer durchlaufenden Strecke und
schleust daraus aus, seine KS_EIN-Achse muss darauf liegen. Bisher richtete
vfl-insert-as-element das KS_AUS entlang der Kettenrichtung aus, wodurch
das KS_EIN um den Blockschwenk verdreht stand - beim 90-Grad-Element kaum
sichtbar, beim 30-Grad-Element deutlich.
Beim 30-Grad-Element wird die Seitenauswahl im AS-Gruppendialog jetzt
ausgegraut; stattdessen gibt ein zweiter Punkt die Zufuehrungsrichtung
(der Startpunkt bleibt der Sitz des Elements). Die Seite folgt aus der Lage
des naechsten Kettenpunkts zur Achse (vfl-seite-aus-lage). 90 Grad bleibt
unveraendert bei der Seitenfrage.
Der Dialog legt bei 30 Grad bewusst KEINE Seite mehr in die Pending-Queue -
sonst zog die nachfolgende Punktfrage sie als vermeintlichen Punkt heraus
und erschien gar nicht (realer Fehler beim ersten Test).
Abwaertskompatibilitaet: aeltere 30-Grad-Ketten wurden noch MIT Seitenfrage
gebaut. vfl-replay-peek-art sieht beim Replay nach, was tatsaechlich
ansteht ("PT" = Achse, "STR" = Seite) - die Modus-Wahl selbst wird nicht
journalisiert, weil sie daraus eindeutig rekonstruierbar ist.
Unit-Suite 687/687 gruen. VF-Hoehe in BricsCAD bestaetigt. Die AS-Achsenfrage
ist dort noch NICHT gelaufen, seit die Seitenauswahl ausgegraut wird.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Rad/Rad an beiden Flanken gilt nur bei gleich ausgerichteten Raedern als
"Seite an Seite"; in Gegenrichtung (Kreisel seitlich versetzt Ende an Ende)
ist es eine Weiche
- toleranz_beruehrung von 1 auf 10 mm (Zeichenungenauigkeiten, Spalt und
Ueberlappung)
- Unit-Tests fuer Ende-an-Ende, Seite-an-Seite und den Fall aus test.dxf (E3/C7)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Drei zusammenhaengende Korrekturen am GF-Zweig mit ES-Element (Modus 1).
1) ES-Fussabdruck wurde massiv unterschaetzt (333.65 mm zu lang)
Reserviert wurde (abs ein-dx) - die Block-X-Komponente aus
vf-element-masse. Ein Element wird aber so gedreht eingebaut, dass sein
KS_EIN auf der Fahrtrichtung liegt; beim drehenden ES_Element_30
(ein-ang=120 Grad) landet dadurch ein Teil der Block-Y-Komponente auf der
Fahrtachse. Real verbraucht es laengs 576.2 mm statt der reservierten
242.6 mm - die Kette ragte um die Differenz ueber den gepickten Endpunkt
hinaus (Nutzer-Befund 2026-10-09).
Warum das lange unentdeckt blieb: beim ES_Element_90 ist ein-ang=0, dort
ist (abs ein-dx) ZUFAELLIG richtig. Der frueher bestaetigende 90-Grad-Test
konnte den Fehler strukturell nicht finden (Nutzer-Hinweis).
Neu in vf_core.lsp: vf-element-laengs / vf-element-quer (hz-unabhaengige
Projektion auf bzw. quer zur Fahrtrichtung), vf-set-es-masse setzt
zusaetzlich ein-laengs / ein-quer. In vf_linienzug.lsp liest vfl-es-laengs
den Wert mit Rueckfallkette; ein bewusst genulltes ein-dx gewinnt dabei,
damit die rund zwei Dutzend Null-/Restore-Stellen keinen Doppelabzug
bekommen.
In BricsCAD bestaetigt: Separator+ES verbrauchen 875.83 mm gegen 875.79 mm
Soll (0.04 mm), Hoehe 151.23 gegen 151.20 mm.
2) Endpunkt per Ziellinie statt per Klick
Steht die Fahrtrichtung durch den Vorgaenger fest, ist die Laenge nicht
mehr frei: die (um den ES-Querversatz seitlich versetzte) Bahn des
ES-KS_AUS trifft eine Ziellinie in genau einem Punkt. Ein Klick kann den
nur annaehern. Neue Frage mit zwei gleichwertigen Optionen (Radio-Buttons
im Wizard-Modus): Ziellinie durch ZWEI PUNKTE zeichnen - Schnittpunkt wird
gerechnet - oder wie bisher einen Punkt waehlen.
REIN PLANAR: die Hoehe kommt weiterhin aus dem Gefaellewinkel, die
Ziellinie bestimmt nur X/Y (Nutzer-Praezisierung).
Beide Wege schreiben denselben einzelnen "DL"-Journaleintrag - Replay,
Doppelklick-Edit und 2D/3D-Konvertierung muessen von Ziellinien nichts
wissen. Die Bindung an die Linie besteht nur beim Bauen: wird die Linie
spaeter verschoben, folgt die Kette NICHT.
Abwaertskompatibilitaet: die neue Frage erzeugt einen zusaetzlichen
Journaleintrag, den aeltere Ketten nicht haben. vfl-replay-peek-art sieht
beim Replay nach, was tatsaechlich ansteht; steht dort ein "DL", ist es
ein Altbestand und die Frage entfaellt - sonst haette sie den Laengenwert
als Antwort verschluckt (Queue-Desync).
3) Bedienung: Achsenzwang und ruhige Ansicht
vfl-getpoint-achse zwingt den Cursor beim Picken auf die Anschlussachse
(SNAPANG + ORTHOMODE, kein BKS-Wechsel - getpoint liefert daher
unveraenderte Koordinaten). Nur die horizontale Richtung wird erzwungen,
die Hoehe bleibt frei.
vfl-view-refresh zoomte vor JEDER Laengeneingabe hart auf _Extents - die
Ansicht sprang bei grossen Anlagen nach jedem Klick weg. Jetzt wird nur
noch eingegriffen, wenn der Baupunkt aus dem sichtbaren Ausschnitt laeuft,
und dann per _ZOOM _Center unter Beibehaltung der Zoomstufe.
13 neue Unit-Tests (etage-laengs/-quer,
vfl-es-laengs, vfl-kreuz2, vfl-laenge-bis-ziellinie inkl. Realfall aus dem
BricsCAD-Log), Suite 533/533 gruen. lang-Paritaet geprueft.
Offen und bewusst nicht angefasst: vfl-winkel-machbar-p nutzt aus-dx/ein-dx
ebenfalls als Laengsmass und hat damit denselben Fehler (AS_30: 276 mm,
ES_30: 334 mm). Der saubere Fix fuellt ein-dx/aus-dx an der Quelle mit dem
Laengswert - das beruehrt rund 87 Fundstellen samt ihrer Null-/Restore-
Konvention und gehoert separat getestet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Eckrad: eigener DCL-Dialog (eckrad_edit.dcl) beim Einfuegen und per
Doppelklick (EckradEdit); Sivas-Merkmale am Kreisel ausgerichtet
(2950, 3381, 3992 Ja/Nein); bei Sep./Scanner-Zaehlung ausgenommen
- Kreisel: eigener Name bleibt in Bezeichnung + Beschriftung erhalten
- Sivas: Kreisel/Eckrad unterschiedlicher Hoehe nicht mehr zusammengefasst
- Export: Hoehen-Attribute in Z verschobener Kreisel/Eckrad/VF/GF neu
berechnet
- GF-Edit: Einfuegehoehe aus aktueller Z-Koordinate
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).
Die gebaute Etage-Kette endete 987.63 mm zu weit (X) und 3.46 mm zu hoch (Z).
Der Fehlbetrag lag vollstaendig im Ein-/Auslauf: der Solver reservierte dort
1177.87 mm, real verbraucht die Kette 2165.09 mm.
Zwei Ursachen:
(a) vf-element-masse liefert KS_EIN->KS_AUS im BLOCK-Koordinatensystem. AS
und ES werden aber um (hz - ein-ang) gedreht eingebaut - beim
AS_Element_30 ist ein-ang = 90 Grad, dadurch landet die Block-Y-
Komponente auf der Hauptachse. Bilanziert wurde die Block-X-Komponente:
AS 209.7 statt real 486.10, ES -242.6 statt real 525.29.
(b) Die Auslauf-Staustrecke wurde fix mit 400 mm budgetiert, ist seit dem
Umbau "Auslauf RUECKWAERTS vom ES gerechnet" aber variabel (im Testfall
334 mm). Daraus die 3.46 mm Resthoehe.
Fix: neue Funktion etage-rand-budget (seite) rechnet Einlauf (Schritte 1-4)
und Auslauf (12-15) exakt so, wie etage-foerderanlage-einfuegen sie baut,
inklusive analytisch vorab bestimmtem L-exit. Kern sind die reinen,
hz-unabhaengigen Projektionen etage-laengs/etage-quer. Die alte Naeherung
bleibt als Fallback, falls ein Block fehlt.
Damit faellt auch die bisherige Annahme, Laengentreue und seitliche
Fluchtung des ES-KS_AUS seien nicht gleichzeitig loesbar: die Bauschritte
5-11 laufen auf der Hauptachse und tragen nichts zur Quer-Bilanz bei,
L-exit ist deshalb von L_GF/L_VF unabhaengig und vor dem Solve bestimmbar.
Weiter: Konstante *vfk-etage-stau-ein* (400 mm) ersetzt die nackte Zahl an
beiden Stellen; zwei neue lang-Keys (de+en, Paritaet 1095/1095); neuer
Regressionsblock tu-tests-etage in tests/test_unit.lsp mit dem AS/ES-Fall
(Suite 520/520 gruen).
In BricsCAD verifiziert: Soll-Endpunkt (11804.31, 3039.64, 4256.5) exakt
getroffen, Abweichung 0.00 mm in allen drei Achsen.
Offen: bei korrekter Bilanz bleiben im Testfall bei 33 Grad nur 16.13 mm
fuer beide GF-Strecken. Eine Mindest-GF-Laenge als Gueltigkeitskriterium
der Winkelwahl ist noch nicht eingebaut.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neue Module ssg_blocktools.lsp (SSG_BLOCK_COUNT, SSG_BLOCK_DELETE,
SSG_ATTR_ERSETZEN) und ssg_texttools.lsp (SSG_TEXT_ERSETZEN,
SSG_TEXT_PARALLEL, SSG_TEXT_HOEHE, SSG_TEXT_STIL) sowie der generische
Eingabe-Wrapper ssg_input.lsp, dazu Menue-/Lade-Integration,
zweisprachige Texte und Unit-Tests fuer die reinen Kerne.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- ZUORDNUNG: ssg-id-check-all laeuft jetzt ZUERST, danach sind die
Wrapper-IDs endgueltig - Separator-Kopien, AS/ES- und Einheiten-Marker
bekommen ZUORDNUNG direkt beim Erzeugen. Entfallen:
csv:sep-proxies-zuordnung-setzen, csv:asmark-ids-setzen,
csv:unitmark-ids-setzen. zuordnung_fix/*cs-sep-fix-by-handle* bleibt
(count_sep_scan rechnet eigenstaendige Sensoren bewusst neu).
- sepliste-IDs: Zuordnung ueber die KS-Kettenfolge je Typ
(csv:sepliste-kette-paare) statt ueber die teils gespiegelten
sepliste-Koordinaten (csv:sepliste-paare, csv:sepliste-ids-setzen
entfallen). Die Kette wird je Lauf einmal berechnet (csv:kette-von);
die ID liest csv:block-to-json erst beim Schreiben. Behebt vertauschte
TrackIds/Nachbarn in HundM05 VF_1 (0031/0029).
- Element-Klassifizierung: eine Tabelle csv:element-familien (cfg-Muster)
fuer Suche und Klassifizierung; csv:proxy-typ entfaellt.
- Einheiten-Marker: K1/K2 nur noch in *csv-baustein-by-handle*
(csv:geometrie-merken), K1/K2-Attribute und
csv:unitmark-k-kos-strings entfallen.
Geprueft: HundM05-Export alt/neu headless verglichen - einzige Abweichung
ist die korrigierte Reihenfolge in VF_1. LISP-Unit-Tests 303/303.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Der Typ (Merkmal "Typ") jeder Separator-Zeile kommt jetzt an EINER Stelle
aus der Einheiten-Schneidung csv:kette-einheiten (neu: csv:kette-sep-typen,
eingetragen in csv:ketten-verarbeiten) - dieselbe Quelle wie die
Einheiten-Boundingbox. VF = Separator direkt vor der Umlenkstation bzw.
zwischen Umlenk- und Motorstation, sonst GF.
Die bauzeitige XDATA SSG_SEP_TYP (ssg-sep-typ-xdata-schreiben/-lesen,
15 Einfuegestellen) entfaellt. Sie war teils falsch: der Separator vor dem
ES hinter einer Motorstation bekam "VF", und ein sep_nach-Separator einer
GF, den die folgende VF-Einheit als Einlauf nutzt, blieb "GF"
(HundM05: Sep1/5/7/9/11 und Sep2).
Unit-Tests csv:kette-sep-typen in tests/test_unit.lsp.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AS/ES-Marker werden wie alle Hilfskopien geloescht (ausser csv_leave_proxies). IDs von AS/ES, Separator-Kopien und Einheiten bleiben ueber reservierte IDs (XDATA SSG_ID_RES) am VF_n/GF_n-Wrapper stabil: AS|n/ES|n, K|i, U|n.
Co-Authored-By: Claude Opus 5.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>
Neuer Menuepunkt Konfiguration > CSV-Export (CSV_EXPORT_KONFIG) mit DCL-
Dialog: drei sich ausschliessende Export-Modi (group_vf_gf/all_elements/
separator_track, letzterer neu - nur AS/ES/Separator) ueber die zentrale
Variable *csv-export-modus*, sowie zwei unabhaengige Haken fuer sichtbare
Element-Proxy-Kopien (Zuordnung pruefen / Kopien behalten).
Die Einzelteil-Proxy-Zeilen (Boegen, Streckenelemente, Umlenk-/Motorstation)
aus der letzten Session sind fuer den Normalfall zu granular. Standardmaessig
(*csv-export-alle-elemente* = nil) fasst csv:unitmark-aktualisieren sie jetzt
zu je einer "Foerdereinheit"/"Gefaelleeinheit"-Zeile pro zusammenhaengendem
VF-/GF-Abschnitt einer Kette zusammen, mit einem persistenten Rechteck-Marker
(ZZ_UNIT_MARKER, analog ZZ_ASES_MARKER) auf der Bounding-Box-Vereinigung
aller enthaltenen Elemente. Der bisherige Rohdaten-Export bleibt ueber
(csv:export-alle-elemente-an) weiterhin verfuegbar.
Einheiten-Grenzen kommen rein export-seitig aus der sepliste (SEP/AS/ES in
echter Bau-Reihenfolge) plus dem bereits vorhandenen SSG_SEP_TYP je
Separator - eine bauzeitige Markierung in vf_linienzug.lsp/vf_standard.lsp/
vf_etage.lsp waere deutlich invasiver gewesen (3 unabhaengige Baupfade ohne
gemeinsamen Einstiegspunkt). csv:sepliste-partition (Lauflaengen-Kodierung
ueber die typisierte sepliste) und csv:element-unit-zuordnung (Zuordnung der
gesammelten Elemente per Kettenrichtungs-Projektion statt der nachweislich
unzuverlaessigen csv:nested-welt-records-Listenreihenfolge) sind reine,
dateifrei getestete Funktionen.
Korrigiert nebenbei eine falsche Annahme: L_VF_m/L_GF_m zaehlen pro Segment,
nicht pro Einheit - die tatsaechliche Einheiten-Anzahl kommt nur aus der
sepliste-Typfolge.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bisher tauchten nur der Wrapper selbst, verpackte Separatoren und AS/ES-
Kettenenden als eigene CSV-Zeilen auf - die uebrigen Kettenbausteine
(Boegen, gerade Foerderer-/Gefaellestrecken-Segmente, Umlenk-/Motorstation)
blieben nur in der Wrapper-Blockdefinition verpackt. csv:element-proxies-
erzeugen (analog zu csv:sep-proxies-erzeugen) fuegt fuer jeden Fund eine
temporaere Kopie ein, K1/K2 kommen aus dem EIGENEN KS_EIN/KS_AUS jedes
Elements (nicht dem Gesamt-AS/ES der Kette) und bleiben leer, wo keines
existiert (z.B. das nie tatsaechlich eingefuegte Vario_Kurve_*).
Zusaetzlicher Fix: csv:get-k-kos-strings ignorierte bisher die Skalierung
des Top-Level-Inserts - fuer Staustrecke_SP_1000_mm (das per Laenge nicht-
uniform skaliert wird) waere K2 damit falsch gewesen, unabhaengig von der
tatsaechlich gebauten Segmentlaenge.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Stufe 1 (LISP-Export-Pfad): export_raw.json enthaelt jetzt fuer jeden
sepliste-Eintrag (AS/SEP/ES) einer VF_n/GF_n-Kette die ID des realen
Bauteils, das ihn vertritt.
- csv:sep-proxies-erzeugen (Separatoren) und die neuen AS/ES-Marker teilen
sich csv:nested-welt-records/csv:block-einfuegen-welt zur Platzierung.
- csv:sepliste-paare ordnet sepliste-Eintraege ihrem Bauteil exklusiv nach
Abstand zu (kuerzester zuerst, dann verbraucht) statt "jeder Eintrag
nimmt sich das naechste" - ein einzelner fehlerhafter Koordinatenwert
(bekannter Bug: gespiegeltes x bei lfdnr=2) verschiebt dadurch keine
andere Zuordnung mehr.
- Neu: ZZ_ASES_MARKER - ein kleines Rechteck an jedem AS/ES-Kettenende,
das nach dem Export STEHEN BLEIBT (anders als die temporaeren
Separator-Kopien). Macht das sonst unsichtbare, in der Wrapper-
Blockdefinition verpackte Kettenende in BricsCAD sichtbar/anklickbar
und traegt seine ID unsichtbar am Attribut ID - dadurch behaelt ein
AS/ES seine TeileId ueber Exportlaeufe hinweg. Wird bei jedem Export
neu aufgebaut (Lage folgt der Kette), Wiederfund ueber ZUORDNUNG+TYP+
LFDNR, verwaiste Marker werden entfernt.
In BricsCAD verifiziert (5 HundM05-Ketten, zwei Exportlaeufe: gleiche
Marker-IDs, korrekte sepliste-"id"-Felder). Dabei einen realen Bug
gefunden und behoben: die Blockdefinition des Markers uebernahm ueber
einen ungefilterten entnext-Walk versehentlich auch die Attribute des
zuletzt eingefuegten Blocks (VF_5 verlor dadurch alle Attribute inkl.
ID) - jetzt auf LWPOLYLINE/ATTDEF gefiltert.
9 neue zeichnungsfreie Unit-Tests (csv:sepliste-paare/*, csv:asmark-
finden/*, csv:proxy-typ/*), 4 neue de/en-Textschluessel (Paritaet
geprueft). bin\run_tests.bat --lisp: 257/257 bestanden.
Noch nicht enthalten (Stufe 2, Python): map_separator_kette_items nutzt
das neue "id"-Feld noch nicht, build_strecke_schleus_items synthetisiert
AS/ES-Zeilen weiterhin selbst statt die exportierten zu lesen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Modus 2 journalisiert die Segment-Essenz (SEGS) statt der Objekt-Handles
(OBJS) - identische Umstellung wie Modus 3. Damit ist der Block selbst-
enthalten und der Doppelklick-Neubau unabhaengig von den Original-LINE/ARC.
Behebt den beobachteten Modus-2-Desync (Winkel wurde beim Neuaufbau interaktiv
nachgefragt + Abweichung, weil der OBJS-Replay an den - ggf. verschobenen -
Pfad-Objekten hing).
- vfl-in-selection + obj-liste im Modus-2-Ablauf durch vfl-in-segmente ersetzt
(Live: ssget -> gf-sortiere-objekte -> gf-analysiere-kette -> Eck-Vorpruefung
-> SEGS; Replay: fertige Essenz aus dem Journal). Objektauswahl steht jetzt
NACH der Startpunkt-Praeambel (vfl-in-segmente braucht den startpunkt).
- segmente9 (9-Feld-Essenz) eingefuehrt, 5-Feld-segmente daraus abgeleitet;
seg-ent -> nil (kein Live-Highlight mehr, wie Modus 3).
- Marker bleibt "linienzug2".
HARTER SCHNITT fuer Altbestand: alte OBJS-"linienzug2"-Bloecke (ohne SEGS)
werden beim Doppelklick klar abgewiesen (neuer Text vfl-edit-m2-obsolet, de/en)
statt mit falschen Daten in den Bau zu laufen; der Batch-Konverter ueberspringt
sie. Erkennung: vfl-journal-hat-segs-p.
Tests: 3 file-freie Unit-Tests fuer vfl-journal-hat-segs-p (SEGS erkannt,
OBJS/leer nicht). 243/243 LISP-Unit-Tests gruen in BricsCAD; test-neutral gegen
HEAD (11=11 Python-Failures); lang-Paritaet geprueft. End-to-end (Neubau +
deckungsgleicher Doppelklick) wie bei Modus 3 interaktiv zu bestaetigen.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Der scharfe *error*-Abbruch-Handler (wickelt Teil-Geometrie bei ESC/(exit) zu
einem VF_n-Block mit vollem Journal) stand in Modus 1/2/3 dreimal WORTGLEICH,
nur der Marker-String unterschied sich. Jetzt eine gemeinsame Funktion
vfl-abbruch-handler-installieren (marker), die *error* als Lambda-Liste mit
eingebautem Marker-Literal setzt (list-Konstruktion, kein globaler Zwischen-
zustand). Der fragile Wickel-Rumpf existiert damit nur noch EINMAL - kuenftige
Fixes an einer Stelle statt drei.
Die je-Modus unterschiedliche old-error-Quelle bleibt an der Aufrufstelle
(M1: *error*, M2/M3: dbg-old-error via fruehem dbg-Hook) - nur der wortgleiche
Handler-Rumpf wird geteilt. Alle vom Handler zur Abbruchzeit dynamisch
aufgeloesten Locals (old-error/lastEnt/vfl-nummer/... /dbg-an) sind unveraendert
im Modus-Frame gebunden (VERTRAG in der Funktion dokumentiert).
Tests (tests/test_unit.lsp, tu-tests-vfl-abbruch): der Konstruktor erzeugt eine
gueltige (lambda (msg) ...)-Struktur und baut GENAU den uebergebenen Marker als
letztes Argument des vfl-modus-abbruch-sichern-Aufrufs ein (linienzug2 vs
linienzug3 geprueft). 240/240 LISP-Unit-Tests gruen in BricsCAD; keine neuen
Python-Failures (11 = HEAD-Baseline). Modus-1-ESC-Abbruch interaktiv bestaetigt
(Teilkette bleibt als editierbarer VF_n-Block stehen).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Modus 3 (Vorwaerts-Nachbau) hat jetzt dieselbe XDATA-Editierbarkeit +
Doppelklick-Neubau wie Modus 1/2. Statt der Pfad-Objekt-Handles wird die
abgeleitete Segment-ESSENZ journalisiert (neuer Journal-Typ SEGS): der VF_n-
Block ist damit selbst-enthalten, der Neubau unabhaengig davon, ob die
urspruenglichen LINE/ARC noch existieren - robuster als der OBJS-Weg von Modus 2.
Journal-Kern (vf_linienzug.lsp):
- Neuer Typ SEGS: Segmentliste (typ hz laenge bwinkel bseite spx spy epx epy)
serialisiert als ";"-getrennte Segmente, Felder per "|". Eingebunden in
vfl-entry->string / vfl-string->entry / vfl-entry->json.
- vfl-in-segmente: Live (ssget -> gf-sortiere-objekte -> gf-analysiere-kette ->
Eck-Vorpruefung -> 9-Feld-Essenz) ODER Replay (Essenz direkt aus SEGS-Journal).
Ersetzt vfl-in-selection im Modus-3-Ablauf.
- vfl-kette->segmente9 fuehrt Bau-Segmente + Start/Endpunkte zusammen; Soll-Ende
kommt jetzt aus der Essenz statt aus den Original-Entities.
Modus-3-Umbau:
- Abbruch-Wickler + vfl-journal-xdata-schreiben mit Marker "linienzug3" (analog
Modus 2). Kopf-Kommentar/Fehler-Handler-Variablen an Modus 2 angeglichen.
- Kein Live-Segment-Highlight mehr (Essenz-Bau reicht keine Entity mehr durch) -
bewusst, im Code dokumentiert.
Doppelklick/Batch:
- vfl-edit-ent2 zu vfl-edit-ent-voll parametrisiert; vfl-edit-ent3 ruft
vf-linienzug-modus3. vfl-edit-ent / vfl-konvertiere-ent / vfl-journal-xdata-
lesen dispatchen "linienzug3".
Tests:
- 8 file-freie SEGS-Roundtrip-Unit-Tests (tests/test_unit.lsp, tu-tests-vfl-segs);
234/234 LISP-Unit-Tests gruen in BricsCAD.
- vfl-in-segmente im statischen Headless-Waechter registriert.
- Verifiziert an einer echten linienzug3-Kette (results/test.dwg): SEGS-Journal
korrekt geschrieben, Doppelklick-Neubau geometrisch deckungsgleich zum Original.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Der Extrusions-Fix (d4260ac) hat csv:local-to-world von parent-rot-rad
(Winkel) auf parent-R (3x3-Rotationsmatrix) umgestellt. tu-tests-export
uebergab noch den Winkel und lief in "bad argument type <0.0>
expected <CONS>". Jetzt per (mat3-rz winkel) die Matrix bilden;
erwartete Ergebnisse unveraendert (Identitaet bzw. 90-Grad-Z-Drehung).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
cs-zuordnung-lauf (~230 Zeilen, ~26 Locals) in sieben benannte
Routinen zerlegt (cs-sammle-bloecke, cs-scanner-zuordnen,
cs-separatoren-zuordnen, cs-korrektur-vermerken, cs-scanner-distanz-
melden, cs-anzahl-schreiben, cs-bericht-ausgeben); die Engine ist
jetzt ein schlanker Orchestrator. Verhalten unveraendert.
Dadurch ist die rein geometrische Zuordnungslogik von den Entity-
Zugriffen getrennt und unittest-faehig: neuer Block tu-tests-sepscan
mit 30 Tests fuer cs-in-box/cs-bump/cs-carrier-by-id/cs-assign/
cs-nearest-two/cs-resolve-sensor (Carrier-Records als plain Listen,
keine Zeichnung noetig).
Testarchitektur (Laden) vereinheitlicht: lazy Feature-Module
(GeruestInsert, count_sep_scan) werden AUSSCHLIESSLICH in test_unit.scr
auf .scr-Top-Level geladen. Grund: in BricsCAD werden per load
definierte Funktionen erst nach Rueckkehr zum Top-Level sichtbar - ein
load in c:TEST_UNIT oder einem gecatchten Testblock bindet sie im
selben Durchlauf nicht. Die Testbloecke laden nichts mehr, sie pruefen
nur per atoms-family. Runner gehaertet (tu-run-block faengt harte
Fehler je Block ab -> FAIL statt Suite-Abbruch, Report immer da).
Nebenbei aufgeraeumt: tote tests.lsp-Referenz in ssg_load.lsp entfernt
(Datei laengst geloescht, blockierte headless den kompletten Testlauf).
Voller LISP-Unit-Lauf jetzt 226/226 gruen.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ssg-sepliste->string formatierte die Separator-Koordinaten mit
(rtos x 2 2). rtos respektiert die Zeichnungs-Systemvariable DIMZIN
(Nullunterdrueckung): bei dem verbreiteten DIMZIN=8 wird 10.00 zu 10
gekuerzt, das Praezisions-Argument hilft nicht. Dieselben Koordinaten
serialisierten damit je nach Zeichnungsprofil unterschiedlich - fatal
fuer die PERSISTENTE XDATA/Journal-Ablage am Block (verlustfrei im
Roundtrip, aber umgebungsabhaengig).
Neue Helferfunktion ssg-sepliste-fmt-koord (fix-basiert, kaufmaennische
Rundung mit Uebertrag und Vorzeichen) ersetzt rtos - reproduzierbar,
unabhaengig von DIMZIN/LUPREC/LUNITS. Plus 7 Kantenfall-Tests.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sammelt beim Bau von VF_n/GF_n-Ketten die Baureihenfolge der Separator-/
AS-/ES-Sub-Bloecke vor dem Block-Sweep und schreibt sie als XDATA auf den
fertigen Wrapper (ssg_ks_insert.lsp); export.lsp liest sie fuer das neue
"sepliste"-Feld im CSV-Export, export_neighbors.py nutzt es als Fallback
zur BBox-Kollisionspruefung. Dazu Unit-Tests fuer die reinen Serialisierungs-
funktionen (Chunking, Roundtrip) in test_unit.lsp.
Ausserdem: makunbound (existiert nicht in BricsCAD-AutoLISP) aus
test_run_all.lsp entfernt - verursachte Laufzeitfehler bei
SSG_RUN_ALL_TESTS_EXPORT/_OFFEN.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
y.wang
s.hensch
s.ayadi
m.stangl