[ADD] dbg2lsp.py: AutoLISP-Funktionen automatisch mit ssg_dbg instrumentieren
Neues Entwickler-Tool (bin/dbg2lsp.bat + lib/dbg2lsp.py), das das manuelle Einfuegen von dbgf/dbg/dbgreturn/dbgopen/dbgclose automatisiert: - --method NAME: dbgf + dbg je Parameter + dbgreturn um die letzte Rumpf-Form - --recursive: verfolgt den Aufrufgraphen ueber Dateigrenzen hinweg (Builtins werden automatisch uebersprungen, da sie kein defun im Suchpfad haben) - --add-open DATEI METHODE: dbgopen/dbgclose fuer einen Einstiegspunkt (z.B. ein c:BEFEHL-Kommando), inkl. aller (exit)-Stellen Dokumentiert in doc/dbg2lsp.md, Kurzeintrag in CLAUDE.md. Ausserdem: set_attributs.py aus doc/tools.md und CLAUDE.md entfernt - das Skript existiert nicht mehr in lib/. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
+206
@@ -0,0 +1,206 @@
|
||||
# dbg2lsp
|
||||
|
||||
Instrumentiert AutoLISP-Funktionen (`.lsp`) automatisch mit den `ssg_dbg.lsp`-Routinen
|
||||
(`dbgf`, `dbg`, `dbgreturn`, `dbgopen`, `dbgclose`) - so wie es beim manuellen Debuggen
|
||||
bereits von Hand gemacht wird (siehe z.B. `Lisp/KreiselInsert.lsp::ils-eckrad-insert`).
|
||||
Erspart das muehsame und fehleranfaellige manuelle Einfuegen dieser Aufrufe in
|
||||
lange Aufrufketten (Kreisel/VarioFoerderer/Gefaellestrecke/Separator-Scanner o.ae.),
|
||||
bevor ein Testlauf in BricsCAD gestartet wird.
|
||||
|
||||
- [Aufruf](#aufruf)
|
||||
- [Was wird eingefuegt](#was-wird-eingefuegt)
|
||||
- [--method](#--method)
|
||||
- [--recursive](#--recursive)
|
||||
- [--add-open](#--add-open)
|
||||
- [Schalter](#schalter)
|
||||
- [Typischer Ablauf](#typischer-ablauf)
|
||||
- [Beispiele](#beispiele)
|
||||
- [Funktionsweise / Aufloesung](#funktionsweise--aufloesung)
|
||||
- [Grenzen](#grenzen)
|
||||
- [Idempotenz](#idempotenz)
|
||||
|
||||
## Aufruf
|
||||
|
||||
```
|
||||
bin\dbg2lsp.bat <datei.lsp> [--method NAME ...] [--recursive] [--add-open DATEI METHODE] [Schalter]
|
||||
```
|
||||
|
||||
Das Batch-Skript ruft `setenv.bat` auf und startet `lib/dbg2lsp.py` mit den
|
||||
uebergebenen Argumenten. `<datei.lsp>` dient als Anker (ihr Verzeichnis wird immer
|
||||
mitdurchsucht) - die gesuchte Funktion muss nicht zwingend in genau dieser Datei
|
||||
stehen, siehe [Funktionsweise](#funktionsweise--aufloesung).
|
||||
|
||||
## Was wird eingefuegt
|
||||
|
||||
### --method
|
||||
|
||||
Fuer die angegebene Funktion (mehrfach angebbar) wird direkt als erste Rumpf-Form
|
||||
|
||||
```lisp
|
||||
(dbgf "funktionsname")
|
||||
(dbg 'parameter1)
|
||||
(dbg 'parameter2)
|
||||
...
|
||||
```
|
||||
|
||||
eingefuegt (ein `dbg`-Aufruf je Eingabeparameter - die Locals nach `/` in der
|
||||
Parameterliste NICHT, das sind keine Eingabewerte), und die **letzte Form des
|
||||
Funktionsrumpfs** wird eingeklammert:
|
||||
|
||||
```lisp
|
||||
(dbgreturn <letzte Rumpf-Form>)
|
||||
```
|
||||
|
||||
`dbgreturn` loggt und liefert den Rueckgabewert unveraendert weiter (siehe
|
||||
`Lisp/ssg_dbg.lsp`) - das Verhalten der Funktion aendert sich dadurch nicht.
|
||||
|
||||
### --recursive
|
||||
|
||||
Verfolgt zusaetzlich den Aufrufgraphen: jede Funktion, die im (Original-)Rumpf
|
||||
aufgerufen wird - auch beliebig verschachtelt, z.B. in einem `if`/`progn`, aber
|
||||
NICHT innerhalb einer `'quotierten Liste` (die ist reine Datenliste, z.B.
|
||||
`'(("OSMODE") ("CECOLOR"))`) - wird ebenfalls mit `--method`-Logik instrumentiert,
|
||||
sofern sich ihr `(defun ...)` in einem der durchsuchten Verzeichnisse findet.
|
||||
|
||||
AutoLISP-/BricsCAD-Builtins (`princ`, `command`, `strcat`, `rtos`, `entmake`, `vla-*`, ...)
|
||||
haben dort naturgemaess kein `defun` und werden dadurch automatisch **nicht** angefasst -
|
||||
es gibt keine Builtin-Blacklist zu pflegen. Die `ssg_dbg.lsp`-Funktionen selbst
|
||||
(`dbgf`, `dbg`, `dbgp`, `dbgmsg`, `dbgreturn`, `dbgopen`, `dbgclose`, `dbgflush`, `dbgon`, `dbgoff`
|
||||
und ihre internen `dbg-*`-Helfer) sind fest ausgeschlossen, damit eine bereits
|
||||
instrumentierte Funktion nicht dazu fuehrt, dass das Debug-Framework sich selbst
|
||||
instrumentiert.
|
||||
|
||||
Bereits instrumentierte Funktionen werden uebersprungen (siehe [Idempotenz](#idempotenz)),
|
||||
ihr Rumpf wird aber trotzdem nach weiteren, noch nicht instrumentierten Aufrufen
|
||||
durchsucht - die Rekursion bricht dadurch nicht an einer schon bearbeiteten Stelle ab.
|
||||
|
||||
### --add-open
|
||||
|
||||
Fuegt in der angegebenen Methode (typischerweise ein `c:BEFEHL`-Kommando, das
|
||||
einen ganzen Testlauf umspannt) ein:
|
||||
|
||||
```lisp
|
||||
(dbgopen "<dbg-datei>" "<envvar>")
|
||||
```
|
||||
|
||||
als erste Rumpf-Form, sowie
|
||||
|
||||
```lisp
|
||||
(dbgclose)
|
||||
```
|
||||
|
||||
vor **jedem** `(exit)`-Aufruf im Rumpf (auch verschachtelt) und zusaetzlich am
|
||||
Ende des Rumpfs - ausser die letzte Rumpf-Form ist bereits selbst ein `(exit)`
|
||||
(dann waere ein zweites `dbgclose` ohnehin unerreichbarer Code).
|
||||
|
||||
`--add-open DATEI METHODE` ist unabhaengig von `--method`/`--recursive` nutzbar
|
||||
und mehrfach angebbar; alle drei Mechanismen lassen sich in einem Aufruf kombinieren.
|
||||
|
||||
## Schalter
|
||||
|
||||
| Schalter | Beschreibung |
|
||||
|---|---|
|
||||
| `datei` (Pflicht, Position 1) | Anker-`.lsp`-Datei; ihr Verzeichnis wird immer mitdurchsucht |
|
||||
| `--method NAME` | Funktion mit `dbgf`/`dbg`/`dbgreturn` instrumentieren (mehrfach angebbar) |
|
||||
| `--recursive` | Auch alle im Rumpf aufgerufenen projekteigenen Funktionen instrumentieren |
|
||||
| `--search-dir DIR` | Weiteres Verzeichnis nach `.lsp`-Dateien durchsuchen (mehrfach angebbar). Default: `Lisp/` und das Verzeichnis von `datei` |
|
||||
| `--max-depth N` | Maximale Rekursionstiefe fuer `--recursive` (Default: `3`) |
|
||||
| `--exclude NAME` | Funktionsname von `--recursive` ausschliessen (mehrfach angebbar) |
|
||||
| `--add-open DATEI METHODE` | `dbgopen`/`dbgclose` in `METHODE` (aus `DATEI`) einfuegen (mehrfach angebbar) |
|
||||
| `--dbg-file NAME` | Dateiname fuer `(dbgopen ...)`. Default: aus dem `--add-open`-Methodennamen abgeleitet (`c:TEST_MUBEA` -> `test_mubea.dbg`) |
|
||||
| `--dbg-envvar NAME` | Umgebungsvariable fuer `(dbgopen ...)` (Default: `DXFM_LOG`) |
|
||||
| `--force` | Auch instrumentieren, wenn bereits `(dbgf ...)`/`(dbgopen ...)` vorhanden zu sein scheint |
|
||||
| `--dry-run` | Nur ein Diff anzeigen, keine Dateien schreiben |
|
||||
|
||||
## Typischer Ablauf
|
||||
|
||||
1. **Immer zuerst `--dry-run`** laufen lassen und das Diff pruefen (mehrere Dateien
|
||||
koennen betroffen sein, siehe `--recursive`).
|
||||
2. Ohne `--dry-run` erneut aufrufen - die Dateien werden direkt (in-place) geschrieben.
|
||||
3. In BricsCAD `(load ...)` neu laden bzw. den Testlauf starten.
|
||||
4. Die `.dbg`-Datei (per `--add-open` geoeffnet, Pfad = `%DXFM_LOG%\<--dbg-file>`)
|
||||
auswerten.
|
||||
5. Da die Dateien in-place geschrieben werden und ueber Git versioniert sind: nach
|
||||
dem Debuggen die Debug-Aufrufe entweder manuell entfernen oder die Datei(en)
|
||||
per `git checkout -- <datei>` verwerfen (das Werkzeug selbst hat keinen
|
||||
"--remove"-Schalter).
|
||||
|
||||
## Beispiele
|
||||
|
||||
Eine einzelne Funktion instrumentieren:
|
||||
|
||||
```
|
||||
bin\dbg2lsp.bat tests\test_mubea.lsp --method mubea:build-separator-one --dry-run
|
||||
```
|
||||
|
||||
Eine Funktion UND alles, was sie aufruft (bis Tiefe 3, Default):
|
||||
|
||||
```
|
||||
bin\dbg2lsp.bat tests\test_mubea.lsp --method mubea:build-kreisel --recursive --dry-run
|
||||
```
|
||||
|
||||
Mehrere Einstiegspunkte in einem Lauf, plus Oeffnen/Schliessen der Debug-Datei
|
||||
im umgebenden Testbefehl - das entspricht genau der Instrumentierung, die fuer
|
||||
den urspruenglichen Scanner-Bug in `TEST_MUBEA` von Hand gemacht wurde:
|
||||
|
||||
```
|
||||
bin\dbg2lsp.bat tests\test_mubea.lsp ^
|
||||
--method mubea:build-kreisel ^
|
||||
--method mubea:build-vario-one ^
|
||||
--method mubea:build-gf-one ^
|
||||
--method mubea:build-separator-one ^
|
||||
--recursive ^
|
||||
--add-open tests\test_mubea.lsp c:TEST_MUBEA
|
||||
```
|
||||
|
||||
Bestimmte generische Helfer von der Rekursion ausschliessen (z.B. um `ssg-start`/`ssg-end`
|
||||
nicht mit anzufassen):
|
||||
|
||||
```
|
||||
bin\dbg2lsp.bat tests\test_mubea.lsp --method mubea:build-kreisel --recursive ^
|
||||
--exclude ssg-start --exclude ssg-end
|
||||
```
|
||||
|
||||
## Funktionsweise / Aufloesung
|
||||
|
||||
- `datei` wird zuerst relativ zum aktuellen Arbeitsverzeichnis, sonst relativ zur
|
||||
Projektwurzel (erkannt an `.git/` bzw. `Lisp/`, ausgehend von `datei` nach oben
|
||||
gesucht) aufgeloest.
|
||||
- Durchsucht werden: das Verzeichnis von `datei`, `Lisp/` (relativ zur Projektwurzel),
|
||||
jedes `--search-dir` sowie das Verzeichnis jeder `--add-open`-Datei - jeweils
|
||||
rekursiv nach `*.lsp`.
|
||||
- Aus all diesen Dateien wird EIN Index `Funktionsname -> (defun ...)` aufgebaut
|
||||
(case-insensitiv, wie AutoLISP-Symbole zur Laufzeit). `--method`/`--add-open`
|
||||
muessen daher nicht in `datei` selbst stehen, sondern werden ueberall gefunden.
|
||||
- Klammer-/String-/Kommentar-Erkennung ist zeichenweise implementiert (kein
|
||||
vollstaendiger Lisp-Reader) - genuegt aber, um Top-Level-`(defun ...)`-Bloecke,
|
||||
ihre Parameterliste und die letzte Rumpf-Form zuverlaessig zu erkennen, auch bei
|
||||
mehrzeiligen Parameterlisten mit Locals nach `/`.
|
||||
- Alle Aenderungen werden zunaechst als Liste von reinen Text-Einfuegungen
|
||||
gesammelt (keine Loeschungen) und erst am Ende je Datei angewandt - Positionen
|
||||
bleiben dadurch unabhaengig von der Bearbeitungsreihenfolge gueltig.
|
||||
|
||||
## Grenzen
|
||||
|
||||
- **Nur die letzte Rumpf-Form wird zu `dbgreturn`.** Fruehe `(exit)`-Ausstiege
|
||||
MITTEN im Rumpf werden von `--method` nicht mit einem eigenen `dbgreturn`
|
||||
versehen (nur `--add-open` behandelt `(exit)`-Stellen explizit, dort aber nur
|
||||
mit `dbgclose`, nicht mit einem geloggten Rueckgabewert).
|
||||
- **Kein "--remove".** Rueckbau erfolgt manuell oder per `git checkout -- <datei>`.
|
||||
- **`--recursive` kann viele Dateien anfassen** - projekteigene Helfer wie
|
||||
`ssg-start`/`ssg-val`/`ssg-attrib-merge` werden mitinstrumentiert, sobald sie im
|
||||
Aufrufgraphen auftauchen. `--max-depth` und `--exclude` begrenzen das gezielt;
|
||||
ohne `--dry-run`-Kontrolle vorher nicht blind auf grosse Funktionen mit hoher
|
||||
`--max-depth` loslassen.
|
||||
- **Mehrfache Definitionen desselben Namens** in unterschiedlichen Dateien: es
|
||||
gewinnt der erste beim Durchsuchen gefundene (Dateireihenfolge nicht garantiert
|
||||
sortiert-stabil ueber Verzeichnisgrenzen) - in dieser Codebasis kommt das
|
||||
ueblicherweise nicht vor.
|
||||
|
||||
## Idempotenz
|
||||
|
||||
Vor dem Einfuegen prueft das Werkzeug, ob die erste Rumpf-Form bereits `(dbgf ...)`
|
||||
(fuer `--method`) bzw. `(dbgopen ...)` (fuer `--add-open`) ist, und ueberspringt die
|
||||
Funktion in dem Fall mit einer `[skip]`-Meldung. Mit `--force` wird trotzdem erneut
|
||||
eingefuegt (fuehrt bei wiederholtem `--force`-Aufruf zu doppelten `dbgf`/`dbg`-Zeilen -
|
||||
in dem Fall vorher besser die Datei zuruecksetzen).
|
||||
-162
@@ -35,18 +35,6 @@ Diese Werkzeuge ermöglichen die massenhafte Aufbereitung von einzelnen dxf Date
|
||||
- [--number SIVASNR](#--number-sivasnr-1)
|
||||
- [Uebersicht K-Zuordnung](#uebersicht-k-zuordnung)
|
||||
- [Umgebungsvariablen](#umgebungsvariablen-1)
|
||||
- [set\_attributs](#set_attributs)
|
||||
- [Aufruf](#aufruf-2)
|
||||
- [Datenquellen](#datenquellen-2)
|
||||
- [Ablauf](#ablauf-2)
|
||||
- [Konfiguration (attradd.cfg)](#konfiguration-attraddcfg)
|
||||
- [Attribute Omniflo Kurve (Bogen)](#attribute-omniflo-kurve-bogen)
|
||||
- [Attribute Omniflo Weiche](#attribute-omniflo-weiche)
|
||||
- [CSV-Export-Felder (Merkmale)](#csv-export-felder-merkmale)
|
||||
- [Schalter](#schalter-2)
|
||||
- [--number SIVASNR / -n SIVASNR](#--number-sivasnr---n-sivasnr)
|
||||
- [--dry-run / -d](#--dry-run---d)
|
||||
- [Umgebungsvariablen](#umgebungsvariablen-2)
|
||||
|
||||
|
||||
# set_einfuegepunkt
|
||||
@@ -274,153 +262,3 @@ Nur die angegebene 9-stellige Sivasnr verarbeiten. Kombinierbar mit jedem Schalt
|
||||
|---|---|
|
||||
| `DXFM_DATA` | Pfad zu `data/` (JSON + DXF Quelldateien) |
|
||||
| `DXFM_RESULTS` | Pfad zu `results/` (Ausgabe) |
|
||||
|
||||
---
|
||||
|
||||
# set_attributs
|
||||
|
||||
Fuegt Attribute (ATTDEF) zu allen Omniflo DXF-Dateien hinzu und verpackt die
|
||||
gesamte Geometrie in eine benannte Blockdefinition. Die Attribut-Tags und deren
|
||||
Werte werden ueber eine Konfigurationsdatei gesteuert.
|
||||
|
||||
**Voraussetzung:** Die Quelldateien in `data/omniflo/` sollten zuvor durch
|
||||
`set_einfuegepkt.py` verarbeitet worden sein, damit `$INSBASE` korrekt gesetzt ist.
|
||||
|
||||
## Aufruf
|
||||
|
||||
```
|
||||
python lib/set_attributs.py [--number SIVASNR] [--dry-run]
|
||||
```
|
||||
|
||||
## Datenquellen
|
||||
|
||||
| Pfad | Inhalt |
|
||||
|---|---|
|
||||
| `cfg/attradd.cfg` | Attribut-Konfiguration (Tags und Quellfelder je Elementtyp) |
|
||||
| `data/json/omniflo_boegen.json` | Liste aller Boegen mit Metadaten |
|
||||
| `data/json/omniflo_weichen.json` | Liste aller Weichen mit Metadaten |
|
||||
| `data/omniflo/*.dxf` | DXF-Quelldateien (Basis: Ausgabe von `set_einfuegepkt.py`) |
|
||||
|
||||
## Ablauf
|
||||
|
||||
1. Konfiguration aus `cfg/attradd.cfg` lesen
|
||||
2. JSON-Daten laden und Lookup-Tabelle (Sivasnr -> Typ + Eintrag) erstellen
|
||||
3. Fuer jede Sivasnr die DXF-Datei oeffnen, bestehende ATTDEFs entfernen
|
||||
4. Neue ATTDEFs gemaess Config einfuegen (Layer `ATTRIB`, unterhalb der Geometrie)
|
||||
5. Alle Entities (Geometrie + ATTDEFs) in eine Blockdefinition verschieben:
|
||||
- Blockname = Sivasnummer (identisch mit dem Dateinamen ohne `.dxf`)
|
||||
- Basispunkt der Blockdefinition = `$INSBASE` aus dem DXF-Header
|
||||
6. Im Modelspace einen INSERT auf den neuen Block einfuegen, mit ATTRIB-Entities
|
||||
befuellt aus den ATTDEF-Standardwerten (ermoeglicht Attributanzeige per Klick in BricsCAD)
|
||||
7. Ergebnis nach `results/omniflo/` speichern
|
||||
|
||||
## Ausgabestruktur (DXF)
|
||||
|
||||
```
|
||||
BLOCKS
|
||||
BLOCK "<sivasnr>" (Basispunkt = $INSBASE)
|
||||
<Geometrie-Entities>
|
||||
ATTDEF BESCHR = "..."
|
||||
ATTDEF ARTINR = "..."
|
||||
...
|
||||
ENDBLK
|
||||
|
||||
ENTITIES (Modelspace)
|
||||
INSERT "<sivasnr>" at (0, 0)
|
||||
ATTRIB BESCHR = "..."
|
||||
ATTRIB ARTINR = "..."
|
||||
...
|
||||
SEQEND
|
||||
```
|
||||
|
||||
Der INSERT im Modelspace traegt die konkreten Attributwerte und ist in BricsCAD
|
||||
per Klick editierbar. Die Blockdefinition mit ATTDEFs dient als Vorlage fuer
|
||||
den Block-Import via `import_element_as_block` (omniflo_utils.py).
|
||||
|
||||
## Konfiguration (attradd.cfg)
|
||||
|
||||
Die Config-Datei ist im INI-Format mit Abschnitten je Elementtyp.
|
||||
Quellwerte koennen sein:
|
||||
- **JSON-Feldname** (z.B. `ProfilTyp`) - Wert wird aus dem JSON-Eintrag gelesen
|
||||
- **Fester Text** in Anfuehrungszeichen (z.B. `"Omniflo Kurve"`)
|
||||
- **Platzhalter** `{sivasnr}` - wird durch die Sivasnr ersetzt
|
||||
|
||||
### Attribute Omniflo Kurve (Bogen)
|
||||
|
||||
| ATTDEF-Tag | Quelle | Beschreibung |
|
||||
| --- | --- | --- |
|
||||
| `BESCHR` | `ProfilTyp` | Profilbezeichnung aus JSON |
|
||||
| `ARTINR` | `Sivasnr` | Sivas-Artikelnummer |
|
||||
| `TEILEART` | `"Omniflo Kurve"` | Fester Typname |
|
||||
| `RADIUS` | `Radius` | Kurvenradius in mm |
|
||||
| `WINKEL` | `KurvenWinkel` | Kurvenwinkel in Grad |
|
||||
| `SIVASNR_TEF` | `SivasnrTEF` | Sivas-Nr. des TEF-Antriebs (leer = kein Antrieb) |
|
||||
| `LAYER` | *(aus [layer])* | Layer-Name gemaess Kategorisierung |
|
||||
|
||||
### Attribute Omniflo Weiche
|
||||
|
||||
| ATTDEF-Tag | Quelle | Beschreibung |
|
||||
| --- | --- | --- |
|
||||
| `BESCHR` | `ProfilTyp` | Profilbezeichnung aus JSON |
|
||||
| `ARTINR` | `Sivasnr` | Sivas-Artikelnummer |
|
||||
| `TEILEART` | `"Omniflo Weiche"` | Fester Typname |
|
||||
| `WEICHENTYP` | `WeichenTyp` | Weichentyp (Einzelweiche, Doppelweiche, Dreiwegeweiche, ...) |
|
||||
| `WINKEL` | `KurvenWinkel` | Kurvenwinkel in Grad |
|
||||
| `RICHTUNG` | `KurvenRichtung` | Richtungskennung (1=Links, 2=Rechts, 3=Beide, 7=Dreiweg) |
|
||||
| `SIVASNR_TEF` | `SivasnrTEF` | Sivas-Nr. des TEF-Antriebs (leer = kein Antrieb) |
|
||||
| `LAYER` | *(aus [layer])* | Layer-Name gemaess Kategorisierung |
|
||||
|
||||
### CSV-Export-Felder (Merkmale)
|
||||
|
||||
Die Attribute werden beim CSV-Export (`export_csv.py`, aufgerufen ueber `c:EXPORTCSV`) wie folgt in CSV-Merkmale ueberfuehrt.
|
||||
CSV-Format: `Elementnummer;TeileArt;TeileId;Bezeichnung;Anzahl;Merkmale`
|
||||
|
||||
**Omniflo Kurve:**
|
||||
|
||||
| Merkmal | Quelle | Typ |
|
||||
| --- | --- | --- |
|
||||
| `Kurvenwinkel` | JSON `KurvenWinkel` | float |
|
||||
| `Radius` | JSON `Radius` | float |
|
||||
| `Höhe` | Attribut `HOEHE` / Z-Koordinate | string |
|
||||
| `Drehung` | Attribut `DREHUNG` / CAD-Rotation | float |
|
||||
| `SivasNummer` | JSON `Sivasnr` | string |
|
||||
|
||||
**Omniflo Weiche:**
|
||||
|
||||
| Merkmal | Quelle | Typ |
|
||||
| --- | --- | --- |
|
||||
| `Weichentyp` | JSON `WeichenTyp` | string |
|
||||
| `Richtung` | JSON `KurvenRichtung` | string |
|
||||
| `Weichenwinkel` | JSON `KurvenWinkel` | float |
|
||||
| `Höhe` | Attribut `HOEHE` / Z-Koordinate | string |
|
||||
| `Drehung` | Attribut `DREHUNG` / CAD-Rotation | float |
|
||||
| `Antrieb Kurve` | `SivasnrTEF` != null | bool |
|
||||
| `SivasNummer` | JSON `Sivasnr` | string |
|
||||
|
||||
|
||||
Höhe und Drehung werden beim Export selbst aus den Blockinformationen entnommen und dann ins json geschrieben.
|
||||
|
||||
| ATTDEF-Tag | Quelle | Beschreibung |
|
||||
| --- | --- | --- |
|
||||
| `HOEHE` | `"2000"` | Montagehoehe in mm (wird beim Export aus Z-Koordinate aktualisiert) |
|
||||
| `DREHUNG` | `"0"` | Drehwinkel in Grad (wird beim Export aus CAD-Rotation aktualisiert) |
|
||||
|
||||
## Schalter
|
||||
|
||||
### --number SIVASNR / -n SIVASNR
|
||||
|
||||
Nur die angegebene Sivasnr verarbeiten.
|
||||
|
||||
### --dry-run / -d
|
||||
|
||||
Nur anzeigen welche Attribute gesetzt wuerden, ohne DXF-Dateien zu schreiben.
|
||||
|
||||
## Umgebungsvariablen
|
||||
|
||||
| Variable | Verwendung |
|
||||
|---|---|
|
||||
| `DXFM_DATA` | Pfad zu `data/` (JSON + DXF Quelldateien) |
|
||||
| `DXFM_CFG` | Pfad zu `cfg/` (attradd.cfg) |
|
||||
| `DXFM_RESULTS` | Pfad zu `results/` (Ausgabe nach `results/omniflo/`) |
|
||||
|
||||
Alle drei haben Fallback auf relative Pfade vom Projektverzeichnis.
|
||||
|
||||
Reference in New Issue
Block a user