KRL¶

Handshakes with the running KRL program, $TECHPAR and $SEN_PINT exchange, and KRL file tooling.

Usage¶

wait_for_signal()/signal_complete() default to per-bit Digin/Digout groups, which the shipped configs don't declare (digital I/O there is exposed only via the DiL/DiO words). Add per-bit Digin.i*/Digout.o* groups to your RSI config's SEND/RECEIVE sections to use the defaults below, or use api.io.get_input() / api.io.set_output() (no group=) against the shipped configs instead.

# Wait for KRL to set a digital input (synchronization)
if api.krl.wait_for_signal(3, timeout=10.0):
    print("KRL ready")

# Signal KRL that Python is done
api.krl.signal_complete(2)       # Sets Digout.o2 = HIGH (per-bit group required)

# Pass data to KRL via Tech.T variables (slots 11-199)
api.krl.write_param("T22", 120.0)   # KRL reads $TECHPAR[2,2]
api.krl.write_param(13, -50.0)

# Read data from KRL via Tech.C variables
force = api.krl.read_param("C11")    # KRL writes $TECHPAR_C[1,1]
actual_x = api.krl.read_param(12)

# $SEN_PINT (Max context: SEN_PINT / MAP2SEN_PINT objects) - an integer
# both sides can read and write, a cleaner handshake than a digital bit
api.krl.write_sen_pint(7)            # KRL reads $SEN_PINT[1]
n = api.krl.read_sen_pint()          # KRL wrote $SEN_PINT[1]

# Parse KRL .src/.dat files to CSV
api.krl.parse_to_csv("robot_prog.src", "robot_prog.dat", "output.csv")

# Inject RSI commands into existing KRL program
api.krl.inject_rsi("robot_prog.src", "robot_prog_rsi.src")

Reference¶

KRLAPI ¶

KRLAPI(client: RSIClient)

KUKA Robot Language (KRL) program manipulation interface.

Provides utilities for parsing KRL programs, extracting coordinate data, and injecting RSI control commands into existing KRL workflows.

Initialize KRLAPI namespace.

Parameters:

Name	Type	Description	Default
`client`	`RSIClient`	RSIClient instance (currently unused, reserved for future features)	required

parse_to_csv `staticmethod` ¶

parse_to_csv(src_file: str, dat_file: str, output_file: str) -> str

Parse KRL source and data files, extract coordinates to CSV.

Reads .src (program logic) and .dat (position data) files, extracts point definitions and movement commands, and exports to CSV format.

Parameters:

Name	Type	Description	Default
`src_file`	`str`	Path to KRL .src program file	required
`dat_file`	`str`	Path to KRL .dat data file	required
`output_file`	`str`	Path for output CSV file	required

Returns:

Type	Description
`str`	Status message indicating success or failure

Raises:

Type	Description
`FileNotFoundError`	If source or data files don't exist
`Exception`	If parsing fails

Example

api.krl.parse_to_csv('robot_prog.src', 'robot_prog.dat', 'output.csv') 'KRL data successfully exported to output.csv'

Note

The parser extracts position data (E6POS, E6AXIS, FRAME) from the .dat file and matches them with movement commands (PTP, LIN, CIRC) from the .src file.

inject_rsi `staticmethod` ¶

inject_rsi(input_krl: str, output_krl: Optional[str] = None, rsi_config: str = 'RSIGatewayv1.rsi') -> str

Inject RSI control commands into a KRL program.

Automatically modifies a KRL .src file to include RSI initialization, sensor communication, and cleanup code. This allows adding real-time external control to existing robot programs.

Parameters:

Name	Type	Description	Default
`input_krl`	`str`	Path to input KRL .src file	required
`output_krl`	`Optional[str]`	Optional output path (defaults to overwriting input)	`None`
`rsi_config`	`str`	RSI configuration file name (default: 'RSIGatewayv1.rsi')	`'RSIGatewayv1.rsi'`

Returns:

Type	Description
`str`	Status message indicating success or failure

Raises:

Type	Description
`FileNotFoundError`	If input KRL file doesn't exist
`Exception`	If injection fails

Example

Modify in place¶

api.krl.inject_rsi('robot_prog.src') 'RSI successfully injected into robot_prog.src'

Create new file¶

api.krl.inject_rsi('robot_prog.src', 'robot_prog_rsi.src') 'RSI successfully injected into robot_prog_rsi.src'

Note

The injection adds: - RSI_CREATE() at program start - RSI_ON() before motion commands - RSI_MOVECORR() during movement - RSI_OFF() after motion This allows Python to send corrections during program execution.

wait_for_signal ¶

