tro_annotate --read-tros: TRO-Handkorrekturen aus BricsCAD, Staubereiche vor dem TRO
- Marker tragen KEY (ID der ID-Datei) und SLOTS (Bauteil je Slot), die Zeichnung die Bauteiltabelle SPS_SKEL_PARTS (XRECORD) fuer "Im Plan waehlen" im Dialog TRO_EDIT (dxfmakros) - --read-tros schreibt geaenderte, neue und geloeschte Marker als Abschnitte edit/edit_add nach cfg/tro_overrides.ini; tro_flow.apply_edits wendet nur diese Arten an (Bauteile mit Lage, exportfest) - --emit-lisp schreibt dazu *TRO-SLOTS* und *TRO-SLOT-KINDS* - model: Lagerlinien zaehlen je TRO (Katalog nur Vorgabe), Mubea-Speicher jetzt 20 Linien (Golden-Datei) - Staubereich als stehendes graues Rechteck direkt vor seinem TRO-Marker (jam_abstand statt jam_versatz); Marker 150 mm, Text 120 mm Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
+109
-31
@@ -89,9 +89,10 @@ Supporting libraries (no CLI of their own, imported by the tools above):
|
||||
reads it, finds each TRO again by the position of its separators, assigns
|
||||
new IDs, writes/extends the file. Used by `tro_flow.py` (read and write) and
|
||||
`tro_annotate.py` (read only). See §4, "TRO-IDs".
|
||||
- **`lib/tro_overrides.py`** — reads the hand-maintained
|
||||
`%SKEL_CFG%\tro_overrides.ini`; only `material_flow.py --connect` still uses
|
||||
it. See §6a.
|
||||
- **`lib/tro_overrides.py`** — reads `%SKEL_CFG%\tro_overrides.ini`. The
|
||||
hand-maintained kinds are only used by `material_flow.py --connect`; the
|
||||
BricsCAD corrections (`edit`/`edit_add`, written by `tro_annotate.py
|
||||
--read-tros`) are applied by `tro_flow.py` and `tro_annotate.py`. See §6a.
|
||||
|
||||
Separate, documentation-only tool (not part of the generator pipeline):
|
||||
|
||||
@@ -367,9 +368,14 @@ colors all come from `lib/tro_catalog.py` — nothing is hard-coded here.
|
||||
| `--renumber` | — | off | Number all TROs afresh along the material flow and rewrite the `[tro]` section of the ID file (early project phase). Renamed IDs are lost; other sections of the file are kept. |
|
||||
| `--id-tolerance` | `MM` (float) | `100.0` | Maximum distance between an ID-file entry and a separator of a TRO for the TRO to count as found again. |
|
||||
|
||||
TROs, types and connections always come from the layout alone;
|
||||
`cfg/tro_overrides.ini` is not read. Errors in the derivation are fixed in
|
||||
`lib/tro_flow.py`, not in a correction file.
|
||||
TROs, types and connections come from the layout. Errors in the derivation
|
||||
are fixed in `lib/tro_flow.py`, not in a correction file. The one exception
|
||||
(since 2026-10-26) are the corrections the SPS programmers make in BricsCAD
|
||||
(§5, "Editing TROs in BricsCAD"): `tro_flow` reads the `edit`/`edit_add`
|
||||
sections of `cfg/tro_overrides.ini` and applies them right after the
|
||||
derivation (`apply_edits`, before positions and links), so the flow diagram,
|
||||
the TRO-JSON and the SCL show the corrected TROs. All other kinds in that file
|
||||
are still ignored here.
|
||||
|
||||
**TRO-IDs** (`lib/tro_ids.py`). The IDs belong to the SPS programmers and must
|
||||
survive a new layout export; the layout `TeileId` changes between exports, the
|
||||
@@ -419,7 +425,12 @@ with:
|
||||
triangle, square, diamond, …; see `TroSymbol` in `tro_catalog.py`) so types
|
||||
are distinguishable even without color;
|
||||
- visible attributes `ID`, `TYPE` (and `FB_BLOCK` with `--fb`); hidden
|
||||
attributes `ITEMS`, `CONFIDENCE`, `SEPARATORS` for downstream tooling;
|
||||
attributes `UID`, `KEY` (the TRO's key in `tro_overrides.ini`: its ID in
|
||||
the ID file), `ITEMS`, `CONFIDENCE` and `SLOTS` (the part per slot,
|
||||
`separator1=0010;switch1=0061;lines=0066,0069`);
|
||||
- the parts of the export that fit a slot (TeileId, kind, drawing position,
|
||||
half bounding box) as XRECORD `SPS_SKEL_PARTS` in the named object
|
||||
dictionary, for the dialog's "pick in drawing" button;
|
||||
- optional directional flow arrows between TROs (`--flow`) and a legend
|
||||
(`--legend`).
|
||||
|
||||
@@ -428,13 +439,39 @@ own `TRO_`-prefixed layers and carries XDATA under the app id
|
||||
`SPS_SKEL_TRO`; a re-run removes exactly those tagged objects (not by layer
|
||||
name) and rebuilds them, so hand-drawn content on the same layers survives.
|
||||
|
||||
Once at least one marker of a given type has been annotated, the `dxfmakros`
|
||||
BricsCAD menu (`SSG_LIB > TRO`) can insert further markers of that type by
|
||||
hand — `TRO_INSERT` reuses the `TRO_SYM_<Typ>` block definition this tool
|
||||
created and only asks for a point, an id and (optionally) a different type;
|
||||
`TRO_EDIT` changes `ID`/`TYPE` on an existing marker. Neither command draws
|
||||
new shapes — a type with no prior annotated instance in the drawing must be
|
||||
run through this tool at least once first.
|
||||
**Editing TROs in BricsCAD (since 2026-10-26).** The `dxfmakros` commands
|
||||
`TRO_EDIT` (double-click on a marker) and `TRO_INSERT` (`SSG_LIB > TRO`)
|
||||
share **one** dialog for all types (`dcl/tro_edit.dcl`): ID, type, and a list
|
||||
with one row per slot of the type (`separator<n>`, `switch<n>`, `scanner<n>`,
|
||||
`drive`, storage lines `line1..N`) and its part (TeileId). The rows come from
|
||||
the type (`*TRO-SLOTS*` in `tro_types.lsp`, written by `--emit-lisp` from
|
||||
`model.slot_names`), so there is no mask per type; on a type change, slots
|
||||
of the same name keep their part. Below the list: edit the selected slot's
|
||||
TeileId, **"Im Plan waehlen <"** (closes the dialog, takes a point, sets the
|
||||
nearest part of a kind that fits the slot — `model.SLOT_PART_KINDS` — from
|
||||
the `SPS_SKEL_PARTS` table) and +/- for storage lines (the catalog count is
|
||||
only the default). Empty separators, parts used twice or in another marker
|
||||
show as a warning; saving is still allowed. `TRO_INSERT` reuses a
|
||||
`TRO_SYM_<Typ>` block definition this tool created and leaves `KEY` empty
|
||||
(= new TRO); a type with no annotated instance in the drawing must be run
|
||||
through this tool once first. Deleting a marker deletes the TRO.
|
||||
|
||||
Back into the pipeline: save the drawing as DXF and run `--read-tros`. It
|
||||
compares every marker with the derivation **without** corrections: a marker
|
||||
whose `KEY` is a derived TRO becomes `[<csv>.edit.<KEY>]` if type, ID (→
|
||||
`name =`) or parts differ; a marker without such a key becomes
|
||||
`[<csv>.edit_add.<ID>]`; a derived TRO with a position but no marker becomes
|
||||
`delete = true`. Each part is written as `TeileId @ x y` (CSV position) — the
|
||||
TeileId changes between exports, the position does not, so `apply_edits`
|
||||
falls back to the nearest part of the same kind at that spot. The sections
|
||||
replace all earlier `edit`/`edit_add` sections of the CSV in
|
||||
`tro_overrides.ini` (a `reason =` added by hand is kept); the rest of the file
|
||||
stays line for line. The next `tro_flow` / `tro_annotate` run applies them
|
||||
(§4); a re-read of the new drawing gives the same sections. `--check` only
|
||||
reports. If the drawing has no marker of the derived TROs (wrong file, or
|
||||
annotated before the `KEY`/`SLOTS` attributes), nothing is written —
|
||||
re-annotating an old drawing adds the missing attributes to the existing
|
||||
block definitions.
|
||||
|
||||
CSV and DXF live in different coordinate systems; the offset between them is
|
||||
handled by `dxf_registration.py`: by TeileId when the drawing's blocks carry
|
||||
@@ -450,22 +487,26 @@ verified on every run, and cached per CSV/DXF filename pair in
|
||||
| `--flow` | — | off | Draw directional flow arrows between the TROs. |
|
||||
| `--fb` | — | off | Show the Siemens FB block name as a visible attribute on the marker. |
|
||||
| `--legend` | — | off | Draw a legend of the color groups. |
|
||||
| `--marker-size` | `MM` (float) | `300.0` | Marker radius in mm. |
|
||||
| `--text-height` | `MM` (float) | `220.0` | Text height in mm. |
|
||||
| `--marker-size` | `MM` (float) | `150.0` | Marker radius in mm (`default_marker` in `cfg/parameter.ini`). |
|
||||
| `--text-height` | `MM` (float) | `120.0` | Text height in mm (`default_text`; the ID is 1.35×). |
|
||||
| `--ids` | `DATEI` | `<csv-stem>_tro_ids.ini` | ID file as for `tro_flow.py`, **read only**: the markers carry the same IDs as the TRO-JSON. Without the file the TROs are numbered along the material flow, as `tro_flow.py` would. |
|
||||
| `--offset` | `DX,DY` | — | Set the CSV↔DXF offset by hand instead of deriving/loading it. For a drawing built with dxfmakros (CSV exported from the same drawing) this is `0,0`. |
|
||||
| `--re-register` | — | off | Re-derive the coordinate offset even if a verified one is already cached in `%SKEL_CFG%`. |
|
||||
| `--check` | — | off | Dry run: only analyze and report, write no output file. |
|
||||
| `--emit-lisp` | — | off | Regenerate `cad/tro_types.lsp` (the type list for the `TRO_INSERT`/`TRO_EDIT` dialogs) from `tro_catalog.py` and exit — no `--dxf` needed. Written under `%DXFM_LISP%` if set (next to the `dxfmakros` SSG_LIB modules that provide the dialogs), otherwise under `<SPS_SKEL>/cad`. |
|
||||
| `--emit-lisp` | — | off | Regenerate `cad/tro_types.lsp` for the `TRO_INSERT`/`TRO_EDIT` dialog — type list (`*TRO-TYPES*`), slots per type with the storage-line default (`*TRO-SLOTS*`), part kinds per slot (`*TRO-SLOT-KINDS*`) — from `tro_catalog.py`/`model.py` and exit — no `--dxf` needed. Written under `%DXFM_LISP%` if set (next to the `dxfmakros` SSG_LIB modules that provide the dialogs), otherwise under `<SPS_SKEL>/cad`. |
|
||||
| `--anlage` | `NAME` | — | Plant JSON (`<csv>_anlage.json` from `merge_hw_layout`, in `%SKEL_RESULTS%` or a path): also draw the **jam areas** (see below). Must belong to the same CSV. |
|
||||
| `--read-jams` | `[DXF]` | `<csv>_annotated.dxf` | Read the jam-area numbers edited in BricsCAD back from the annotated drawing (saved as DXF) into `%SKEL_CFG%\<csv>_jam_names.ini`, then exit — no `--dxf` needed. |
|
||||
| `--read-tros` | `[DXF]` | `<csv>_annotated.dxf` | Read the TRO markers edited in BricsCAD (`TRO_EDIT`/`TRO_INSERT`, deleted markers) back from the annotated drawing (saved as DXF) into the `edit`/`edit_add` sections of `%SKEL_CFG%\tro_overrides.ini`, then exit — no `--dxf` needed. With `--check` only reported. |
|
||||
|
||||
**Jam areas (`--anlage`).** One block `JAM_AREA` per jam area of the plant
|
||||
JSON on layer `TRO_JAM`: a small rectangle with the name inside
|
||||
(`Jam0054_3`, the same name the SCL uses — `scl_context.jam_numbers` plus the
|
||||
corrections file). It sits `jam_versatz` mm (`cfg/parameter.ini
|
||||
[tro_annotate]`) in front of its separator, towards the predecessor TRO,
|
||||
where the carriers wait. Hidden attributes: `CONVEYOR` (NNNN), `NUMBER` (k),
|
||||
JSON on layer `TRO_JAM`: an upright grey rectangle with the name written
|
||||
vertically inside (`Jam0054_3`, the same name the SCL uses —
|
||||
`scl_context.jam_numbers` plus the corrections file). It sits directly in
|
||||
front of its TRO marker — marker radius + `jam_abstand` mm (`cfg/parameter.ini
|
||||
[tro_annotate]`) from the marker — towards the predecessor TRO (against the
|
||||
flow, where the carriers wait; with only a station before it, opposite to the
|
||||
successor). A second entry (2Sep types) sits next to the first. Only the
|
||||
position is derived this way; connections and flow direction are untouched. Hidden attributes: `CONVEYOR` (NNNN), `NUMBER` (k),
|
||||
`TRO` + `ENTRY` (the stable key, `scl_context.jam_key`), `AREA` (J0039) and
|
||||
`AUTO` (the derived NNNN_k). A jam area without a conveyor shows
|
||||
`Jam????_?`. Double-click opens the dialog **`JAM_EDIT`** (dxfmakros:
|
||||
@@ -478,8 +519,9 @@ that are back at `AUTO`. `scl_skeleton` with a plant JSON reads that file, and
|
||||
the next `--anlage` run draws it, so drawing, file and SCL agree. Invalid
|
||||
values (conveyor not four digits, number < 1) are reported and skipped.
|
||||
|
||||
Layers always carry the prefix `TRO_`. Like `tro_flow.py`, it never reads
|
||||
`cfg/tro_overrides.ini`, so the markers always match the flow diagram.
|
||||
Layers always carry the prefix `TRO_`. Like `tro_flow.py`, it reads only the
|
||||
`edit`/`edit_add` sections of `cfg/tro_overrides.ini`, so the markers always
|
||||
match the flow diagram and the TRO-JSON.
|
||||
|
||||
**Output** (in `%SKEL_RESULTS%`, unless `--check`): `<name>_annotated.dxf`,
|
||||
`<name>_registration.json` (the coordinate transform used, with its proof).
|
||||
@@ -526,7 +568,9 @@ drawing is the current state, not the export.
|
||||
It finds the objects `tro_annotate.py` tagged with XDATA (AppID
|
||||
`SPS_SKEL_TRO`): the `TRO_SYM_<type>` block references (attributes
|
||||
`ID`/`TYPE`/`ITEMS`/`CONFIDENCE`/`SEPARATORS`, plus `FB_BLOCK` when annotated
|
||||
with `--fb`), the flow arrows (`"<from>-><to>"`), and the open-point markers
|
||||
with `--fb`; since 2026-10-26 the markers carry `SLOTS` instead of
|
||||
`SEPARATORS`, so the separators come back empty — the way back from the
|
||||
drawing is now `tro_annotate --read-tros`), the flow arrows (`"<from>-><to>"`), and the open-point markers
|
||||
(`"OFFEN:<name>"`). Each TRO also gets `predecessors`/`successors` computed
|
||||
from the arrows.
|
||||
|
||||
@@ -562,7 +606,10 @@ renamed key, or `items`/`fbType` that do not match the TRO type in
|
||||
no SCL is written. A file with a different schema (e.g. the old
|
||||
`tro_extract.py` output) gets a short message asking for `tro_flow --json`.
|
||||
Part counts (`items`) and the FB type are taken from the catalog via the TRO
|
||||
type.
|
||||
type — except the storage lines (since 2026-10-26): the catalog count (19 for
|
||||
`PinStore_Auto`) is only the default; a TRO with storage lines counts its own
|
||||
(layout or BricsCAD correction), so the Mubea store shows 20. A TRO-JSON
|
||||
written before still reads (the catalog count is accepted too).
|
||||
|
||||
Produces a **skeleton, not a running program**: one `REGION` per TRO with the
|
||||
instance call and every parameter line in the right order, following the real
|
||||
@@ -1037,11 +1084,42 @@ wrong keys/items, SCL rendering from a document) — run with
|
||||
|
||||
## 6a. `tro_overrides.py` — manual corrections to the derived TROs (library, no CLI)
|
||||
|
||||
> **Since 2026-10-05 only `material_flow.py --connect` reads this file.**
|
||||
> `tro_flow.py` and `tro_annotate.py` no longer apply corrections: the sections
|
||||
> were keyed on running TRO numbers and went stale with every new export.
|
||||
> Errors in the TRO derivation are fixed in `lib/tro_flow.py` instead. The
|
||||
> format below is kept for `material_flow.py`.
|
||||
> **Since 2026-10-05 only `material_flow.py --connect` reads the hand-written
|
||||
> kinds below** (`tro`, `split`, `merge`, `openpoint`, `connections`).
|
||||
> `tro_flow.py` and `tro_annotate.py` no longer apply them: the sections were
|
||||
> keyed on running TRO numbers and went stale with every new export. Errors in
|
||||
> the TRO derivation are fixed in `lib/tro_flow.py` instead.
|
||||
>
|
||||
> **Since 2026-10-26 the file also holds the BricsCAD corrections** (kinds
|
||||
> `edit`, `edit_add`), and those *are* applied by `tro_flow.py` and
|
||||
> `tro_annotate.py` (`tro_flow.apply_edits`). They are keyed on the ID from
|
||||
> `<csv>_tro_ids.ini`, which stays stable across exports, and their parts carry
|
||||
> a position. They are written by `tro_annotate.py --read-tros` (see §5),
|
||||
> not by hand:
|
||||
>
|
||||
> ```ini
|
||||
> [mubea.csv.edit.TRO05] ; derived TRO, key = ID in the ID file
|
||||
> type = 1Sep1Swi ; omitted = as derived
|
||||
> name = Einschleus_K2 ; new ID (the ID file keeps TRO05)
|
||||
> separator1 = 0012 @ -400.0 -3554.9 ; part per slot: TeileId @ x y (CSV)
|
||||
> switch1 = - ; slot deliberately empty
|
||||
> lines = 0066 @ 958.0 12300.0, 0069 @ 958.0 11500.0 ; storage lines
|
||||
> reason = ... ; may be added by hand, survives re-reads
|
||||
>
|
||||
> [mubea.csv.edit.TRO19]
|
||||
> delete = true
|
||||
>
|
||||
> [mubea.csv.edit_add.TRO99] ; new TRO from TRO_INSERT
|
||||
> type = 1Sep
|
||||
> separator1 = 0036 @ 1475.0 -5078.0
|
||||
> ```
|
||||
>
|
||||
> If slot keys are present they are the complete set (missing slots stay
|
||||
> empty); without them the parts stay as derived. Order of application:
|
||||
> deletes, edits, adds, renames last. A part given to an edited/added TRO is
|
||||
> taken from the TRO that had it; a TRO left without its separators is dropped
|
||||
> (finding). Renamed and added TROs are not written under their new ID into
|
||||
> the ID file (`Analysis.renamed`/`added`).
|
||||
|
||||
`tro_flow.py` derives TRO types from the mechanical layout alone. Some things
|
||||
are simply not in the CSV export: a switch that the export does not carry, a
|
||||
|
||||
Reference in New Issue
Block a user