latest changes
This commit is contained in:
Samer Ayadi committed
1 parent
8bd0739653
commit
d7edc55116
23 files changed
+4769
-44
No files matched your search
@@ -0,0 +1,193 @@
|
||||
# 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).
|
||||
|
||||
|
||||
|
||||
> 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.
|
||||
|
||||
|
||||
|
||||
> 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.
|
||||
Reference in new issue
Block a user