wait_for_signal(channel: int, timeout: float = 5.0, check_interval: float = 0.01, group: str = 'Digin') -> bool

Wait for KRL to set a specific I/O signal.

Blocks until the specified digital input becomes HIGH, or timeout occurs. Commonly used for synchronization where Python waits for KRL to signal completion of a robot operation before proceeding.

Parameters:

Name	Type	Description	Default
`channel`	`int`	Input channel number to monitor (1-based)	required
`timeout`	`float`	Maximum wait time in seconds (default: 5.0)	`5.0`
`check_interval`	`float`	Polling interval in seconds (default: 0.01 = 10ms)	`0.01`
`group`	`str`	I/O group name (default: 'Digin')	`'Digin'`

Returns:

Type	Description
`bool`	True if signal received, False if timeout occurred

Example

Wait for KRL to signal ready on input 3¶

if api.krl.wait_for_signal(3, timeout=10.0): ... print("KRL signaled ready!") ... # Proceed with Python-side processing ... else: ... print("Timeout waiting for KRL signal")

Handshake pattern: Python waits → KRL signals → Python continues¶

api.motion.update_cartesian(X=100) # Send correction api.krl.wait_for_signal(1) # Wait for KRL to acknowledge

KRL has processed the correction, safe to continue¶

Note

This is a blocking operation. The check_interval determines polling frequency - lower values provide faster response but higher CPU usage. For typical RSI applications, 10-50ms intervals are appropriate.

Warning

Ensure the KRL program actually sets the signal, otherwise this will block until timeout. Consider using try/except for timeout handling.

signal_complete ¶

signal_complete(channel: int, group: str = 'Digout') -> str

Signal to KRL that Python-side operation is complete.

Sets the specified digital output HIGH to notify the KRL program that Python has finished processing and KRL can proceed.

Parameters:

Name	Type	Description	Default
`channel`	`int`	Output channel number to signal on (1-based)	required
`group`	`str`	I/O group name (default: 'Digout')	`'Digout'`

Returns:

Type	Description
`str`	Status message indicating success

Raises:

Type	Description
`RSIVariableError`	If the output channel doesn't exist
`RSISafetyViolation`	If safety checks prevent the operation

Example

Signal KRL that data processing is complete¶

api.krl.signal_complete(2) 'Signaled complete on Digout.o2'

Typical coordination pattern:¶

1. KRL sends data via Tech variables¶

2. Python processes data¶

result = api.krl.read_param('C11') # Read from KRL processed = result * 2.0 # Process api.krl.write_param('T21', processed) # Write result api.krl.signal_complete(1) # Tell KRL we're done

Note

This sets the output and leaves it HIGH. If you need to reset the signal after KRL acknowledges, use api.io.pulse() instead or manually call api.io.set_output(channel, False) after KRL reads the signal.

write_param ¶

write_param(slot: Union[int, str], value: float) -> str

Write parameter to a Tech.T variable for KRL to read.

Tech.T variables are "Transfer" parameters written by Python and read by KRL programs — this is the Python-to-KRL command channel. Used for passing numerical data (commands, targets) from Python to the robot controller. (Tech.C is the KRL-to-Python state channel; see read_param().)

Parameters:

Name	Type	Description	Default
`slot`	`Union[int, str]`	Tech slot name, e.g. 'T11', 't15'. A bare number/int (e.g. 11) is treated as a T-slot for backwards compatibility, but an explicit 'T' prefix is recommended for clarity.	required
`value`	`float`	Numerical value to write	required

Returns:

Type	Description
`str`	Status message indicating success

Raises:

Type	Description
`ValueError`	If slot doesn't resolve to a valid `<letter><number>` form
`RSIVariableError`	If the Tech group or slot doesn't exist in receive_variables (the slot must be declared in the RSI config)
`RSISafetyViolation`	If safety checks prevent the operation

Example

Send a command to KRL¶

api.krl.write_param('T21', 1) # Tech.T21 = 1 (e.g. "Ready") 'Updated Tech.T21 to 1.0'

Send multiple parameters¶

api.krl.write_param('T22', 120.0) # X offset api.krl.write_param('T23', -50.0) # Y offset api.krl.write_param('T24', 800.0) # Z offset

KRL side reads with: target_x = $TECHPAR[2,2]¶

Note

The slot must be declared in both directions in the RSI config (DEF_Tech.T... under ) for this to succeed — see RSI_EthernetConfig_Full.xml. The KRL program must read from $TECHPAR[fg,idx] (advance-run technology parameters) to access these values - Tech.T22 is $TECHPAR[2,2].

KRL Example

