set_gripper_ctrl_mode¶

Runs at once Any mode Takes control

Switch the gripper between motor mode and firmware mode. In firmware mode the gripper's own firmware moves the jaws to the targets that open_gripper(), close_gripper(), move_gripper() and set_gripper() give it, and reports their position and whether something stopped them. In motor mode the robot gives the gripper's motor zero current: the jaws neither move nor hold, set_gripper() targets do not reach the gripper, and the queued gripper commands are refused with GRIPPER_MOTOR_MODE.

Switching to motor mode also drops the gripper's target, so the jaws stay still when firmware mode returns. Homing drives the gripper itself in either mode. latest_status() reports the mode in gripper.

Syntax¶

robot.set_gripper_ctrl_mode(mode)

Arguments¶

Name	Type	Default	Description
`mode`	`int`	required	`1` for motor mode or `2` for firmware mode.

Default values¶

From the robot's homing file, read each time the robot software starts: firmware mode when the first homing step that homes the gripper names firmware mode, as config/PAR6_homing.xml does, motor mode otherwise. It lasts until changed or until the robot software restarts.

Returns¶

Any

None. The robot answers before the gripper changes mode.

Examples¶

robot.set_gripper_ctrl_mode(2)

Further details¶

Warning

Motor mode takes the current off the gripper's motor: the jaws stop holding, and a part between them can slip out.

Usage restrictions 5 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
[6023] No gripper — the robot has no CAN gripper
[6003] Invalid arguments — mode is not 1 or 2
[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 read the mode. The message says why

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

CommandRejected: The robot refused it: mode is not 1 or 2, the robot has no CAN gripper, 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.
ValueError: mode cannot be read as a whole number, for example the text "firmware". Nothing is sent.

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": "set_gripper_ctrl_mode", "args": [2]}