- lib/model.py (neu, pydantic): TroBase -> DerivedTro, Connection, OpenPoint,
Analysis (aus tro_flow verschoben), TroDocument = TRO-JSON (Schema
sps_skel-tro-v2). items/fbType werden immer ueber den Typ aus tro_catalog
gelesen, nie gespeichert; abweichende Werte in einer JSON sind ein Fehler.
JSON-Schluessel wie bisher (id, type, fbType ...), extra="forbid".
- tro_flow: Tro/Analysis aus model.py; neuer Schalter --json schreibt
<name>_tro.json (TroDocument)
- scl_skeleton: liest die JSON ueber TroDocument statt per Dict-Zugriff,
Bauteile ueber TroItem-Konstanten; ungueltige JSON -> Exit 1 ohne SCL,
alte tro_extract-JSON (v1) mit Hinweis auf tro_flow --json
- tro_annotate: nur noch Ansicht; derselbe analyse_tros-Aufruf wie tro_flow
(inkl. sepliste-Gegenprobe), damit Zeichnung und JSON uebereinstimmen
- tro_extract: geparkt (unveraendert)
- tests/test_model.py + conftest.py, pytest in requirements.txt aktiviert
- Doku: Python_Scripts.md (§6b model.py), Commandlines.md, CLAUDE.md,
Aufrufkommentare in bin/ (scl_skeleton.bat zeigte tro_flow-Aufrufe)
Geprueft: alle tro_flow/tro_annotate-Ausgaben (8 CSVs) bis auf Zeitstempel
identisch zum vorherigen Stand; scl_skeleton alt/neu auf derselben JSON
byte-identisch (export, mubea, HundM05); 10 Tests gruen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- --max-residual: feste Grenze DEFAULT_MAX_RESIDUAL (600 mm), Meldung
verweist auf --offset
- --layer-prefix: Layer immer mit Praefix TRO_
- --use-overrides: cfg/tro_overrides.ini wird nie gelesen, Marker passen
damit immer zum TRO-Fluss
- damit toter Code entfernt: draw_open_points, Layer TRO_OPENPOINT,
Berichtszeilen Offene Punkte/Typkorrekturen (Daten kamen nur aus der INI)
- --emit-lisp bleibt (einziger Weg, tro_types.lsp fuer TRO_INSERT/TRO_EDIT
nach einem neuen Katalogtyp neu zu schreiben)
- doc/Python_Scripts.md nachgezogen
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
scl_skeleton.py brach mit KeyError ab, sobald der TRO-Fluss Stationen
(SYSn) enthielt. Stationen bekommen jetzt keine REGION/Instanz, der von
einer Station gespeiste TRO ist der Anfang der Reihenfolge, in den
Staubereich-Kommentaren sind sie als Station markiert.
tro_annotate.py liess Verbindungen unter 2,2 Markergroessen still weg
(HundM05 TRO03->TRO04, 500 mm) - sie fehlten dann in tro_extract.py und
in der SCL. Kurze Verbindungen werden jetzt Mitte-zu-Mitte gezeichnet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tro_flow:
- _station_positionen: Richtung des Zu-/Ablaufpfeils mit groesstem
Winkelabstand zu allen Kanten des Anker-TROs und zu bereits gesetzten
Stationspfeilen (15-Grad-Raster), echte Stationsrichtung nur bei
Gleichstand - vorher lag z. B. Mubea TRO02 -> SYS2 fast auf TRO02 -> TRO13
tro_annotate:
- Symbole mit typ-eigener Fuellfarbe (Solid-Hatch) unter der Gruppenkontur
- Kantenfarben/-layer wie im SVG: Uebergabe blau, Weiche orange,
Materialeingang gruen, Materialausgang rot (TRO_WEICHE/_EINGANG/_AUSGANG)
- Stationen als farbige Beschriftung am Pfeilende, Lage ueber
tro_flow._station_positionen (ohne CONNECTION_ARROW-Block)
- Legende wie im SVG: je vorkommendem Typ Fuellung/Rand/Form, dann Kantenfarben
- CONNECTION_ARROW: FROM_TRO/TO_TRO unsichtbar (Daten bleiben), KIND auch weiche
cfg/dxf_registration.json: mubea.csv|mubea.dxf und HundM05.csv|HundM05.dxf
mit Versatz 0 (CSV aus derselben dxfmakros-Zeichnung; Auto-Ermittlung sieht
die verschachtelten Separatoren nicht und war mehrdeutig);
mubea.csv|500573_60_1.dxf neu ermittelt (36/46 Punkte).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- tro_flow/tro_annotate: cfg/tro_overrides.ini nur noch mit --use-overrides
(die Abschnitte haengen an laufenden TRO-Nummern und am CSV-Namen und
veralten mit jedem Export; [export.csv.connections] ersetzte alle
abgeleiteten Kanten und liess TRO13-20 unverbunden)
- link_tros: Separatoren mit Zuordnung auf eine Strecke, die in keiner
TrackIds-Liste stehen, per Projektion AS->ES in die Strecken-Kette
einsortieren (Mubea VF_3: 0037/0038 erzeugten je 9 Fehlkanten;
mubea 38 -> 22 Verbindungen, HundM05 unveraendert)
- tro_catalog: typ-eigene Fuellfarbe je TRO-Typ, Mermaid-classDefs je Typ
- tro_overrides/tro_flow: connect.ini zurueck einlesen (--from-connect)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each TRO marker gains a UID attribute: a unique, permanent four-digit number in
the same space as the TeileId of the CSV export and the ID attribute of SSG_LIB
(dxfmakros/Lisp/ssg_id.lsp). The visible ID (TRO03) is untouched - it stays the
speaking name that TRO_EDIT and TRO_INSERT work with. The UID is a separate tag
on purpose: IDSCHECK treats ID as numeric and would overwrite TRO03 with a number
while correcting duplicates.
Numbers are allocated above the highest already in use, taken from two sources -
the ID attributes of the drawing and the TeileId of every CSV object. The second
source is the one that matters here: a mechanical drawing not built with SSG_LIB
carries no ID attributes at all (in the Mubea plan only 10 of 669 blocks have any
attributes), so without it the run would start at 0001 and take numbers the CSV
already uses for components. With it the markers start at 0062, above TeileId
0061.
With --flow each edge now also gets a CONNECTION_ARROW block at the midpoint of
the arrow, rotated along it, holding FROM_UID/TO_UID plus FROM_TRO/TO_TRO as
readable text and KIND. That makes the relationship extractable from a DXF export
and stable when a marker is moved or renamed. The shaft and head stay separate
geometry: a block with fixed geometry cannot span two arbitrary points, and
scaling it in X would distort the arrowhead.
Block name prefix CONNECTION_ so the SSG_BLOCKEDIT dispatcher in dxfmakros picks
it up via "CONNECTION_*".
Verified on the real drawing: 10 markers with UIDs 0062-0071, 29 connections with
UIDs 0072-0100, every FROM_UID/TO_UID matching its marker, all 39 UIDs unique.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The TRO edit dialog belongs with the other SSG_LIB edit commands, so
cad/tro_edit.lsp and cad/tro_edit.dcl move to dxfmakros (Lisp/Tro_Edit.lsp,
dcl/tro_edit.dcl) where they use the ssg_* helpers, the DXFM_DCL path and the
existing SSG_BLOCKEDIT dispatcher instead of standing on their own. Keeping a
second copy here would only let the two drift apart before the repos are merged.
--emit-lisp now writes the generated type list to DXFM_LISP when that variable is
set, so it lands next to the SSG_LIB modules that read it. Without the variable it
still writes to cad/ and says where the file actually belongs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Replaces the generic marker with one shape per type, so the types are
distinguishable in the drawing without relying on colour. The shape belongs to
the type, so it sits in tro_catalog next to the colour - colour groups (6 groups),
shape identifies (10 types):
1Sep circle 1Sep1Swi triangle 1Sep2Swi pentagon
1Sep_SSCC 2 circles Vario rectangle Vario_workStation hexagon
PinStore_Auto square EmptyCarrBuffer diamond
LoadingBoom arrow 2Sep1Swi triangle down
The visible attributes are now ID and TYPE, as those are what the dialog edits;
FB_BLOCK stays visible under --fb and ITEMS/CONFIDENCE/SEPARATORS stay hidden
data. Note this renames the former TRO_ID/TRO_TYPE tags, so drawings annotated
with an earlier version need regenerating.
Marker layers now take the *stroke* colour instead of the fill. A CAD symbol is
line work, and the pastel fills of the palette were nearly invisible as lines -
LoadingBoom in particular came out almost white on white.
cad/tro_edit.dcl and cad/tro_edit.lsp add the TROEDIT command: pick a TRO_SYM_*
block, edit ID and TYPE, write back on OK. TYPE is a picklist rather than free
text so it cannot drift from the catalogue; the list comes from cad/tro_types.lsp,
which "tro_annotate.py --emit-lisp" generates from TRO_CATALOG. If that file is
missing the dialog degrades to the block's current type instead of failing.
The dialog deliberately changes attributes only. The marker shape belongs to the
block definition of the type and FB_BLOCK is derived from it, so both follow on
the next annotation run - the dialog says so, and TROEDIT prints a reminder when
the type was changed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Takes the original DXF, the CSV export and the derived TROs and writes a copy of
the drawing with the TRO information overlaid. The original is never touched.
Per TRO a block marker with attributes, not loose geometry: one block definition
per type (TRO_SYM_<type>), inserted at the plant coordinate, carrying TRO_ID,
TRO_TYPE, FB_BLOCK visibly and ITEMS, CONFIDENCE, SEPARATORS as hidden data.
That makes the result queryable and editable inside BricsCAD, and a corrected
TRO_ID can later feed back into the generator.
Layers follow the colour groups of tro_catalog (TRO_MARKER_sep, _vario, _store,
...) with the group colour as true colour and entities BYLAYER, so the layer
manager filters by TRO type. Flow arrows and the legend get their own layers.
Re-runs are idempotent through XDATA, not layer names: every generated entity is
tagged with the SPS_SKEL_TRO appid and a re-run deletes exactly those. Deleting
by layer would also destroy anything a user had put on the same layer.
Switches follow the other tools; --check reports the registration and what would
be drawn without writing, --flow adds the TRO-level arrows, --fb shows the
function block, --offset and --re-register override the stored transform. DWG is
rejected with a clear message since ezdxf cannot read it.
Verified against the real 23.8 MB drawing: 9 markers on the correct layers with
readable attributes, 15 flow arrows, and a re-run replaces its own 46 entities
instead of duplicating them.
Adds ezdxf to requirements and stores the verified Mubea transform in cfg/.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Michael StanglandClaude Opus 5.5
Samer AyadiandClaude Opus 5.5