sps_skel/doc/500573_Mubea/Materialfluss_und_TROs_Mubea.md

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 to regenerate. (The earlier 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).

Open graphs/mubea_material_flow.svg for the full-resolution, zoomable version. Full node/connection listing: 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.

---

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.

Full-resolution: graphs/mubea_tro_flow.svg · full report incl. connections & rules: 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

:: 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.