reload_zones¶

Runs at once Any mode Takes control

Re-read the safety zones from their files and apply them. The robot reads config/system.xml again (the <active_cell> name and the <haptic_walls> policy), then the cell file config/cells/<name>.xml and the gripper XML's tool spheres, and checks every zone. Only when all of it is valid does it apply them, at once and without a restart or re-homing: to the planner, to is_reachable(), to the safety monitor and to the freedrive walls. An empty <active_cell> removes every zone.

A cell file or tool sphere that is not valid is refused with ZONE_CONFIG, and the zones in force stay as they were. A <haptic_walls> value outside its range is not refused: it falls back to its default, with a warning in the robot's log. The gripper is the one the robot software started with; another <active_gripper> needs a restart.

Moves planned before the call are not checked again; the safety monitor checks every move against the new zones. A wall never pushes on its own: a tool sphere already inside a zone when it is reloaded feels nothing until it has been outside once.

Syntax¶

robot.reload_zones()

Arguments¶

None.

Default values¶

When the robot software starts it reads the same files, and a file that is not valid stops it. No zones as shipped: <active_cell> is empty.

Returns¶

dict

The zones now in force, as get_zones() returns them.

Examples¶

zones = robot.reload_zones()
zones["cell"]

Further details¶

Warning

Zones are not a safety-rated function, and they check only the tool centre point and the gripper's tool spheres: the arm's links can still enter a zone.

Usage restrictions 4 codes

This command runs at once; it is not queued. The robot accepts it in any mode and state, from the client that holds control or when no client does.

It answers with one of these codes when it does not carry the command out:

[6101] Control held by another client — another client holds control; the message names it
[7001] Cell file unreadable — config/system.xml or the gripper XML cannot be read or is not valid XML; <active_cell> is not a plain name (letters, digits, _, -) or names no file in config/cells/; the cell file is not valid XML, its root is not <cell>, it holds other elements than <zone>, or it is written for a newer robot software; a zone in it breaks a rule of the cell file (its name, shape, kind, reaction, checks, margin, enabled, haptic or freedrive value, its geometry, an unknown attribute or element) or shares its name with another; or a tool sphere in the gripper XML is not four numbers with a radius of at least 0. The message names the file, the zone and the reason
[6025] RTI not running or not answering — rTI did not answer within 1 s: it is not running or not responding. The command may still have taken effect
[6026] Refused by RTI — rTI could not use the zones the robot read. The message says why; the zones in force stay

In Python, a code above raises CommandRejected; its number is the code. The call raises:

CommandRejected: The robot refused it: the cell file or a tool sphere is not valid (ZONE_CONFIG), or another client holds control. Or RTI refused it or did not answer within 1 s (Errors:).
RobotTimeout: The robot did not answer within 5 s.
RobotConnectionError: The client is not connected.

If the connection drops while the call waits for the robot's answer, it raises CommandRejected with the code CONNECTION_LOST (DISCONNECTED after disconnect()); while it waits for the robot's status, RobotConnectionError.

Like every immediate command, it also answers BAD_ARGS when a raw client sends a value the robot cannot read at all, and INTERNAL when it fails inside the robot.

Protocol¶

A client that does not use robotclient sends this over the TCP command protocol (port 29000) for the example above:

{"id": "c1", "cmd": "reload_zones", "args": []}