RSI-PI/docs/controller-setup.md
Adam 8701074979 feat: controller setup guide + minimal RSI test program; relicense to Apache-2.0
- Add rsi_config/RSIPI_Minimal.src: RSI test program with no $TECH
  dependency, mirroring KUKA's RSI_Ethernet example (issue #1)
- Add docs/controller-setup.md: KRC4 install/network/troubleshooting
  guide cited against the KST RSI 3.3 V5 manual
- Relicense AGPL-3.0 -> Apache-2.0 (LICENSE, badges, classifiers)
- Add CITATION.cff, README How to Cite + Support sections, FUNDING.yml
- Fix author metadata typos; contact email is now contact@otherworld.dev
- Remove KUKA-proprietary TestServer.exe and stale egg-info from
  tracking; move internal planning docs out of the public tree
2026-07-11 01:12:44 +01:00

250 lines
13 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# KUKA Controller Setup Guide
Getting RSIPI talking to a real robot: installing the config files on a KRC4
controller, configuring the network, and troubleshooting the common failure
modes.
Primary source: the official **KUKA.RobotSensorInterface 3.3 manual**
(KST RSI 3.3 V5, issued 2016-10-17, for KSS 8.3/8.4), available from KUKA
via [my.kuka.com](https://my.kuka.com) or your KUKA support contact (it is
KUKA-copyrighted, so it is not redistributed with this repo). Section/page
references below (e.g. "manual §8.1.1, p. 56") point into that document. Claims not covered by the
manual are marked *(practical experience)* and sourced at the bottom.
## Prerequisites
- **KRC4 controller** with **KSS 8.3 or 8.4** and the
**KUKA.RobotSensorInterface 3.x** option package installed
(manual §4.1, p. 25). Check **Help > Info > Options** on the pendant.
RSI provides `RSI_CREATE`, `RSI_ON`, `RSI_MOVECORR`, `RSI_OFF`,
`RSI_DELETE` (manual §7.1, p. 39).
- RSI must **not** be installed together with KUKA.ConveyorTech or
KUKA.ServoGun TC (manual §4.1, p. 25).
- For corrections in `#IPO` sensor mode, **function generator 1 must be
free** (manual §4.1, p. 25; configurable via `RSITECHIDX` in
`KRC:\R1\TP\RSI\RSI.DAT`, manual §5.2, p. 30).
- PC side: Python 3.10+ with RSIPI installed (`pip install -e .`), on a
network interface reachable from the controller. KUKA specifies a
"real-time-capable operating system and real-time-capable network card
with 100 Mbit in full duplex mode" (manual §4.1, p. 25) — a normal
Windows/Linux PC works for testing but is not real-time capable, so
expect occasional late packets (see [Timing](#timing-requirements)).
## 1. Install the files
The files in `rsi_config/` go to **two different places**. This split is
specified in manual §8.1.1, p. 56:
> 2. Copy KRL programs into the directory `C:\KRC\ROBOTER\KRC\R1\Program`
> of the robot controller.
> 3. Copy the sample configurations and the XML file for the Ethernet
> connection to the directory
> `C:\KRC\ROBOTER\Config\User\Common\SensorInterface` of the robot
> controller.
| File | Destination on controller |
|---|---|
| `RSIPI_Full.rsi` | `C:\KRC\ROBOTER\Config\User\Common\SensorInterface\` |
| `RSIPI_Full.rsi.diagram` | `C:\KRC\ROBOTER\Config\User\Common\SensorInterface\` |
| `RSIPI_Full.rsi.xml` | `C:\KRC\ROBOTER\Config\User\Common\SensorInterface\` |
| `RSI_EthernetConfig_Full.xml` | `C:\KRC\ROBOTER\Config\User\Common\SensorInterface\` |
| `RSIPI_Minimal.src` | `C:\KRC\ROBOTER\KRC\R1\Program\` (= `KRC:\R1\Program` in the Navigator) |
| `RSIPI_Test.src` | `C:\KRC\ROBOTER\KRC\R1\Program\` (= `KRC:\R1\Program` in the Navigator) |
Watch the paths carefully — they are confusingly similar:
- KRL programs go under `...\ROBOTER\KRC\R1\Program` (**with** `\KRC\`).
- SensorInterface files go under `...\ROBOTER\Config\User\Common\...`
(**without** a second `\KRC\`). Putting them in
`C:\KRC\ROBOTER\KRC\Config\User\Common\SensorInterface` is a common
mistake; `RSI_CREATE` will not find them there.
- A `.src` file placed in the SensorInterface folder never appears as a
program, and a program that isn't loaded through `KRC:\R1\Program` throws
"variable not defined" on every RSI keyword.
Notes:
- The RSI, DIAGRAM and XML files "form a unit and must be transferred to
the robot controller together" (manual §8.1, p. 55).
- **Do not rename the files.** `RSIPI_Full.rsi` references
`RSI_EthernetConfig_Full.xml` by name in its ETHERNET object, and the
`.src` programs load `"RSIPI_Full.rsi"` by name in `RSI_CREATE`.
- Copy `.src` files as the **Expert** user group (log on via
Configuration > User group).
## 2. Configure the network
RSI needs "its own Ethernet sensor network which is independent of other
KLI subnetworks", physically connected via the KLI ports X66 or X67.1-3 on
the controller cabinet (manual §5.1, p. 29).
### Controller side
Two documented ways to set the robot's RSI IP address (manual §5.1.1 and
§5.1.2, pp. 2930):
**A. KLI network configuration on the pendant** (requires KSS 8.3.15+,
Expert group, T1/T2, no program selected):
1. Main menu > **Start-up > Network configuration** > **Advanced...**
2. **Add interface**; name it (e.g. "Ethernet sensor network").
3. Set **Address type: Mixed IP address** — this auto-creates the
real-time UDP receiving tasks RSI needs.
4. Enter the robot's IP and subnet mask, **Save**, and **reboot the
controller**.
**B. RSI-Network tool in Windows** (Expert group): minimize the HMI
(Start-up > Service > Minimize HMI), run **All Programs > RSI-Network**,
select the entry **New** under *RSI Ethernet* in the tree, press **Edit**,
enter the robot controller's IP, confirm, then **cold restart** the
controller.
IP address rules (manual §5.1.1, p. 29):
- PC and controller must be "located in the same network segment", i.e.
only the last of the 4 octets may differ.
- "The IP address range **192.168.0.x is blocked**" and the address "must
not be in the address range of another KLI subnet". The manual's example
uses robot `192.168.1.2` / mask `255.255.255.0` with the sensor (PC) at
`192.168.1.1`. This repo's default config uses `10.10.10.x`, which
safely avoids all KUKA-internal ranges *(practical experience — see
Sources)*.
### "Address already in use" when adding the interface
This error is not documented in the manual *(practical experience)*: it
appears when the address you enter collides with an interface entry that
already exists — a leftover RSI Ethernet entry, or another KLI subnet
containing the same address. Fix: in the interface tree, **edit or delete
the existing entry instead of adding a second one** (note the documented
RSI-Network procedure edits the existing "New" entry rather than creating
another), and make sure the subnet doesn't overlap any other configured
interface. Reboot (cold restart) afterwards — network changes only take
effect after a reboot (manual §5.1.1 step 8 / §5.1.2 step 5, p. 30).
### PC side
Give the PC a **static IP** on the RSI link and put that address in
`RSI_EthernetConfig_Full.xml` (both the copy on the controller and the copy
the Python side loads — they must match):
```xml
<CONFIG>
<IP_NUMBER>10.10.10.10</IP_NUMBER> <!-- your PC's IP -->
<PORT>64000</PORT>
<SENTYPE>ImFree</SENTYPE>
<ONLYSEND>FALSE</ONLYSEND>
</CONFIG>
```
Pick a free UDP port "not assigned a standard service" (manual §8.1.2.1,
p. 58). Allow that UDP port through the PC firewall, or disable the
firewall on the dedicated RSI interface *(practical experience)* — a
blocked firewall shows up as "Python receives nothing" while a packet
capture still sees traffic arriving.
### Timing requirements
The robot controller initiates the exchange and sends a packet every
sensor cycle; "a data packet received by the sensor system must be
answered within the sensor cycle rate. Packets that arrive too late are
rejected. When the maximum number of data packets for which a response has
been sent too late has been exceeded, the robot stops." (manual §2.3.2,
p. 15). The sensor cycle is **4 ms** in `#IPO_FAST` (default) or **12 ms**
in `#IPO` mode (manual §7.1.4, p. 41). The allowed number of late packets
is the `Timeout` parameter of the ETHERNET object — set to 100 in
`RSIPI_Full.rsi`.
## 3. First run: minimal test
`RSIPI_Minimal.src` mirrors KUKA's official `RSI_Ethernet.src` example
(manual §8.1.3, p. 59: `RSI_CREATE``RSI_ON(#RELATIVE)`
`RSI_MOVECORR()``RSI_OFF`) and uses no `$TECH` variables, no I/O and no
`$SEN_PREA` — so it isolates "does RSI work at all" from everything else.
1. On the pendant (T1 mode, low override): select `RSIPI_Minimal` and start
it. It does a BCO run to the current position, activates RSI, and reports
*"RSI active - start the Python sender now"*. The robot holds position,
waiting for corrections.
2. On the PC, from the repo root:
```python
from RSIPI import RSIAPI
api = RSIAPI("RSI_EthernetConfig_Full.xml")
api.start()
if not api.wait_for_connection(timeout=30.0):
raise SystemExit("No packets from robot - see troubleshooting table")
print("Connected:", api.motion.get_current_pose())
api.motion.update_cartesian(X=5.0) # small 5mm correction
input("Press Enter to stop...")
api.stop()
```
3. Stop by cancelling the program on the pendant. Stopping the Python side
instead also works: after `Timeout` late packets the robot stops and
reports an RSI communication error — expected and safe (manual §2.3.2,
p. 15). (A clean stop signal would require a STOP object in the signal
flow, manual §7.1.6, p. 42 — `RSIPI_Full.rsi` doesn't include one.)
Keep first corrections small. The signal flow limits Cartesian corrections
to ±500 mm (`POSCORR1` in `RSIPI_Full.rsi`), which is generous — tighten it
in RSI Visual and/or set software limits on the Python side via
`api.safety.set_limit()` before doing anything real.
Independent cross-check: KUKA ships a Windows test server (`TestServer.exe`)
with the RSI option package for exactly this purpose (manual §8.1.2, p. 56)
— find it on the controller under
`D:\KUKA_OPT\RSI\DOC\Examples\Ethernet\Server` (manual §8.1, p. 55). If the
robot exchanges packets with TestServer but not with RSIPI, the problem is
on the Python/firewall side, not the robot.
## 4. Full test
`RSIPI_Test.src` + `rsi_config/rsipi_test.py` exercise the whole feature
set: corrections, `$SEN_PREA` (via MAP2SEN_PREA objects, manual §11.2.10,
p. 81), digital I/O, and a handshake over the `Tech.C` / `Tech.T` channels.
Those channels are "technology parameters in the main run / advance run
(function generators 1 to 6)" (manual §7.4.57.4.6, pp. 5253): on the
wire, `DEF_Tech.C1` carries the ten parameters of function generator 1 as
attributes `C11…C110`.
On the KRL side the test program reads/writes these as `$TECH.C[11]` etc.
On at least one user's KSS 8.3.38 installation these `$TECH` references
fail to load with "variable not defined"
([issue #1](https://github.com/otherworld-dev/rsi-pi/issues/1)) — the
variables appear tied to a technology-package installation, and the exact
availability conditions haven't been pinned down yet. **If only the
`$TECH.…` lines error, run `RSIPI_Minimal.src` instead** — everything
except the Tech handshake works without them.
## 5. Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| "Variable not defined" on **every** line / `RSI_CREATE`, `RSI_ON`, `RSIOK` unknown | `.src` file not in `KRC:\R1\Program`, or RSI option not installed | Move the `.src` (see §1); check RSI appears under Help > Info > Options |
| "Variable not defined" only on `$TECH.…` lines | `$TECH` technology parameters not available on this installation | Use `RSIPI_Minimal.src` (see §4) |
| "Address already in use" when creating the RSI Ethernet entry | An interface entry with that address/subnet already exists | Edit or delete the existing entry instead of adding a new one; reboot (see §2) |
| `RSI_CREATE` returns `RSIFILENOTFOUND` / `RSIINVFILE` | Config files missing from `Config\User\Common\SensorInterface` (check for the extra-`\KRC\` path mistake), renamed, or `.rsi`/`.rsi.xml`/`.diagram` set incomplete | Re-copy all four config files together, keep original names (manual §7.1.2, p. 40 for return codes) |
| `RSI_ON` fails / RSI communication error immediately | IP in `RSI_EthernetConfig_Full.xml` doesn't match the PC, or subnet mismatch (only last octet may differ), or PC in `192.168.0.x` | Fix `<IP_NUMBER>`; follow the IP rules in §2 |
| Robot program runs but Python sees no packets | PC firewall blocking the UDP port, or RSIPI bound to the wrong interface | Allow the port / disable firewall on the RSI interface; verify with KUKA's `TestServer.exe` (see §3) |
| Robot stops mid-motion with RSI error after running fine | Response packets late: Python loop blocked, or non-dedicated network | Keep the correction loop free of blocking work; use a dedicated interface; watch the `Delay` variable (count of late packets, manual §7.4.5, p. 52) |
| Corrections apply but motion is jerky | Late/rejected packets | Same as above — dedicated network, faster loop |
Still stuck? Open an issue with your KSS version, RSI version (Help > Info >
Options), and the exact pendant error message.
## Sources
- **KUKA.RobotSensorInterface 3.3** manual, KST RSI 3.3 V5, KUKA Roboter
GmbH, 2016-10-17 — from KUKA ([my.kuka.com](https://my.kuka.com)).
All "manual §…" references above.
- [Michael Sobrepera, "KUKA Setup Guide"](https://michaelsobrepera.com/guides/kuka.html)
— practical KRC4 + RSI walkthrough (network interface creation, firewall,
file copying).
- Robot-Forum: [KRC4 RSI Ethernet](https://www.robot-forum.com/robotforum/thread/12240-krc4-rsi-ethernet/)
and [IP addresses in network configuration of KRC4](https://www.robot-forum.com/robotforum/thread/16990-ip-addresses-in-network-configuration-of-krc4/)
— reserved KRC4 subnets (`192.168.0.x` shared-memory driver) and RSI
network setup experience.