# TO-TEST — lab verification checklist

Things that need a real KRC4 + robot to verify. Created 2026-07-10 while
working [issue #1](https://github.com/otherworld-dev/rsi-pi/issues/1).
Manual references are to `KUKA.RobotSensorInterface 3.3.pdf` (repo root).

Record for every session: KSS version, RSI version, installed options
(**Help > Info > Options** — photo the list), exact pendant error messages.

## A. Issue #1 — unblock kaosbeat (KR60-HA, KSS 8.3.38, RSI 3.3.5)

### A1. `RSIPI_Minimal.src` has never run on hardware

New file, written 2026-07-10 to mirror KUKA's `RSI_Ethernet.src` example
(manual §8.1.3, p. 59). Verify before telling kaosbeat it works:

- [ ] Loads in `KRC:\R1\Program` with no "variable not defined" errors
- [ ] Header `&ACCESS RVP` / `&REL 1` accepted (note: `RSIPI_Test.src` uses
      `&H NOBOUNDSCHECK` instead — if the pendant rejects the header, match
      whatever the working file uses)
- [ ] `MsgNotify()` calls display on the smartHMI
- [ ] `RSI_CREATE("RSIPI_Full.rsi", ...)` returns RSIOK
- [ ] `RSI_ON(#RELATIVE)` returns RSIOK
- [ ] `RSI_MOVECORR()`: robot holds position, then follows
      `api.motion.update_cartesian(X=5.0)` from RSIPI
- [ ] Kill the Python side mid-motion → robot stops safely with an RSI
      comm error after ~100 late packets (ETHERNET `Timeout=100`;
      manual §2.3.2, p. 15)
- [ ] Cancel program on pendant → clean `RSI_OFF`/`RSI_DELETE` path runs

### A2. The `$TECH` "variable not defined" mystery

kaosbeat's controller rejects every `$TECH.C[..]` / `$TECH.T[..]` line in
`RSIPI_Test.src` at load. Our controller ran it before. Find the difference:

- [ ] Does `RSIPI_Test.src` still load on the lab controller?
- [ ] Diff our installed options list against kaosbeat's (his: KSS 8.3.38,
      HMI 8.3.8450, kernel V8.3.450, RSI 3.3.5) — which package provides
      the `$TECH` structure?
- [ ] Check `KRC:\R1\TP\RSI\RSI.DAT`: `RSITECHIDX` value, and the
      machine-datum `$TECH_MAX` (number of function generators;
      manual §5.2, pp. 30–31)
- [ ] Confirm the correct KRL syntax for reading function-generator
      params on KSS 8.3 — is `$TECH.C[11]` right, or should it be a
      different variable/form? (Manual documents only the wire side:
      `DEF_Tech.C1` ⇒ attrs `C11…C110`, §7.4.5, pp. 52–53)
- [ ] Outcome → post answer on issue #1: exact package to install, or
      corrected syntax

### A3. Path + pendant claims in docs/controller-setup.md

- [ ] Confirm on a real KRC4 that SensorInterface is
      `C:\KRC\ROBOTER\Config\User\Common\SensorInterface` (no second
      `\KRC\`) and that files in `C:\KRC\ROBOTER\KRC\Config\...` (the path
      kaosbeat used!) make `RSI_CREATE` return RSIFILENOTFOUND
- [ ] Try to reproduce "address already in use" in the network config /
      RSI-Network tool; confirm the fix (edit/delete existing entry +
      reboot) — currently marked *(practical experience)* in the doc
- [ ] Note which config method the lab robot uses: KLI network config
      (§5.1.1) vs RSI-Network tool (§5.1.2)

## B. RSIPI regression on hardware

Last confirmed working before the big refactor
(`6b873d9 refactor: revamp core API, network handler, XML processing`).
The echo server is not proof — the real controller is stricter (IPOC
timing, XML format, 4 ms deadline in `#IPO_FAST`).

- [ ] `api.start()` + `wait_for_connection()` against the real robot with
      `RSI_EthernetConfig_Full.xml`
- [ ] Packet response consistently under 4 ms? Watch the `Delay` receive
      variable (late-packet counter) during a few minutes of streaming
- [ ] `update_cartesian()` small corrections — direction and magnitude
      sane (POSCORR1 RefCorrSys = Base, limits ±500 mm)
- [ ] Digital I/O: `DiO` word → MAP2DIGOUT1 (writes outputs 20+),
      `Digout.o1-o3` readback
- [ ] `$SEN_PREA` writes via MAP2SEN_PREA1-3 (needs a KRL program that
      reads them, e.g. `RSIPI_Test.src` phase 4)
- [ ] Full protocol run: `rsipi_test.py` + `RSIPI_Test.src` (blocked on A2)
- [ ] Tech round-trip: `api.krl.write_param(11, x)` on the PC ⇒ KRL sees
      generator-1 param 1; KRL writes ⇒ shows up in receive vars
- [ ] `TestServer.exe` cross-check works as described in
      docs/controller-setup.md §3

## C. Desk checks (no robot needed — do before lab if time)

- [ ] `krl_api.py` docstrings claim Tech slots "11-199", but the config
      structure only defines C11…C610 with param digits 1–10 (e.g. C110 is
      gen 1 param 10 — there is no C199). Validate `write_param`'s range
      check against what the wire format actually supports
- [ ] Does `rsi_echo_server` produce the manual-conformant `<Tech
      C11=... C110=...>` attribute style after the refactor?

## Done

(move checked items here with date + result)