Contexts and deployment¶

The RSI contexts that ship with RSIPI, how they are resolved by name, and the two command-line modules that move a context to a controller or generate the Ethernet config from one. Background and the table of contexts: Configuration.

Reference¶

context ¶

Locate the RSI context bundles that ship with RSIPI.

A "context" is one unit of four files that must always travel together:

RSIPI_<Name>.rsi          RSIVisual's signal-flow file
RSIPI_<Name>.rsi.xml      the file the controller actually reads
RSIPI_<Name>.rsi.diagram  RSIVisual's canvas layout (cosmetic)
RSI_EthernetConfig_<Name>.xml   the telegram structure, named by the .rsi

BOTH ENDS MUST LOAD THE SAME PAIR. Passing context("joints") on the PC only works if the controller has that context's files in C:\KRC\ROBOTER\Config\User\Common\SensorInterface\. A config that disagrees with the controller's means the two ends describe different telegrams, which is not a clean failure - see controller/README.md.

>>> from RSIPI import RSIAPI, context
>>> api = RSIAPI(context("joints"))

There is deliberately no "everything wired up" context. The maximal one (full) is the least portable: its AXISCORREXT and external-axis monitor channels cannot bind on a robot without external axes, and the ETHERNET object reports RSIBad at RSI_ON. joints is the most capable context that works on any 6-axis robot, which is why it is the default.

available_contexts ¶

available_contexts() -> List[str]

Names accepted by :func:context, in rough order of capability.

describe_contexts ¶

describe_contexts() -> str

Human-readable listing of the shipped contexts.

context ¶

context(name: str = DEFAULT_CONTEXT) -> str

Path to a shipped context's Ethernet config, for passing to RSIAPI.

Parameters:

Name	Type	Description	Default
`name`	`str`	one of :func:`available_contexts` (default `"joints"`).	`DEFAULT_CONTEXT`

Returns:

Type	Description
`str`	Absolute path to `RSI_EthernetConfig_<Name>.xml`.

Raises:

Type	Description
`RSIConfigError`	if the name is unknown, or the packaged file is missing (an installation that dropped its data files).

Example

from RSIPI import RSIAPI, context api = RSIAPI(context()) # joints api = RSIAPI(context("basic"))

context_files ¶

context_files(name: str = DEFAULT_CONTEXT) -> List[Path]

The four files of a context - copy ALL of them to the controller.

A .rsi copied without its matching config produces RSI_CREATE: Invalid index - signal output on the controller.

deploy ¶

Copy the files a controller needs out of the installed package.

The RSI contexts ship inside RSIPI so that pip install provides a config to run against, which means they live somewhere under site-packages. Nobody should have to go digging in there to put four files on a robot.

python -m RSIPI.deploy --context joints --out C:\deploy

Then copy the contents of that folder to C:\KRC\ROBOTER\Config\User\Common\SensorInterface\ on the controller, as the Expert user group.

All four files of a context are copied together, always. A .rsi that reaches the controller without its matching config produces RSI_CREATE: Invalid index - signal output.

deploy ¶

deploy(name: str = DEFAULT_CONTEXT, out_dir: str = 'rsi_deploy', overwrite: bool = False) -> list

Copy one context's four files into out_dir.

Parameters:

Name	Type	Description	Default
`name`	`str`	context name (see :func:`RSIPI.available_contexts`)	`DEFAULT_CONTEXT`
`out_dir`	`str`	destination directory, created if needed	`'rsi_deploy'`
`overwrite`	`bool`	replace files that are already there	`False`

Returns:

Type	Description
`list`	The list of destination paths written.

Raises:

Type	Description
`RSIConfigError`	unknown context name
`FileExistsError`	a destination file exists and overwrite is False

config_builder ¶

Generate a matching RSI_EthernetConfig XML from an RSI context.

Writing the Ethernet config by hand after building a context in RSIVisual is fiddly and easy to get wrong, and getting it wrong is what produces

RSI_CREATE: Invalid index - signal output

on the controller - the context references an ETHERNET channel the config never declares. None of it needs to be typed out, though: the context already records which object feeds every ETHERNET input and which object consumes every ETHERNET output. This module reads that and writes the config.

python -m RSIPI.config_builder MyContext.rsi.xml --ip 10.10.10.10 --port 64000

The generated config is correct by construction, and examples/validate_context.py will confirm it.

Tag names follow the conventions RSIPI's API expects (RKorr, AKorr, DiO, SenP1-3 and so on), because those are what motion.update_cartesian(), io.set_output() and the rest look for. Rename them and the telegram still works, but the named API methods stop finding their variables.

build_config ¶

build_config(rsi_xml: str, ip: str, port: int, sentype: str = 'ImFree', onlysend: bool = False, internals: Optional[List[str]] = None) -> str

Build the Ethernet config XML text for a context.

Parameters:

Name	Type	Description	Default
`rsi_xml`	`str`	path to the context's `.rsi.xml`	required
`ip`	`str`	sensor (PC) IP the controller transmits to	required
`port`	`int`	UDP port	required
`sentype`	`str`	the name in `<Sen Type="">`	`'ImFree'`
`onlysend`	`bool`	True for one-way data logging (no replies expected)	`False`
`internals`	`Optional[List[str]]`	extra INTERNAL SEND tags, e.g. `["DEF_MACur"]`	`None`

Returns:

Type	Description
`str`	The config file's XML as text.

Raises:

Type	Description
`RSIConfigError`	if the context has no ETHERNET object, or wires a channel this builder has no naming convention for.