# Mubea — Material Flow & TROs (from the dxfmakros layout)

**As of:** 2026-08-07 · **Source:** `data/export.csv` (113 rows, fresh `EXPORTCSV`) · **Plant:** Mubea 500573 "Sitzbezügelager"

> **Update (2026-08-07 — material flow rebuilt from the richer `export.csv`).**
> The new export adds the **transfer/switch elements** — 23 Einschleuselement, 23
> Ausschleuselement, 1 Weiche — and fully populated `Nachbarn`. `material_flow.py` now
> **uses the Ein-/Ausschleuselement to direct every Kreisel↔Strecke edge**
> (`Ausschleusung` = Kreisel→Strecke at the strecke's *Anfang*, `Einschleusung` =
> Strecke→Kreisel at its *Ende*) instead of guessing from heights, and **marks the Weiche**
> on the Kreisel↔Kreisel link. Result: directions are now deterministic (no more "unknown
> type" warnings, ambiguities resolved). Two return-lane ends remain unreachable **on
> purpose** — they are the open ends the **BTMT entry/exit (Beladung/Entladung)** will close
> once those stations are placed. *The TRO section further below still reflects the earlier
> `mubea.csv` run and is regenerated in the **next** step.*

> **How to read this.** The Mubea layout was drawn in BricsCAD with our **dxfmakros**
> library, so every conveyor object is a real, attributed item. dxfmakros exported those
> items — with their **coordinates, properties and neighbours** — to `mubea.csv`. From that
> CSV the `lib/` tooling derives two graphs, both **laid out at the real plant coordinates**
> so they match the drawing:
>
> 1. the **material-flow graph** — the mechanical objects and how material moves between them;
> 2. the **TRO graph** — the control units (Transfer Route Objects) derived from that flow.
>
> This is generated output, not hand-authored — see [§5](#5-how-this-was-produced) to regenerate.
> (The earlier [TRO_Identifikation_500573.md](TRO_Identifikation_500573.md) was a manual first
> pass on a *different*, purely mechanical drawing; **this** file supersedes it for Mubea.)

---

## 1. The plant in one paragraph

Empty hanger carriers (**Bügelträger**) circulate on three rotary tables (**Kreisel**) linked
by driven conveyor segments (**VarioFörderer / Strecke**). The core is a **line store** of
**20 gravity lanes** (**Gefällestrecke**), each with its own separator, sharing a common
in-/outfeed — i.e. one **PinStore**. Barcode **scanners** read carriers at three points.

**Item inventory (from `export.csv`):**

| Item type (German) | Meaning | Count | Role in the graph |
|---|---|---:|---|
| `ILS 2.0 Gefaellestrecke` | gravity lane (rolls down by slope) | 20 | node |
| `ILS 2.0 Separator` | stopper / separator (releases one carrier) | 33 | attached (`Zuordnung`) |
| `ILS 2.0 Scanner` | barcode scanner | 7 | attached (`Zuordnung`) |
| `ILS 2.0 Kreisel` | rotary table / turntable (2 lanes each) | 3 | node (2 lanes each) |
| `ILS 2.0 Strecke` | driven conveyor segment (VarioFörderer) | 3 | node |
| `ILS Ausschleuselement` | Kreisel→Strecke transfer (at strecke *Anfang*) | 23 | **directs an edge** |
| `ILS Einschleuselement` | Strecke→Kreisel transfer (at strecke *Ende*) | 23 | **directs an edge** |
| `ILS Weiche` | switch between two Kreisel | 1 | **marks an edge** |
| **Total** | | **113** | |

The transfer/switch elements don't become their own nodes — they supply the **direction** of
the Kreisel↔Strecke edges and mark the Weiche, so the graph stays at the conveyor-object level.

---

## 2. Material-flow graph (real-layout placement)

Nodes are placed at their true plant coordinates (`neato -n`, 0.25 pt/mm), so the picture
matches the drawing: the 20 gravity lanes form the central vertical stack, fed by **Kreisel 3**
(left) and discharging into **Kreisel 2** (right).

![Material-flow graph](graphs/mubea_material_flow.svg)

> Open [`graphs/mubea_material_flow.svg`](graphs/mubea_material_flow.svg) for the full-resolution,
> zoomable version. Full node/connection listing: [`graphs/mubea_material_flow_report.md`](graphs/mubea_material_flow_report.md).

### 2.1 Items with their properties (flow objects)

Separators and scanners are *attachments* — they appear in the last two columns of the object
they sit on. A **Kreisel** is a loop, modelled as two lanes (`-L` / `-R`).

| Node | Type | Name | Grid | Height [m] | Separators | Scanners |
|---|---|---|---|---:|---|---|
| `0001-L` | Kreisel | Kreisel 3 (lane L) | A/1 | 1.470 | – | – |
| `0001-R` | Kreisel | Kreisel 3 (lane R) | A/1 | 1.470 | 0057 | – |
| `0002-L` | Kreisel | Kreisel 2 (lane L) | A/1 | 1.470 | 0003, 0010, 0011 | 0006 |
| `0002-R` | Kreisel | Kreisel 2 (lane R) | A/1 | 1.470 | – | – |
| `0009-L` | Kreisel | Kreisel 1 (lane L) | F/1 | 1.940 | – | – |
| `0009-R` | Kreisel | Kreisel 1 (lane R) | F/1 | 1.940 | 0059, 0060 | – |
| `0012` | Strecke | VarioFörderer 3 | A/10 | 0.237 | 0014, 0058 | – |
| `0013` | Strecke | VarioFörderer 2 | A/1 | 0.237 | 0056, 0061 | 0005 |
| `0015` | Strecke | VarioFörderer 1 | A/3 | 0.000 | – | 0008 |
| `0016`–`0035` | Gefällestrecke ×20 | Gravity lanes 1–20 | E/2–E/10 | 1.941 | one each (0036–0055, +0004) | – |

*Coordinates, heights and the `Merkmale` (feature) properties per item are carried through from
the CSV; the full per-lane table is in the [material report](graphs/mubea_material_flow_report.md).*

---

## 3. TRO graph (control units)

The TROs are **derived** from the material flow using the rules in `lib/tro_flow.py`
(catalogue: `lib/tro_catalog.py`). The graph is placed at the same real coordinates.

![TRO graph](graphs/mubea_tro_flow.svg)

> Full-resolution: [`graphs/mubea_tro_flow.svg`](graphs/mubea_tro_flow.svg) ·
> full report incl. connections & rules: [`graphs/mubea_tro_report.md`](graphs/mubea_tro_report.md).

### 3.1 Result: 10 TROs

| Type | FB block | Count | Components per TRO |
|---|---|---:|---|
| `1Sep` | `FB_ILS_MTRO_1Sep` | 6 | 1× separator |
| `Vario` | `FB_ILS_MTRO_Vario` | 3 | 1× separator, 1× drive |
| `PinStore_Auto` | `FB_ILS_MTRO_PinStore_Auto` | 1 | 1× encoder, 1× scanner, 1× separator, 19× storage line |

### 3.2 TROs with their properties

| TRO | Type | X [mm] | Y [mm] | Host node(s) | Separators | Scanner | Why this type | Confidence |
|---|---|---:|---:|---|---|---|---|---|
| `TRO01` | `1Sep` | 5355 | −5878 | `0001-R` | 0057 | – | single separator on a driven Kreisel lane | medium |
| `TRO02` | `1Sep` | −400 | 13920 | `0002-L` | 0003 | – | single separator on a driven Kreisel lane | medium |
| `TRO03` | `1Sep` | −220 | −481 | `0002-L` | 0010 | 0008 | separator + scanner on a driven Kreisel lane | medium |
| `TRO04` | `1Sep` | −220 | −3472 | `0002-L` | 0011 | 0006 | separator + scanner on a driven Kreisel lane | medium |
| `TRO05` | `1Sep` | 10490 | −525 | `0009-R` | 0059 | 0007 | separator + scanner on a driven Kreisel lane | medium |
| `TRO06` | `1Sep` | 10310 | 160 | `0009-R` | 0060 | – | single separator on a driven Kreisel lane | medium |
| `TRO07` | `Vario` | 9186 | 13893 | `0012` | 0014, 0058 | – | driven conveyor segment (drive dir: up) | high |
| `TRO08` | `Vario` | 5492 | −4980 | `0013` | 0056, 0061 | – | driven conveyor segment (drive dir: up) | high |
| `TRO09` | `Vario` | −641 | 5859 | `0015` | – | – | driven conveyor segment (drive dir: up) | high |
| `TRO10` | **`PinStore_Auto`** | 989 | 3924 | `0016 … 0035` (20 nodes) | 0004 … 0055 (21) | 0005 | **20 gravity lanes, each with its own separator, common in-/outfeed — the line-store pattern** | high |

*X/Y is the centroid of the components a TRO was built from (in the CSV plant coordinate system).*

---

## 4. Findings to confirm with the E-planning

The TRO **types** are solid; a few points can't be decided from the mechanical layout alone:

- **`1Sep` vs `1Sep_SSCC`.** TRO03, TRO04, TRO05 each have a scanner at the separator. They are
  typed `1Sep`; whether any is really `1Sep_SSCC` (SSCC scanner + end-measurement + WCS telegram)
  cannot be seen mechanically — confirm against the I/O list.
- **Scanner mounting vs. reading point.** Scanner 0005 is mounted on `0013` but reads at
  separator 0004 on lane `0035`; scanner 0008 is mounted on `0015` but reads at separator 0010.
  (Noise from the export; noted, not fatal.)
- **Two flow directions undetermined** around the Kreisel↔Strecke hand-overs (neighbours at equal
  height) — drawn bidirectional in the material graph until the drive directions are confirmed.
- **CSV plausibility deltas** (stated `Anzahl_Separator`/`Anzahl_Scanner` vs. actually attached)
  are listed in the material report — worth a quick check in the drawing.

What is **not** derivable here and must come from the electrical planning / `FB_Main`: the binding
TRO numbering, sensor/actuator tags, JamAreas, destination logic and timing.

---

## 5. How this was produced

```bat
:: 1) items + material flow, placed at real coordinates
bin\material_flow.bat --file mubea.csv --tosvg --use-cords --doc

:: 2) derive the TROs, placed at real coordinates
bin\tro_flow.bat --file mubea.csv --tosvg --use-cords --doc
```

Outputs land in `%SKEL_RESULTS%` (`results/`); the SVGs and reports here are copies. The
`--use-cords` flag (new for `material_flow.py`, matching `tro_flow.py`) places every node at its
plant coordinate and renders with Graphviz `neato -n`, so both graphs mirror the real layout.

**Next step (later, not now):** feed these TROs back into the BricsCAD drawing as TRO symbols
with their connections (`lib/tro_annotate.py` → `results/mubea_annotated.dxf`, then the
`dxfmakros` `TRO_INSERT` / `TRO_EDIT` menu), and record neighbours in `connect.ini`.

---

## 6. Entry / exit points (BTMT Be-/Entladestation) & data freshness

The **entry and exit points** of the material flow are the **BTMT Be-/Entladestation**
(`BTMT-Beladung` = loading = **entry/source**, `SC_Entladung` = unloading = **exit/sink**).
`material_flow.py` now **recognises them** (matched on `TeileArt`/`Bezeichnung`): an entry
becomes a green source node feeding the flow, an exit a red sink node — connected via the
export's `Nachbarn`, or to the nearest object if none is given.

Two current limitations to be aware of:

1. **The stations are not in the drawing / CSV yet.** They are not placed in `Mubea.dxf`,
   and — importantly — dxfmakros' `EXPORTCSV` does **not** export them at all (their block
   names match no export pattern; dxfmakros docs mark this *"Export noch offen"*). So a
   freshly exported CSV still won't contain them until either the export is extended in
   dxfmakros or the rows are added by hand. The sps_skel recognition is ready for that moment.
2. **The TRO graph does not yet show entry/exit.** `tro_flow.py` ignores the stations for
   now (they carry no separator, so they are not TROs). Adding them as boundary markers in
   the TRO graph is the planned follow-up, best done against a real BTMT row.

**On reading straight from the DXF instead of the CSV:** ezdxf reads `Mubea.dxf` fine (2.6 s)
and gives correct item positions + attributes, but it **cannot reproduce the 3-D bounding
boxes** that dxfmakros' neighbour detection relies on (`export_neighbors.py`, from BricsCAD's
`vla-getboundingbox`) — so a BricsCAD-free reader can place items but not rebuild the
connections reliably. The reliable path to *current* data is therefore a fresh
`EXPORTCSV` run in BricsCAD; the graphs above are then regenerated with the two commands in §5.