Commit Graph

21 Commits

Author SHA1 Message Date
s.ayadi b66c4e5dae update mubea with BTMT information 2026-09-07 15:38:39 +02:00
s.ayadi e7ce72459d [FIX] mubea.json Separator-Drehung 90->270 + Debug-Exporte gf.dxf/test.dxf
Erwartete Drehung fuer den Separator in Kreisel_rechts korrigiert
(entdeckt beim Nachverfolgen der Separator-Rotation im GF-Export).
gf.dxf/test.dxf sind Testzeichnungen aus der Fehlersuche.
2026-09-04 09:25:09 +02:00
s.ayadi 541ad3f89d Separator am rechten oberen Kreisel hat noch gefehlt 2026-09-03 12:04:22 +02:00
s.ayadi e815ba1b49 Ein Separator unten am Förderer war noch zu viel 2026-09-03 11:58:18 +02:00
s.ayadi 428f1ced70 [FEAT] VF-Linienzug aus Eingabedaten bauen (Stufe 1: Spec -> Journal -> Replay)
Stufe 1 des Fahrplans in doc/TODO-plan-vf-interactive.md, fertig fuer
Modus 1. Eine SPEC beschreibt eine Kette in Domaenenwerten ("links",
"winkel", "aussen", ja/nein) statt in Menue-Codes; vsp-journal uebersetzt sie
in ein Eingabe-Journal, vsp-bau-aus-spec spielt es per
vfl-journal-replay-start durch den UNVERAENDERTEN vf-linienzug-modus. Der
fertige Block traegt damit dasselbe SSG_VF_EDIT-Journal wie eine handgebaute
Kette und bleibt per Doppelklick editier- und 2D/3D-konvertierbar - kein
Journal-Konsument muss etwas von Specs wissen.

CAD-Lauf VF_SPEC_BAU: 5 OK, 0 Fehler. Je Kette status "executed",
prompts 0 (keine Live-Eingabe erreicht), eingaben_offen 0, keine
Spec-Fehler, keine Bau-Meldungen, glieder_ist == glieder_soll,
Einfuegepunkt gleich dem Kettenstart der Spec.

Neu:
- Lisp/vf_spec.lsp: Code-Tabellen, Emitter vsp-journal, Validierung
  vsp-pruefen, flacher JSON-Loader, Headless-Rahmen vsp-headless-an/-aus,
  Ergebnis-Record, vsp-bau-aus-spec/-liste, c:VF_SPEC_BAU. Von vf_core.lsp
  NACH vf_linienzug.lsp geladen - damit sind beide Ladewege abgedeckt (Menue
  und der .scr-Loader), das MNL bleibt unveraendert.
- lib/vf_spec_export.py: derselbe Emitter in Python PLUS die Umkehrung
  (spec_aus_journal), erzeugt die Spec-Testdaten.
- tests/testdata/vf_spec_hundm05.json: die 5 echten Ketten als Spec,
  erzeugt statt handgeschrieben.
- tests/test_vf_spec.lsp (C:TEST_VF_SPEC, in alltests.json): 7 Faelle je
  Glied-Typ, 7 Validierungsfaelle, Gruppieren, und die 5 echten Ketten gegen
  ihr aufgezeichnetes Journal.
- tests/test_vf_spec.py: 36 Tests (Rundlauf, Spec-Daten, Validierung,
  Erwartungswert-Abgleich, Ergebnisse von VF_SPEC_BAU).

Drei Regeln, die der Uebersetzer besitzen muss - jede wuerde sonst die ganze
Replay-Queue verschieben:
- Der Menue-Code haengt am Frame: erste Sektion 4 Optionen (kein GF-Bogen,
  es gibt noch keine Richtung), jede spaetere 5.
- hz steht genau EINMAL im Journal, beim ersten Segment (vfl-in-abstand
  journalisiert die Richtung nur bei freier Richtungswahl).
- Nur ein HORIZONTALER Erstkoerper einer VF-Einheit stellt die Separator-/
  Endpunktfragen vorab (winkel1=0 laeuft durch vfl-baue-horizontal-koerper);
  ein gewinkelter wird ohne jede Frage gebaut.

Wie die Richtigkeit belegt ist - drei Implementierungen derselben Grammatik,
die einander pruefen:
- Rundlauf gegen echte Daten: journal_aus_spec(spec_aus_journal(tok)) == tok
  fuer alle 5 HundM-Ketten, tokenweise numerisch verglichen. Damit ist
  bewiesen, dass die Spec das Journal verlustfrei abbildet.
- Der Weg, den LISP nimmt (flaches JSON -> Spec -> Journal), ergibt separat
  geprueft dieselben Journale wie das aufgezeichnete Protokoll.
- Der unabhaengige Dekoder aus lib/vf_journal_export.py verdaut alle 7
  synthetischen Emitter-Ausgaben restlos, auch die zwei Zweige, die in den
  echten Daten fehlen (Linie-VF, gewinkelter Erstkoerper).
- Die Erwartungswerte im LISP-Test kommen aus dem geprueften Python-Emitter;
  TestLispErwartungen liest sie zurueck und vergleicht erneut. Ohne das
  koennte ein Uebertragungsfehler einen falschen Erwartungswert
  festschreiben und der CAD-Lauf waere gruen, obwohl der Emitter falsch
  liegt.

