Skip to content

enter_flashing_mode

Runs at once IDLE or ACTIVE_ERROR mode Takes control

Hand the CAN bus to a firmware flasher; the motors let go. The robot stops sending on the CAN bus, so a separate flasher program can use it; everything else keeps running: the E-stop, the I/O, the status. About 0.1 s after the robot falls silent, each drive's watchdog lets go of its motor: the joints brake and sink slowly, the gripper coasts. So the arm must be parked or supported, which nothing on the robot can check: the call needs your claim, and the robot records which one you made.

It works while disabled, not homed or with an error latched: that is how a drive left in its bootloader by a failed flash is recovered. End it with exit_flashing_mode().

Syntax

robot.enter_flashing_mode(parked_confirmed=False, force=False, wait=None)

Arguments

Name Type Default Description
parked_confirmed bool False You parked the arm, at the robot's park pose, and confirm it.
force bool False The arm is not parked but supported by other means, for example because a drive cannot move it.
wait bool | None None Wait until the robot reports flashing mode, up to 10 s. None follows the client's sync setting.

Returns

Nothing.

Examples

robot.move_joints(0, -90, 180, 0, 0, 180)  # PAR6's park pose
robot.wait_idle()
robot.enter_idle_mode(wait=True)
robot.enter_flashing_mode(parked_confirmed=True, wait=True)

Further details

Note

stop() and disable() from any client end flashing mode and resume the robot's CAN traffic, which can make a flash in progress fail.

Further details

Warning

The motors stop holding the arm. Park or support it first.

Usage restrictions 4 codes

This command runs at once; it is not queued. The robot accepts it only when it is in IDLE or ACTIVE_ERROR mode, 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:

  • [6010] Command not allowed now — the message names the mode or state it needs
  • [6101] Control held by another client — another client holds control; the message names it
  • [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
  • [6014] Mode change refused — rTI refused FLASHING: nobody claimed the arm can go limp safely, or the mode it is in does not allow it. The message says why

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

  • CommandRejected: The robot refused it: it is not in IDLE mode or the error state, 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, or, with wait, did not report flashing mode within 10 s.
  • RobotConnectionError: The client is not connected.
  • ValueError: Neither parked_confirmed nor force is true. 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": "enter_flashing_mode", "args": [false]}

See also

exit_flashing_mode safety_stop