Schoenenberger_Systeme_GmbH/dxfmakros
3
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

[ADD] HundM05: fehlende Separator/Scanner nachgetragen + Bau-Support

Browse Source 
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>
This commit is contained in:
Samer Ayadi
2026-09-08 12:01:48 +02:00
parent 8ed12b64e9
commit 754815c61f
3 changed files with 193 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/testdata/object_data.md
Vendored
+1 -1
View File
@@ -649,7 +649,7 @@ Zwei Dateien beschreiben dieselben 5 Ketten, in zwei Formaten:
| `tests/testdata/hm_recformat.json` | die **Aufzeichnung**: rohes Eingabe-Journal aus der XDATA der Kundenzeichnung, als Frage-Antwort-Protokoll | `TEST_HM_RECFORMAT` (in `alltests.json` abgeschaltet) |
| `tests/testdata/hundm05.json` | die daraus abgeleitete **Spec** (Domaenenwerte statt Menue-Codes, 52 statt 281 Objekte) - hier werden weitere Teile der Anlage nachgetragen | `TEST_HUNDM05` |
In `hundm05.json` stehen neben den Ketten auch **andere Objekte der Anlage**, erkennbar am Feld `function` - Format wie in den jeweiligen Einzel-Testdaten (ein Kreisel also wie in `kreisel_tests.json`, Schema in Abschnitt 1). Damit beschreibt EINE Datei die ganze Anlage. Der Ketten-Uebersetzer ueberspringt diese Objekte (`vsp-gruppieren`), `hundm05:bau-zusatzobjekte` in `tests/test_hundm05.lsp` baut sie, und `lib/vf_spec_export.py` uebernimmt sie beim Neuerzeugen der Spec-Daten. Im Ergebnis-JSON unterscheidet das Feld `kind` die Objektarten (`linienzug` / `kreisel`).
In `hundm05.json` stehen neben den Ketten auch **andere Objekte der Anlage**, erkennbar am Feld `function` - Format wie in den jeweiligen Einzel-Testdaten (ein Kreisel also wie in `kreisel_tests.json`, Schema in Abschnitt 1). Damit beschreibt EINE Datei die ganze Anlage. Der Ketten-Uebersetzer ueberspringt diese Objekte (`vsp-gruppieren`), `hundm05:bau-zusatzobjekte` in `tests/test_hundm05.lsp` baut sie, und `lib/vf_spec_export.py` uebernimmt sie beim Neuerzeugen der Spec-Daten. Im Ergebnis-JSON unterscheidet das Feld `kind` die Objektarten (`linienzug` / `kreisel` / `sensor`). `sensor` sind Separator/Scanner-Eintraege (erkennbar an `block`, Schema wie Abschnitt 5/`mubea.json`) - `hundm05:bau-sensor` baut sie per direktem `_.INSERT` nach, analog zu `mubea:build-separator-one` in `tests/test_mubea.lsp` (`ils-insert-sensor` selbst ist nicht scriptbar).
Die Spec ist das Eingabeformat, die Aufzeichnung die Vorlage, an der sie gemessen wird (Rundlauf-Beweis in `tests/test_vf_spec.py`). Warum beide bleiben: die Aufzeichnung ist die einzige eingecheckte Kopie der Originaldaten (`data/polylines.dxf` ist zu gross fuer das Repo) UND der einzige Test dafuer, dass ein BESTEHENDER `VF_n`-Block weiter abspielbar ist - also dass Doppelklick-Edit und 2D/3D-Konvertierung an Altbestand funktionieren. Gebaut wird routinemaessig nur noch aus der Spec, damit nicht zweimal dieselbe Geometrie entsteht.