Skip to content

rti_set_command_timeout

Runs at once Any mode Takes control

Set how long the robot waits for the next real-time command. While control is claimed, a gap longer than this between two commands ends the stream: the arm brakes to rest within its limits, then the robot latches RTI_LINK_LOST, which disables it. Until then the robot carries on with the last command: a position stream along your last targets, a velocity or a torque command unchanged. It takes effect at once, also mid-stream.

In RTI mode it can only shorten the 40 ms: a stale velocity or torque must not drive on for longer. In SOFT_RTI, which takes position targets only, it can be widened up to the operator's ceiling, the robot XML <safety><max_soft_rti_timeout> (0.25 s on PAR6), or up to three of your intervals when that is longer, never above 1 s. Below 8 ms (two ticks) counts as 8 ms. rti_connect() sets it again: call this after it.

Syntax

robot.rti_set_command_timeout(seconds)

Arguments

Name Type Default Description
seconds float required The longest gap allowed between two commands, in seconds, above 0 and limited as described.

Default values

Set at every rti_connect(): 0.04 s in RTI mode; in SOFT_RTI three of your intervals (3 / rate_hz), at least 8 ms and at most 1 s. Before the first one it is config/system.xml <rti_defaults><command_timeout_s>, 0.04 s, read at start.

Returns

Nothing.

Examples

robot.rti_connect(rate_hz=20, wait=True)
robot.rti_set_command_timeout(0.2)
robot.rti_disconnect(wait=True)
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
  • [6003] Invalid arguments — seconds is not a finite number above 0, or the message did not carry exactly one value
  • [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 value. The message says why; the setting in force stays

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

  • CommandRejected: The robot refused it: seconds is not a number above 0, 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: seconds is not a number. Nothing is sent.
  • TypeError: seconds is not a number. 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.

See also

rti_connect rti_claim