DEF my_program()
  DECL REAL target_x, target_y, target_z
  ; Python writes to T12, T13, T14
  target_x = $TECHPAR[2,2]
  target_y = $TECHPAR[2,3]
  target_z = $TECHPAR[2,4]
  ; Use coordinates...
END

read_param ¶

read_param(slot: Union[int, str]) -> float

Read parameter from a Tech.C variable written by KRL.

Tech.C variables are "Control" parameters written by KRL programs and read by Python — this is the KRL-to-Python state channel. Used for passing numerical data (state, sensor echoes) from the robot controller to Python. (Tech.T is the Python-to-KRL command channel; see write_param().)

Parameters:

Name	Type	Description	Default
`slot`	`Union[int, str]`	Tech slot name, e.g. 'C11', 'c15'. A bare number/int (e.g. 11) is treated as a C-slot for backwards compatibility, but an explicit 'C' prefix is recommended for clarity.	required

Returns:

Type	Description
`float`	Numerical value from the Tech.C slot

Raises:

Type	Description
`ValueError`	If slot doesn't resolve to a valid `<letter><number>` form
`RSIVariableError`	If the Tech group or slot doesn't exist in send_variables (the slot must be declared in the RSI config)

Example

Read KRL state¶

state = api.krl.read_param('C11') # Read Tech.C11 print(f"KRL state: {state}") KRL state: 2.0

Read multiple parameters¶

actual_x = api.krl.read_param('C12') actual_y = api.krl.read_param('C13') actual_z = api.krl.read_param('C14')

KRL side writes with: $TECHPAR_C[1,2] = actual_pos.X¶

Note

Tech.C variables are updated every RSI cycle (~4ms) from the robot controller. Values reflect the KRL program's last write operation.

KRL Example

DEF my_program()
  DECL E6POS actual_pos
  actual_pos = $POS_ACT
  ; Write to Tech.C for Python to read
  $TECHPAR_C[1,2] = actual_pos.X
  $TECHPAR_C[1,3] = actual_pos.Y
  $TECHPAR_C[1,4] = actual_pos.Z
END

Warning

Ensure the KRL program has written to the Tech.C slot before reading, otherwise you'll receive the default value (typically 0.0).

read_sen_pint ¶

read_sen_pint(index: int = 1) -> int

Read a $SEN_PINT[index] integer written by the KRL program.

The integer counterpart of $SEN_PREA (the real-valued channel RSIPI already carries as SenP1-3). Needs a context wiring a SEN_PINT object: context("max") wires SEN_PINT1 ($SEN_PINT[1]) to the tag SenPInt1.

Parameters:

Name	Type	Description	Default
`index`	`int`	which SenPInt tag to read (default 1)	`1`

Returns:

Type	Description
`int`	The integer value the KRL program last wrote

Raises:

Type	Description
`RSIVariableError`	if the config declares no such tag

Example

api.krl.read_sen_pint() 7

KRL Example

$SEN_PINT[1] = 7

write_sen_pint ¶

write_sen_pint(value: int, index: int = 1) -> str

Write $SEN_PINT[index] for the KRL program to read.

Needs a context wiring a MAP2SEN_PINT object: context("max") wires MAP2SEN_PINT1 to the tag SenPIntW.

Parameters:

Name	Type	Description	Default
`value`	`int`	integer to write	required
`index`	`int`	which SenPIntW tag to write (default 1, tag `SenPIntW`)	`1`

Returns:

Type	Description
`str`	Status message

Raises:

Type	Description
`RSIVariableError`	if the config declares no such tag

Example

api.krl.write_sen_pint(3) 'SenPIntW set to 3'

KRL¶

Usage¶

Reference¶

KRLAPI ¶

parse_to_csv staticmethod ¶

inject_rsi staticmethod ¶

Modify in place¶

Create new file¶

wait_for_signal ¶

Wait for KRL to signal ready on input 3¶

Handshake pattern: Python waits → KRL signals → Python continues¶

KRL has processed the correction, safe to continue¶

signal_complete ¶

Signal KRL that data processing is complete¶

Typical coordination pattern:¶

1. KRL sends data via Tech variables¶

2. Python processes data¶

write_param ¶

Send a command to KRL¶

Send multiple parameters¶

KRL side reads with: target_x = $TECHPAR[2,2]¶

read_param ¶

Read KRL state¶

Read multiple parameters¶

KRL side writes with: $TECHPAR_C[1,2] = actual_pos.X¶

read_sen_pint ¶

write_sen_pint ¶

parse_to_csv `staticmethod` ¶

inject_rsi `staticmethod` ¶