set_completion_policy¶
Runs at once Any mode Takes control
Set when the robot counts a queued move as finished. The policy decides when each move is reported finished, which is when wait_idle() returns, and when the next move starts:
"commanded": once the robot has sent the move's last setpoint. The next move starts at once, while the arm may still be on its way."settled": the robot holds the move's target until every joint is within 0.01 rad (about 0.6 deg) of it, then reports the move finished and starts the next one. After 2 s it reports the move finished anyway."strict": as"settled", but after 2 s the move fails withSETTLE_TIMEOUT(wait_idle()raisesMotionFailed). The moves after it still run.
A move blended into the next one never waits. Case and spaces around the name do not matter.
Unlike the other defaults, a move cannot carry its own policy: this one applies at once to every move, also those already sent, from every client. It lasts until it is changed or the robot software restarts. The status shows it as exec_completion_policy.
Syntax¶
Arguments¶
| Name | Type | Default | Description |
|---|---|---|---|
policy |
str |
required | "commanded", "settled" or "strict". |
Default values¶
"settled", set each time the robot software starts.
Returns¶
Any
None: the robot sends no value back.
Examples¶
robot.set_completion_policy("strict")
robot.move_joints(90, -105, 165, 0, -30, 180)
robot.wait_idle()
Further details¶
Note
completion_policy given as a per-move setting is refused with
BAD_OPTIONS.
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
- [6003] Invalid arguments — no policy was given (only a raw client can send that)
- [6007] Unknown completion policy —
policyis not"commanded","settled"or"strict" - [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 policy. The message says why
In Python, a code above raises CommandRejected; its number is the code. The call raises:
CommandRejected: The robot refused it: the name is not a policy, 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: