scl_templates: Aufruf-Template FB_ILS_MTRO_2Sep2Swi (ohne Referenz-Aufrufstelle)

Mubea wird damit vollstaendig aus Templates erzeugt. Der FB existiert noch
nicht in der ILSLib; die Schnittstelle ist aus 2Sep1Swi (Separatoren) und
1Sep2Swi (Weichen) angenommen und steht im Template-Kopf - mit den
SPS-Kollegen abzustimmen.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

doc/Python_Scripts.md

@@ -626,8 +626,10 @@ with a real reference call site (`1Sep`, `1Sep1Swi`, `1Sep2Swi`, `1Sep_SSCC`,
 `Vario`, `Vario_workStation`, `PinStore_Auto`); each follows its call site in
 `doc/TRO_Katalog/scl_templates/` line for line, and every value that is still
 open carries `TODO(E-Planung)`. The line decisions are proposals to be confirmed
-by a PLC engineer (`doc/SCL_Templates.md` §6). `2Sep1Swi`, `EmptyCarrBuffer`,
-`LoadingBoom` and `2Sep2Swi` have no call site yet and stay generic. `--strict` stops (exit `1`, no SCL) if any FB type has no
+by a PLC engineer (`doc/SCL_Templates.md` §6). `2Sep1Swi`, `EmptyCarrBuffer` and
+`LoadingBoom` have no call site yet and stay generic. `2Sep2Swi` has a template without
+a call site (FB not yet in the ILSLib, interface assumed from `2Sep1Swi` + `1Sep2Swi`).
+`--strict` stops (exit `1`, no SCL) if any FB type has no
 template. Without `--templates` the output is unchanged.
 
 **Names from the plant JSON (stage 4, `--json <csv>_anlage.json`).** The
@@ -975,8 +977,11 @@ verified against `data/*.scl` where the source is vendored locally, and against
 > Kreisel2/Kreisel1 touch as a single control object with 2 separators,
 > 2 scanners and 2 switches. **`FB_ILS_MTRO_2Sep2Swi` does not exist** in this
 > repository or in `doc/TRO_Katalog/scl_templates/`, and has to be created in
-> the ILSLib — otherwise a future SCL generator will emit a call to a missing
-> block. The closest verified type is `2Sep1Swi` (2 separators, 2 scanners,
+> the ILSLib — otherwise the generated FB_Main calls a missing block. Since
+> 2026-10-28 there is a call-site template `lib/scl_templates/FB_ILS_MTRO_2Sep2Swi.scl.j2`
+> whose header lists the assumed interface (separators as in `2Sep1Swi`, switches
+> as in `1Sep2Swi`) - the FB has to be created to match it, or the template
+> adjusted. The closest verified type is `2Sep1Swi` (2 separators, 2 scanners,
 > **1** switch), which matches the hardware actually present in that export.
 > `3Sep2Swi` (3 separators, 3 scanners, 2 switches) was added on 2026-10-14
 > for the test plant `data/export.csv`, where one Kreisel pulley touches two

doc/SCL_Templates.md

@@ -66,10 +66,12 @@ Coverage per catalog type (`lib/tro_catalog.py`):
 | `2Sep1Swi` | `FB_ILS_MTRO_2Sep1Swi` | **no** | yes | from interface only — needs a real call site |
 | `EmptyCarrBuffer` | `FB_EmptyCarrBuffer` | **no** | yes | from interface only — needs a real call site |
 | `LoadingBoom` | `FB_LoadingBoom_INBOUND` | **no** | yes | from interface only — needs a real call site |
-| `2Sep2Swi` | `FB_ILS_MTRO_2Sep2Swi` | **no** | **no** | no — FB does not exist yet (Mubea needs it) |
+| `2Sep2Swi` | `FB_ILS_MTRO_2Sep2Swi` | **no** | **no** | ✅ done WITHOUT reference (2026-10-28) — FB does not exist yet (Mubea needs it); interface assumed from `2Sep1Swi` (separators) + `1Sep2Swi` (switches), see template header |
 
 So 7 types can be done with a test against real code. 3 can only be checked against the
-interface until someone supplies a real call site. `2Sep2Swi` stays on the fallback (§9).
+interface until someone supplies a real call site. `2Sep2Swi` has a template that is only
+covered by rendering the real plants and the mubea golden file - the FB has to be created
+in the ILSLib to match its assumed interface (or the template adjusted).
 
 ---
 
@@ -410,14 +412,15 @@ as `carousel_run` from connection kinds).
 | Situation | Behaviour | Exit |
 |---|---|---|
 | Template exists for the TRO's `fbType` | render template | 0 |
