set_can_read_first¶

Runs at once Any mode Takes control

Choose whether the robot reads CAN first in each control tick. On, the robot reads the drives' CAN replies at the start of each tick, computes that tick's commands from them and sends the commands at once: about 3.8 ms from a drive's measurement to the command computed from it, instead of about 7.8 ms in the older order, which reads after sending. Measured with the same rate of late replies and the same tracking. Homing always uses the older order. The change takes effect on the robot's next tick, in any mode, and lasts until the robot software restarts. The status field can_read_first shows the order in use; it reads False while homing.

Syntax¶

robot.set_can_read_first(enabled)

Arguments¶

Name	Type	Default	Description
`enabled`	`bool`	required	`True` reads first and sends early; `False` uses the older order.

Default values¶

From config/system.xml <can_read_first>, read each time the robot software starts: on (1).

Returns¶

Any

None: the robot sends no data back.

Examples¶

robot.set_can_read_first(False)
robot.set_can_read_first(True)

Further details¶

Note

When the robot cannot open the CAN socket it needs to read first, it keeps the older order and says why in its log; the call still returns normally. Check the status field.

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 — a raw client sent a value other than true / false or 1 / 0
[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 — the read-first socket did not open when the robot software started (RTI.log says why): the old tick order stays

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

CommandRejected: 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": "set_can_read_first", "args": [0]}