scl_context: Staubereichs-Namen je Foerderer in Fliessrichtung

Staubereiche heissen DB_JamArea<NNNN>.stJam<NNNN>_<k> (Regel der
SPS-Programmierung, Dematic): NNNN = Foerderer, auf dem der Staubereich
liegt (Kreisel- bzw. Vario-Motor), k zaehlt auf diesem Foerderer in
Fliessrichtung. Foerderer: eigener Vario-Antrieb, sonst Separator auf einem
Kreisel (staubereich_kreisel_max_mm in cfg/parameter.ini [scl_context]),
sonst Kreisel-Host, sonst letzter Antriebs-TRO davor auf derselben Strecke.
k folgt der Nachfolgerkette auf dem Foerderer, nicht der REGION-Reihenfolge
(Breitensuche, Dematic Kreisel3 sonst TRO20 vor TRO23). Programm-DBs zaehlen
in der --strict-Gegenpruefung nicht als Geraete.

merge_hw_layout: von Hand gesetzte Antriebe (hw_overrides.ini) bekommen
keinen zusaetzlichen automatischen Widerspruch-Eintrag mehr.

hw_overrides.ini Dematic: VF_6 = MA0043 (TRO04/05) + MA0044 (TRO06/07),
VF_4 = MA0045 (TRO01/02, K0045 = 0008); Separatoren nach Klartext statt
kleinstem Abstand - TRO04 hatte BG0111 von VF_4.

Dematic: alle 25 Staubereiche benannt, 123 Slot-Rollen, 0 Widersprueche,
offene Stellen 615 -> 494.

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

doc/Python_Scripts.md

@@ -607,7 +607,26 @@ layout is `anlage.layout`; names come from `bindings[]` by TRO-ID + slot + role
 | `line<n>` `sensor` / `stopper` / `jamSensor` | PinStore storage lines |
 | `switch<n>` `valve` | `xOutSw<n>ExTo3` — the slot names the switch part from `switches` of the TRO-JSON (Ausschleuselement or ILS Weiche; `switch<i>` belongs to `separator<i>` in 2Sep types) |
 | `drive` `motor` / `motorProtection` / `sen*` | Vario motor, `xInMotorProtection`, `stSenCarrInPos` … (motor/protection fall back to the conveyor of the TRO's host) |
-| `conveyors[]` on the TRO's host | `xInCarouselRun` = `#fbCarousel<NNNN>.xOutConveyorFullSpeed` (Kreisel only); jam DB `"DB_JamArea<NNNN>".stJam<NNNN>_____` — still `TODO`, the running number `<k>` is not fixed yet |
+| `conveyors[]` on the TRO's host | `xInCarouselRun` = `#fbCarousel<NNNN>.xOutConveyorFullSpeed` (Kreisel only) |
+| `conveyors[]` + drive bindings | jam DB `"DB_JamArea<NNNN>".stJam<NNNN>_<k>` (`scl_context.jam_names`, see below) |
+
+**Jam-area names** (rule of the PLC programmers, Dematic 2026-10-22).
+`<NNNN>` is the conveyor the jam area sits on — the number of its Kreisel or
+Vario motor — and `<k>` counts up along the material flow on that conveyor
+(Vario MA0051 → `stJam0051_1`, `stJam0051_2`). The conveyor of a jam area, in
+this order: (1) the TRO's own drive (Vario); (2) its separator lies on a
+Kreisel (within `staubereich_kreisel_max_mm` of the Kreisel's bounding box,
+`cfg/parameter.ini [scl_context]`) — catches TROs whose host is the outgoing
+line; (3) the host is a Kreisel; (4) the host is a line carrying drive TROs →
+the drive of the last drive TRO before it on that line (a 1Sep behind a Vario
+belongs to that Vario's conveyor; VF_6 carries two Varios). `<k>` = 1 is the
+area the flow reaches first on that conveyor (on a Kreisel: where material
+comes on); from there the count follows the successor chain on the same
+conveyor, not the REGION order — that is a breadth-first search over the whole
+plant and reaches a Kreisel TRO through another conveyor first. A jam area
+without a conveyor stays a placeholder and does not count. Dematic: all 25 jam
+areas named. Jam DB names are program DBs, not devices — the `--strict`
+cross-check skips them.
 
 Not filled yet: jam sensors at the exits (`stInSenJam<n>`, the `Ausschleus.stau`
 bindings have no slot), scanners, separator/switch/MainTro numbers. Switch
@@ -860,7 +879,8 @@ Steps:
    on the same layout conveyor (Dematic VF_6: two Vario TROs), the drive is a
    `widerspruch` with the conveyor's motor as a suggestion — each TRO has its
    own motor; set it in `hw_overrides.ini`. `scl_skeleton` then keeps
-   `MA____` instead of falling back to the conveyor's motor.
+   `MA____` instead of falling back to the conveyor's motor. A drive set by
+   hand in `hw_overrides.ini` is left alone by this step.
 5. **Corrections** from `hw_overrides.ini` (last):
    `[<csv>.bindings] TRO01.separator1.sensor = BG0532` (or `= -` to clear) and
    `[<csv>.conveyors] K0102 = 0010`.
@@ -886,12 +906,12 @@ conveyors (Aufgabestation #100/#101, Vario #106–#109) are outside the CSV or
 have a single vote and stay open.
 
 Result on Dematic (`dematic_merge_tro.json` + `dematic_hw.json`, rules
-`e_planning_dematic.ini`): 113 slot roles assigned (all 27 storage lines with
-sensor and stopper, 23 of 25 separators, 5 of 6 switch valves, 6 Vario drives),
-39 open (Vario sensors, scanners, VF_4/VF_6 where mechanical parts are still
-missing), 4 contradictions (the two Vario TROs on VF_6). Then
-`scl_skeleton --templates --strict`: 115 names inserted, all known in TIA,
-open gaps 730 → 615.
+`e_planning_dematic.ini`, corrections for VF_4/VF_6 in `hw_overrides.ini`): 123
+slot roles assigned (all 27 storage lines with sensor and stopper, all 25
+separators, 5 of 6 switch valves, all 7 Vario drives), 33 open (Vario sensors,
+scanners, one switch valve), 0 contradictions. Then
+`scl_skeleton --templates --strict`: 200 names inserted (75 of them jam-area
+names), all devices known in TIA, open gaps 730 → 494.
 
 **Stage 4:** `scl_skeleton --json <csv>_anlage.json` reads the plant JSON
 directly (§5b). `--eplan` still works for a TRO-JSON and is phased out together