Abweichungen von der Planung (Begruendungen in doc/TODO-plan-vf-interactive.md
Abschnitt 4.6): vsp-pruefen ruft den Emitter statt eine zweite Regelmenge zu
pflegen; das vollstaendige Journal steht nicht im Record (statt dessen
glieder_soll/glieder_ist als Desync-Detektor); Zusatzfeld segment_typ am
Glied "Linie", weil dort vfl-segment-entscheidung selbst zwischen GF und VF
waehlt; vf_ende-Werte "automatisch"/"zielpunkt-ohne-es" fuer die Faelle ohne
Frage; Praefix vsp- statt vfs- (das gehoert vf_standard.lsp).

Zusaetzlich:
- tests/test_vf_headless_statisch.py prueft jetzt auch, dass
  Lisp/vf_spec.lsp UEBERHAUPT keine Eingabe-/Dialogfunktion aufruft - beim
  Daten-Pfad ist die Null die Vorgabe.
- tests/testdata/mubea.json: die drei einzeln eingefuegten S-LP-Separatoren
  entfernt (Fortsetzung von 699744e - die Separatoren stecken jetzt in den
  Staustreckenbloecken).

Noch offen: die Uebersetzer fuer Modus 2 und 3. Modus 2 braucht laut
Fahrplan erst 2-3 echte "linienzug2"-Journale als Referenz -
tests/testdata/hundm05.json enthaelt ausschliesslich Modus-1-Ketten.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-03 10:44:38 +02:00
m.stangl 20d8e795ad Die Einzelerzeugung der Separatoren jeder GF bei Mubea entfernt 2026-09-02 12:49:34 +02:00
s.ayadi 7242e815f8 HundM05-Testfall und DXF-Analyse-Skripte
- 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>
2026-08-24 12:10:58 +02:00
s.ayadi a664c938b7 update mubea test 2026-08-04 13:49:23 +02:00
m.stangl fd29b8d9bf Mubea: Drehung der Qualitätssicherungsförderers 2026-08-03 18:29:23 +02:00
m.stangl 7f42ac2701 Etagenförderer auch editierbar gemacht. 2026-08-03 16:25:44 +02:00
s.ayadi b744c94819 Add Etage-Typ-Unterstuetzung zu test_mubea.lsp + Testfall fuer Objekt 0061
mubea:build-vario(-one) liest jetzt ein optionales "typ"-Feld ("standard"
Default, "etage") und dispatcht auf berechne-etage/etage-foerderanlage-
einfuegen bzw. vf-block-erstellen mit dem passenden Typ. Neuer Testfall
VF_Mubea_Etage_0061 bildet Objekt-ID 0061 aus Mubea_Quali.dxf nach
(deltaL=12790, deltaH=0, seite=links, Winkel=9, L_GF1=1602.4).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-03 15:41:06 +02:00
s.ayadi 21c1a65bfd ADD Scanners 2026-07-29 14:28:01 +02:00
s.ayadi 98f1c64c3d Fix des Redefines im Lisp. Erzeugte lange schleifen. Jeder Block nur einmal laden 2026-07-28 16:11:31 +02:00
m.stangl 1d5d7c141e [FIX] Scanner-Insert in TEST_MUBEA: eff wurde durch AND statt IF zu T
mubea:build-separator-one nutzte (and blockname (ssg-ils-block-laden
blockname)) fuer eff - AutoLISPs AND liefert bei mehreren wahren
Ausdruecken T zurueck statt des letzten Werts (anders als in Common
Lisp/Scheme). Sobald ein Blockname (z.B. "Scanner") direkt gefunden
wurde, statt ueber den Separator_SP-Fallback zu laufen, wurde eff=T
an "_.INSERT" uebergeben. Fix: (if blockname (ssg-ils-block-laden
blockname)).

Ausserdem: Scanner-Testeintrag in mubea.json ergaenzt und
_vario_count/_separator_count in test_mubea.py, damit erwartete
Ergebniszahlen auch bei "anzahl">1 (Template->mehrere Kopien) stimmen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-28 13:49:21 +02:00
m.stangl bc1457e9bd Aktuellen Stand von Mubea der funktioniert. 2026-07-28 13:13:47 +02:00
m.stangl 4f1177c1f2 Einige Werte zu GF und VF korrigiert 2026-07-28 11:52:01 +02:00
m.stangl ad7a7243ba Fix der Gefällestrecke: Nimmt auch Fliesskommazahlen für den Winkel an. An Mubea Layout gemerkt. Funktionen zur Einfügung vno Geraden dazu 2026-07-28 11:03:15 +02:00
m.stangl cee2a81b55 Varioförderer Masse geändert 2026-07-27 22:16:36 +02:00
m.stangl e974e63c40 weiter am Mubea Test gebaut. Korrektur der GF und VF koordinaten 2026-07-27 22:09:20 +02:00
m.stangl a8fac86754 Mubeat Test hinzu 2026-07-27 16:54:04 +02:00
m.stangl 2f2e7c46d9 erste Fassung der Erzeugung von Mubea als Test hinzugefügt 2026-07-27 16:04:32 +02:00