-| No template (e.g. `2Sep2Swi`) | render with the current `emit_*` code; header lines `// Aus Template : …` / `// Generisch : … (kein Template - von Hand pruefen)` and an entry in the console summary | 0 |
+| No template (e.g. `2Sep1Swi`) | render with the current `emit_*` code; header lines `// Aus Template : …` / `// Generisch : … (kein Template - von Hand pruefen)` and an entry in the console summary | 0 |
 | No template **and** `--strict` | stop, write nothing | 1 |
 | Template uses an undefined variable / syntax error | stop, write nothing, show template file and line | 1 |
 | Naming rule with unknown placeholder | stop, write nothing | 1 |
 | Invalid TRO-JSON | unchanged from today | 1 |
 
 With `--templates` the console summary gets a `Templates` line (implemented); the
-`Namensregeln` line follows with step 4. Real output for mubea today:
+`Namensregeln` line follows with step 4. Real output for mubea before the `2Sep2Swi`
+template (since 2026-10-28 mubea is fully rendered from templates):
 
 ```
 Templates        = 4 von 5 Typen (generisch: FB_ILS_MTRO_2Sep2Swi)
@@ -452,9 +455,9 @@ Each step ends with all tests green and is usable on its own.
 | 2 ✅ | `scl_context.py`: build the render context from `TroDocument`; `emit_*` read from it — `tests/test_scl_context.py` | golden files byte-identical (also checked on dematic and showroom, with and without `--start`) |
 | 3 ✅ | Pilot `FB_ILS_MTRO_1Sep1Swi.scl.j2` + `_macros`; switches `--templates`, `--strict`; class-C table (§6) filled with proposals — **still to be confirmed by a PLC engineer**; round-trip test | round trip against TRO107 passes; only the 1Sep1Swi REGIONs (+ header) differ from the generic golden files |
 | 4 | `scl_naming.py` + `cfg/scl_naming.ini`; switch `--naming` | naming tests pass; Mubea renders with names instead of TODOs where a rule exists |
-| 5 ✅ | Remaining call-site templates (`1Sep`, `Vario`, `1Sep2Swi`, `1Sep_SSCC`, `Vario_workStation`, `PinStore_Auto`), each with round trip against its reference (`PinStore_Auto`: the parts the reference abbreviates are left out of the comparison); decisions in §6 — **still to be confirmed by a PLC engineer**. Interface check (§8.2) for `Vario_workStation` still open | every round trip passes; HundM05 fully from templates, mubea except `2Sep2Swi` |
+| 5 ✅ | Remaining call-site templates (`1Sep`, `Vario`, `1Sep2Swi`, `1Sep_SSCC`, `Vario_workStation`, `PinStore_Auto`), each with round trip against its reference (`PinStore_Auto`: the parts the reference abbreviates are left out of the comparison); decisions in §6 — **still to be confirmed by a PLC engineer**. Interface check (§8.2) for `Vario_workStation` still open | every round trip passes; HundM05 fully from templates, mubea too since the `2Sep2Swi` template (2026-10-28, no reference) |
 | 6 | Templates on by default; new `--no-templates` keeps the old path for one release | golden files updated and reviewed; one import into TIA Portal (as for Mubea) |
-| 7 | Remove `emit_*` once every type in use has a template (`2Sep2Swi` needs a call site first) | fallback only for types without FB |
+| 7 | Remove `emit_*` once every type in use has a template (`2Sep2Swi` has one, but without call site - confirm it once the FB exists) | fallback only for types without FB |
 
 Docs touched along the way: `doc/Python_Scripts.md` §5b, `doc/Commandlines.md` §2.5,
 `CLAUDE.md` (roadmap), this file.
@@ -511,8 +514,10 @@ jam-area DBs) until an E-Planung export exists, and the `pruefen` timings.
 4. `xInRelease`: `TRUE` as in the reference, or the `"DB_TRO_TEST"` test release used today?
 5. Real call sites for `2Sep1Swi`, `EmptyCarrBuffer`, `LoadingBoom` — available from
    another plant?
-6. `FB_ILS_MTRO_2Sep2Swi` (Mubea): will it be created in the ILSLib, or should the two
-   transfer points be modelled with existing types?
+6. `FB_ILS_MTRO_2Sep2Swi` (Mubea): to be created in the ILSLib (decided 2026-10-28,
+   the two transfer points stay one TRO). Its call site is drafted in
+   `lib/scl_templates/FB_ILS_MTRO_2Sep2Swi.scl.j2`; open: the assumed interface
+   (`bSep<n>Type`, `stInOutCognexInterface1/2`, priority manager, `xNewSwitch`).
 7. `nTo1Destinations`: TRO107 has 2 exits but the value 3 ("Info noetig fuer HMI"). Does
    it count the destinations behind the switch rather than its exits? If so, which
    destinations — the per-exit target lists in the skeleton could supply them.