Lisp (vf_linienzug.lsp/vf_spec.lsp):
- vsp-eingang-hoehe unterstuetzt jetzt "auto" (NIL-Token statt REAL) -
bewusst keine Zahl vorgeben, der Bauablauf berechnet seinen eigenen
Vorschlag, wie bei leerer Konsoleneingabe
- vfl-journal-reset-lauf: internes Reset innerhalb von vf-linienzug-modus/
-modus2 loescht *vfl-replay-queue*/*vflw-pending* nicht mehr mit (Bug:
REPLAY-getriebener Bau (vsp-bau-aus-spec) brach mitten in der Kette ab,
weil eine noch unverbrauchte Queue verworfen wurde)
Python-Gegenstueck nachgezogen (lib/vf_linienzug_grammatik.py,
lib/vf_spec_export.py, lib/vf_journal_export.py):
- NIL-Token-Unterstuetzung fuer eingang_hoehe="auto" im gemeinsamen
Parser-Kern, im Schreiber (SpecSchreiber) und in der Protokoll-Annotation
- gf_verteilung ist im Schreiber jetzt an der Feldpraesenz in der Spec
festgemacht statt an einem Grammatik-Flag (selbstbeschreibend, deckt
Specs mit und ohne diese Frage ab, ohne dass der Aufrufer die Grammatik
kennen muss)
- Rundlauf-Pruefung (main(), test_verlustfrei) toleriert jetzt die bekannte,
schon dokumentierte Erweiterung um drei neue Linie-GF-Pflichtfragen
(ist_teilfolge statt exakter Gleichheit)
- test_gleiche_journale_wie_protokoll: alle 5 Ketten in hundm05.json weichen
inzwischen vom Rohprotokoll ab (Kette 1 bewusst wegen eingang_hoehe,
Ketten 2-5 schon laenger wegen Handkorrektur gegen echte DXF-Positionen)
- expliziter Skip mit Begruendung statt leerem Loop
tests/testdata/hundm05.json:
- mm-Werte (dl, Start-/Stuetzpunkte, Koordinaten der Nachtrag-Objekte) auf
eine Nachkommastelle gerundet
- nicht abgefragte Kopf-Metadaten entfernt (beschreibung, sivas_id,
sivas_bezeichnung, planquadrat, block, dxf_handle) - nur quelle bleibt
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
lib/vf_journal_export.py (Journal.dekodiere) und lib/vf_spec_export.py
(SpecLeser) implementierten denselben Tokenwalk (Praeambel, Sektions-
schleife, Glied-Dispatch, VF-Einheit-Unterschleife) sowie dieselben
Code-Tabellen (SEITE/VARIANTE/VERTEILUNG/IM_VF/ENDPUNKT/ENDE2/ENDE3/
GEFAELLE/GF_LAENGE_MODUS, MENU_START/MENU_START_AKTUELL/MENU_WEITER,
Grammatik) unabhaengig voneinander - Aenderungen an der Grammatik (wie
im vorigen Commit) mussten von Hand synchron gehalten werden und sind
bereits einmal auseinandergelaufen.
Neuer gemeinsamer Parser-Kern (Kern/lies_journal) plus Sink-Schnittstelle
(SpecSink in vf_spec_export.py, ProtokollSink in vf_journal_export.py)
ersetzt die doppelte Implementierung; Code-Tabellen/Grammatik-Objekte
leben jetzt nur noch in lib/vf_linienzug_grammatik.py. Journal behaelt
nur noch die reine XDATA/DXF-Zerlegung, SpecSchreiber (Spec -> Journal,
Gegenstueck zu Lisp/vf_spec.lsp) bleibt unveraendert in vf_spec_export.py.
Zusaetzlich: pruefe_flachen_freitext schlaegt jetzt hart fehl, wenn
generierter Freitext (quelle/beschreibung) ein rohes Anfuehrungszeichen
enthaelt - der Lisp-seitige Flach-JSON-Leser (ssg-cfg-parse-value) kennt
keine Escapes und wuerde daran die Zeichenkette (und damit die gesamte
restliche Datei) falsch zerlegen.
Byte-identischer Output gegen die Baseline geprueft (beide CLIs, echte
Eingaben); pytest tests/test_vf_spec.py + test_vf_journal_grammatik.py
unveraendert: 2 bekannte, vorbestehende Fehlschlaege, 38 bestanden.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vf-linienzug-modus fragt bei einem mit "Horizontal-VF" eroeffneten
Kettenanfang eine Ziel-Hoehe fuer den GF1-Einlauf ab (vfl-prompt-hoehe-
eingang-gf1) und laesst dort die GF-Verteilungsfrage weg (fest "alles am
Einlauf") - vsp-journal/vsp-vf-einheit kannten das noch nicht. Ausserdem
werden ES-Winkel/-Seite beim kettenende-sub jetzt an der richtigen
Journal-Position (inkl. eigenem STEP-Marker) emittiert.
tests/testdata/hundm05.json: VF_hundm05_LZ_02..05 (die vier baugleichen
Schleifen, Block VF_1) aus tests/testdata/linienzug_tests.json neu
abgeleitet, mit den realen Startkoordinaten aus results/test_hundM05.dxf
statt der alten "sub":"auf-ab"-Behelfsloesung. VF_hundm05_LZ_01 und alle
Kreisel-/Separator-/Scanner-/BTMT-Objekte unveraendert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vfl-gf-auf-ab-solve bekommt einen 3. Parameter s-winkel (S's Neigung -
F_total bleibt immer bei *vfk-gefaelle-winkel*=3 Grad). Neue reine
Massen-Helfer vfl-projiziere-neigung + vfl-gf-bogen-summe (Formel-basiertes
Pendant zu vfl-gf-bogen-erweitern aus Option 5, da Option 4's Solver ohne
Live-Probe rechnet). vfl-qc-linie-mit-gf probiert s-winkel=3,6,9,... in
einer Schleife (max. 10 Versuche), bis F_total/S beide baubar sind - der
flachste passende Winkel wird automatisch gewaehlt, damit auch kuerzere
Mittelteil-Gesamtlaengen baubar sind statt nur bei einem festen Winkel.
Bei s-winkel=3 (extra-grad=0) reduziert sich die neue Formel nachweislich
exakt auf die alte, bereits bestaetigte Formel (Term-fuer-Term verifiziert)
- kein Regressionsrisiko fuer den bisherigen Grundfall. Vom Nutzer in
BricsCAD erfolgreich getestet.
Co-Authored-By: Claude Sonnet 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>
Linienzug-Modus 5: AS(90 Grad) -> Richtung+E1 in einem Klick -> 90-Grad-
GF-U-Turn (Gegenseite von AS) -> Fa(fallend, unbekannt)+Sep -> Bogen-auf-6
-> S(steigend, dynamisch 3/6/9/...Grad, flachster passender Winkel wird
automatisch gewaehlt) -> Bogen-ab-6 -> ES, mit exakter Kolinearitaets-
Rueckkehr zur AS-Eintrittsachse (2x2-Gleichungssystem Hoehe+Lage, analog
zu Option 4's E2-Loesung). E1 nutzt AS's real gemessene KS_AUS-Neigung
(neue vf-element-plan-neigung) statt der angenommenen 3 Grad - das macht
Fa/S ueberhaupt erst ueber E1 steuerbar. Bei "nicht baubar" wird eine
exakte Mindest-E1-Laenge vorgeschlagen (wie Option 4's Mindest-
Gesamtlaenge). Zusaetzlich: Bogen-Seite = Gegenseite der AS-Seite (Option 4
und 5), Fehler in vf-element-plan-neigung-Vorzeichen behoben, fehlender
Separator-Fussabdruck in der Hoehen-/Lage-Bilanz ergaenzt.
Neue GF-eigene Vertikalbogen-Bloecke (Vario_Bogen_auf/ab_3/6_rechts, 2D+3D)
fuer die Uebergaenge.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ersetzt den direkten vfl-vf-entscheidung-Aufruf (1300mm Budget, setzt
immer eine frische Umlenkstation voraus) durch Wiederverwendung von
vfl-body-abschluss + vfl-vf-ausgang-bauen - denselben Bausteinen, die
bereits "Option 3: Kettenende exakt am Zielpunkt" innerhalb einer
laufenden VF-Einheit nutzt (800mm Budget, keine Umlenkstation, volle
Stufe-1/2-Diagnose inkl. exakter Zielhoehe bleibt erhalten, da kein
GF1-Stumpf noetig ist).
Zusaetzlich: vfl-letzter-typ-familie korrigiert - letzter-typ="VF"
(gerade fertig gebaute VF-Einheit) zaehlt NICHT zur "VF"-Familie fuer
diesen Zweck, nur "Vario-Kurve" hat keine eigene Umlenkstation. Eine
neue VF-Einheit nach einer bereits fertigen braucht weiterhin eine
frische Umlenkstation (faellt jetzt korrekt auf die bisherige
Automatik zurueck).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nach jedem Endpunkt-Pick + Zielhoehe-Eingabe (Neue Linie: GF Zweig A,
Linie-VF, Neue Linie BIS Kettenende) wird jetzt der absolute Endpunkt
(X/Y, aus deltaL/hz-neu zurueckgerechnet) sowie die eingegebene
Zielhoehe und das daraus resultierende (noch UNREDUZIERTE) deltaH auf
der Konsole ausgegeben - vorher war z.B. bei "Neue Linie BIS
Kettenende" nur das bereits um den Separator+ES-Footprint reduzierte
deltaH sichtbar, was wie ein Rechenfehler wirken konnte.
Neuer Helfer: vfl-echo-endpunkt-hoehe.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bei "Neue Linie BIS Kettenende" (Option 6) wird jetzt erkannt, ob der
Startpunkt zu einer bestehenden VF- oder GF-Kette gehoert (KS_AUS-Scan
am Kettenanfang bzw. letzter-typ bei laufender Fortsetzung) und die
Bau-Logik entsprechend verzweigt, statt immer die generische
Machbarkeits-Automatik zu fragen:
- VF erkannt: baut zwingend ueber die Stufe-1/Stufe-2-Diagnose
(vfl-vf-entscheidung), auch wenn der natuerliche Winkel zufaellig
nahe 3 Grad liegt (vfl-segment-entscheidung haette dort faelschlich
eine reine GF gewaehlt)
- GF erkannt: neue Unterfrage mit denselben 2 Optionen wie "Neue Linie:
GF" (Zielhoehe fest -> Laenge berechnen, ODER Laenge fest -> Winkel
berechnen), eigener Radiobutton-Dialog (Wiederverwendung von
vflw-gruppe-gf-steigend-untermodus-impl)
- nicht eindeutig zuordenbar (z.B. frischer AS-Element-Start): bisherige
automatische Entscheidung unveraendert
Neue Helfer: vfl-letzter-typ-familie (Pendant zu vfl-kette-typ-familie
fuer den session-lokalen letzter-typ-String).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- vfl-in-abstand/-in-selection pruefen jetzt *vfl-wizard-abbruch-grund*
(bisher liefen beide an vfl-in-value/-value-p vorbei, ein Klick auf
"Abbrechen" im Wizard-Dialog fiel dadurch auf einen rohen getpoint
zurueck statt die Kette zu beenden)
- Kombiniertes ES-Element-Dialogfeld (Ja/Nein + Winkel 90/30 + Seite
links/rechts in einem Bildschirm, analog AS-Element)
- Separator VOR/NACH (horizontales Stueck) und Ist-Kettenende-Frage von
Dropdown auf Radiobuttons umgestellt, "Nein" als Vorgabe
- Neigungswinkel-Eingabe bei Gefaellestrecke: 3 Grad als Vorgabe statt
"Gegebene Hoehe"
- Zweig-C-Unterfrage (Endpunkt/Zielhoehe) bei "Steigende GF" bekommt
eigenen Radiobutton-Dialog statt generischem Dropdown-Fallback
- ES-Element-Anhaengung nach einer steigenden GF (Zweig C) baut jetzt
vorher per vfl-bogen-uebergang zurueck auf die Standard-Fallend-Basis
(ES-Element-Hardware gibt es nur fuer diese Anfahrt)
- Stufe-2-Diagnosetext klargestellt (Mindestlaenge vs. Fixwert ohne
GF-Bogen)
- Horizontal-VF: 1000mm-Mindestlaenge entfernt, GF1-Ziel-Hoehe-Feature
wiederhergestellt
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bei der abschliessenden Datei-fuer-Datei-Gap-Analyse gegen e76e24e (Funktions-
inventar + Lang-Key-Diff) zusaetzlich gefunden und behoben:
- vfl-modus-abbruch-sichern: "Zurueck"-Behandlung fehlte komplett - verwarf
bisher wie "Abbrechen" den kompletten Stand statt nur das letzte
angefangene Kettenglied zu verwerfen und automatisch neu zu fragen
(vfl-journal-truncate/-replay-start)
- vfl-vf-einheit (Punkt 7, Auf/Ab-Foerderer-Fortsetzung): Fall "Kette kommt
bereits flach an" (z.B. nach Horizontal-VF/Vario-Kurve) fehlte - fragte
bisher immer nach einer Zielhoehe, obwohl dort keine sinnvolle Zielhoehe
existiert; nutzt jetzt vfl-waehle-winkel-hoehen-tabelle
- Horizontal-VF: GF1-Stumpf wird bei vollem Eingang jetzt aus einer
abgefragten Zielhoehe berechnet statt pauschal auf *vfl-gf-min-laenge*
gesetzt
- Linie-VF/Linie (automatisch): erweiterte Stufe-2-Diagnose bei "nicht
baubar" (Mindestwert-Vorschlaege aus vfl-stufe2-diagnose) ergaenzt
- vfl-hor-koerper-bauen: klemmt weiterhin still auf Mindestlaenge (Kollegen-
Entscheidung, Bauteil muss fuer vf_spec.lsp deterministisch/kopflos
bleiben), meldet das Klemmen jetzt aber ueber vfl-meldung - die
urspruengliche interaktive "trotzdem bauen?"-Rueckfrage mit Checkpoint-
Rueckbau war nicht ohne Bruch der Kopflos-Tauglichkeit restaurierbar
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Restauriert alles aus e76e24e, das nach dem Reset auf master fehlte oder nur
teilweise wiederhergestellt war, und mit dem Kollegen-Umbau abgeglichen:
- vf_core.lsp: Radio-Button-Dialoge fuer Anlagen-Typ/Linienzug-Modus
(vfc-dialog-typ-waehlen/-linienzug-modus-waehlen) + Zurueck-Schleife im
c:VarioFoerderer-Dispatcher
- Vario-Kurve/GF-Bogen-Erkennung am Kettenanfang: vfl-eingang-modus-bestimmen
threaded durch vfl-vf-eingang-bauen/vfl-vf-einheit/vfl-vf-einheit-abschluss,
inkl. Punkt-7-Winkel/Hoehen-Tabelle fuer reduzierten Eingang
- Modus 2: Lauf-Anfang/Lauf-Abschluss (offener Anfang/Ende, GF-Verteilung
"alles Auslauf", Kletter-zu-kurz-Fallback) + Separator VOR/NACH bei
GF-Geraden
- Systemischer Bug behoben: mehrere Wizard-Dialogfunktionen nutzten noch
start_list/add_list (Dropdown) gegen laengst auf boxed_radio_column
umgestellte DCL-Dialoge (vflw-gruppe-as/-gefaelle/-variokurve/
-winkel-seite-impl, vflw-seg-linie-m2/-m3/-bogen-impl,
vfl-glied-gf-bogen/-vario/-as-es-dialog)
- Zentraler Abbruch-Trigger in vfl-in-value/-value-p wiederhergestellt (ohne
ihn wirkte der Zurueck/Abbrechen-Button in keinem Wizard-Dialog)
- vfl-frage-ist-endpunkt/-ist-kettenende als eigene Funktionen mit
Wizard-Dialog extrahiert (vorher Konsolen-Duplikate ohne Dialog-Hookup)
- 3 vfs-vf-entry-Aufrufe mit falscher Argumentzahl gefixt (akute
Absturz-Bugs in Modus 2/3)
- Tote Funktion vflw-gruppe-horizontal-impl entfernt (Tiles nicht mehr im
DCL vorhanden)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Spiegelt die drei neuen Felder (laenge_modus/sep_vor/sep_nach/steigend_modus)
aus Lisp/vf_spec.lsp im Python-Pendant (SpecSchreiber.sektion) - haelt die
"zwei unabhaengige Implementierungen pruefen sich" Architektur des Kollegen
fuer den Schreib-Pfad synchron. tests/test_vf_spec.py: LISP_FAELLE um die
2 neuen Testfaelle ergaenzt, Faelle-Zaehler 7 -> 9.
Bewusst NICHT angefasst: der Rueckwaerts-Decoder (SpecLeser, spec_aus_journal)
- die 5 echten HundM-Ketten (hm_recformat.json) wurden vor dieser Erweiterung
aufgezeichnet und haben daher keine Separator-Antworten fuer ihre Linie-GF-
Sektionen. Der Rundlauf-Test TestRundlauf.test_verlustfrei wird fuer Ketten
mit Linie-GF dadurch rot - eine inhaerente, bewusst in Kauf genommene Folge
der neuen Pflichtfragen im interaktiven Ablauf, kein Fehler im Schreiber
(ausfuehrlich kommentiert direkt an der Aenderung in vf_spec_export.py).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Auf der neuen Kollegen-Architektur (Stufe 0-2: Spec/Journal/Replay-System
in vf_spec.lsp, Frage-Schale/Bauteil-Trennung) neu aufgebaut, nachdem der
urspruengliche Stand (Commit e76e24e) auf einer aelteren Basis beruhte und
per Rebase-Analyse als eigenstaendige, unabhaengige Erweiterung erkannt
wurde (der Kollege hat nichts entfernt - diese Features existierten vorher
nur lokal uncommitted).
Drei Erweiterungen fuer "Neue Linie: GF" in vf-linienzug-modus:
- Separator VOR/NACH direkt vor bzw. nach der Gefaellestrecke einfuegbar.
- Aeussere Vorwahl "Wie soll die Laenge bestimmt werden?": Endpunkt waehlen
(bisheriges Verhalten) oder Zielhoehe zuerst festlegen (Winkel wird
daraus berechnet).
- Dritte Option "Steigende GF" (Sonderfall, 0 bis 3 Grad): erlaubt eine GF,
die statt zu fallen steigt. Neuer Helfer vfl-bogen-uebergang erkennt
anhand der tatsaechlichen Frame-Neigung, ob 0/1/2 Uebergangsboegen
(Vario_Bogen_auf_3/ab_3) noetig sind, und baut sie automatisch - im
Normalfall (fallend->fallend) ein No-Op.
Lisp/vf_spec.lsp (Kollegen-Spec/Headless-Bau-System) um die drei neuen
Felder (laenge_modus/sep_vor/sep_nach/steigend_modus) erweitert, mit
Defaults, die alte Specs unveraendert lassen - haelt die "Spec-Pfad ==
interaktiver Pfad"-Invariante seines Systems (TEST_HUNDM05/VF_SPEC_BAU)
intakt. tests/test_vf_spec.lsp entsprechend mit neuen Testfaellen ergaenzt.
Neuer Regressionstest TEST_LINIENZUG_STUFE2 (linienzug_tests_stufe2.json)
sowie Anleitung doc/vf_linienzug_modus1_anleitung.md aus dem urspruenglichen
Commit uebernommen; die Gefaelle-Hoehe/Winkel-Optionsreihenfolge im
Testdatensatz an die jetzt geltende (Kollegen-)Konvention angepasst.
Offen (bewusst zurueckgestellt): lib/vf_spec_export.py (Python-Vorwaerts-
Emitter, Pendant zu vf_spec.lsp) noch nicht nachgezogen - siehe Folge-Commit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
export_graph.py behandelte BTMT-Stationen bisher wie ein generisches
Durchlaufelement mit zwei Achs-Enden - dadurch entstanden mehrere,
teils widerspruechliche Kanten und die Rolle blieb "Element" statt
"Eingang"/"Ausgang". BTMT hat aber physisch nur EINEN Anschluss zum
Foerdersystem (sitzt als dritter Zweig einer Weiche auf der Kreisel-
Durchgangsbahn, der Kreisel bleibt dabei ein einzelner Verteiler-Knoten):
Beladung speist fest Material ein (kein Vorgaenger im Fluss), Entladung
nimmt es fest raus (kein Nachfolger).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
write_separatorliste_merkmale liess bisher nur "SEP"-Eintraege der
sepliste in die "TrackIds"-Spalte einfliessen; die AS-/ES-Ausschleus-
/Einschleuselemente an Anfang und Ende der Kette fehlten dadurch,
obwohl sie beim Kreisel (compute_kreisel_umlauf) bereits Teil von
dessen TrackIds sind. Jetzt werden alle sepliste-Eintraege (AS, SEP,
ES) in Baureihenfolge aufgeloest.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Explizites CSV-Spalten-Layout (inkl. der neuen "TrackIds"-Spalte) und
die neuen/erweiterten Testdateien (Bezeichnung-Attribut, BTMT im
Kreisel-Umlauf, 0-Grad-Start) nachgetragen - inhaltlich war die Doku
bereits aktuell, es fehlte nur die konkrete Kopfzeile und der
Test-Ueberblick.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Statt eines JSON-Merkmals bekommen VF_n/GF_n/Kreisel jetzt eine eigene
CSV-Spalte "TrackIds" (nach "Nachbarn", vor "Fehler") mit der Reihenfolge
der Separator-/BTMT-/AS-ES-/Weichen-TeileIds entlang der Strecke bzw. um
den Kreisel - analog zur bestehenden "Nachbarn"-Spalte statt versteckt im
Merkmale-JSON. Referenz-CSV fuer den Omniflo-Test an den neuen Header
angepasst.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Die Spalte "Bezeichnung" verwendet jetzt das in BricsCAD frei editierbare
Attribut "Bezeichnung" des Blocks, falls gesetzt - sonst wie bisher die
generierte Standardbezeichnung ("VarioFoerderer :3" usw.). Damit laesst
sich ein in der Zeichnung umbenanntes Element im CSV-Export wiedererkennen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Kreisel bekommen wie VF_n/GF_n ein Merkmal mit der Reihenfolge aller
Separator-/BTMT-Beladung-/BTMT-Entladung-TeileIds entlang der Bahn,
sortiert nach Winkel um die Kreiselachse (Start bei 0 Grad in
Drehrichtung DREHRICHTUNG) - nutzt dieselbe Umlauf-Logik, die bisher
nur die "Nachbarn"-Spalte gespeist hat. Merkmal-Schluessel einheitlich
auf "list_trackids" umbenannt (vorher "Separatorlist" bei VF/GF).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
TEST_HUNDM05 baute bisher keine BTMT-Beladung/SC_Entladung-Stationen,
weil hundm05.json anders als mubea.json nie Eintraege dafuer hatte -
dadurch fehlten sie im CSV-Export der Testanlage. Koordinaten/Rotation
aus dem Insertpoint/K1-KOS-String der realen Referenz-CSV
(hundmM05_1.csv) dekodiert und als "block"-Eintraege ergaenzt; der
bestehende generische _.INSERT-Pfad in hundm05:bau-sensor baut sie ohne
weitere Code-Aenderung. Kommentare/Doku (test_hundm05.lsp,
object_data.md Abschnitt 5) an die jetzt nicht mehr auf Separator/
Scanner beschraenkte Nutzung angepasst.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Kreisel-Kreisel-Weichen fehlten bisher im Kreisel-Umlauf (compute_kreisel_umlauf),
wodurch angrenzende Separatoren auf falsche/fehlende Nachbarn zeigten. Die
kreisel_bounds-Matching-Box ignorierte ausserdem die tatsaechliche Kreiseldrehung
(faelschlich als achsparallel angenommen), was bei gedrehten langen Kreiseln
(Mubea Kreisel 0002) zu falschen Nachbarschaften fuehrte.
Die sepliste-XDATA (AS/SEP/ES-Reihenfolge je VF_n/GF_n) wurde nie ans Python-Item
durchgereicht - die gesamte Ketten-Nachbarschaftserkennung lief dadurch ins Leere.
Nach dem Beheben entstand eine Doppelzaehlung: die in einer Kette verpackten
Separatoren existieren bereits als echte Proxy-INSERTs (csv:sep-proxies-erzeugen);
build_separator_kette_items erzeugte zusaetzlich eigene Zeilen aus der sepliste.
Umgebaut zu map_separator_kette_items: ordnet die sepliste-Reihenfolge den
vorhandenen Proxy-Items zu (Match ueber Wrapper-ID + INSERT-Punkt) statt neue
Zeilen zu erzeugen - keine Doppelzaehlung mehr, Nachbarn korrekt gesetzt.
Ausserdem: vla-getboundingbox scheiterte in einem realen Export bei ALLEN
Bloecken (fehlende bbox ueberall), der Fehler wurde bisher still verschluckt.
REGENALL vor der Export-Schleife behebt das; eine neue Diagnose (exp-bbox-fail)
meldet kuenftige Ausfaelle statt sie zu verschlucken. Freie/eingebettete
Separatoren ohne bbox bekommen zusaetzlich einen Fallback aus einer konfigurierbaren
Symbol-Groesse (cfg/export.cfg [Boundingbox] separator_box_*).
Co-Authored-By: Claude Sonnet 5 <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>
9 reale Separator/Scanner-Koordinaten aus der Anlage in hundm05.json
ergaenzt. hundm05:bau-zusatzobjekte (test_hundm05.lsp) baute bisher nur
Kreisel-Zusatzobjekte - neue hundm05:bau-sensor-Funktion (analog zu
mubea:build-separator-one in test_mubea.lsp) faengt jetzt auch
"block"-Eintraege (Separator/Scanner) ab und fuegt sie per _.INSERT ein.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ILS_EINGANG_INSERT/ILS_AUSGANG_INSERT (Menue SPS > Connections) setzen
das Eingang-/Ausgang-Symbol automatisch lotrecht ueber eine gewaehlte
BTMT-Beladung/-Entladung-Instanz statt per freiem Einfuegepunkt.
Blockdateien Eingang_2D/3D.dwg und Ausgang_2D/3D.dwg ins Flach-Schema
von data/ils kopiert (Quellen in data/ils/2D|3D bleiben unangetastet).
Mubea-Testdaten um ein Eingang-Symbol ueber der Beladung und je ein
Ausgang-Symbol ueber beiden Entladungen erweitert.
Zusaetzlich: BTMT-Drehung im CSV-Export (export_csv.py) auf ganze
Grad gerundet (90/180/... statt z.B. 90.4078), da Kommastellen dort
keine Bedeutung haben.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Benannte Zeichnungen exportieren jetzt nach <name>_export.csv bzw.
<name>_sivas.csv statt der festen Namen export.csv/export_sivas.csv,
damit sich Ergebnisse mehrerer Zeichnungen nicht mehr gegenseitig
ueberschreiben. Unbenannte Zeichnungen (DWGTITLED=0) behalten die
alten Standardnamen. test_export_all.lsp verlaesst sich jetzt auf
diese automatische Praefixierung statt *export-filenames* manuell
zu ueberschreiben.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
K1 ist jetzt IMMER der Eingang eines Elements, K2 IMMER der Ausgang
(AS = Eingangs-Element mit KS_EIN, ES = Ausgangs-Element mit KS_AUS).
- VarioFoerderer/Strecke (VF_*): Richtung liegt ueber die Elementrolle fest
-> K1 = AS-Ende (KS_EIN), K2 = ES-Ende (KS_AUS). Verhalten unveraendert.
- Gefaellestrecke (GF_*): Foerderrichtung ist bergab, also durch die HOEHE
bestimmt (HOEHE_VON_mm > HOEHE_BIS_mm, siehe check_hoehen.lsp). Der Eingang
ist das HOEHERE Ende, der Ausgang das TIEFERE - unabhaengig davon, welches
physische Element das AS bzw. ES ist. csv:vfgf-k-kos-strings sortiert bei
GF darum nach Z (hoeheres Z -> K1, tieferes Z -> K2); Fallback auf die
Rolle, wenn nur ein Ende gefunden wird.
Verifiziert: vario-VF K1 bei VF-x=0 (AS), K2 bei VF-x=15000 (ES);
mubea-GF 0016 AS_z=1852 >= ES_z=1537 -> K1=Eingang(hoch), K2=Ausgang(tief).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
