Chapter 16: Safety, Protective Stops, and Error Recovery
About This Chapter
Because UR robots are collaborative robots, they incorporate numerous safety functions.
Even in situations that would be treated as errors on conventional industrial robots, UR robots often stop as a result of their safety functions operating correctly.
This chapter explains:
Robot Mode
Runtime State
Safety Mode
Protective Stop
Emergency Stop
Fault
Recovery methods using Python
16.1 UR States
The controller maintains several distinct states:
Robot Mode
Runtime State
Safety Mode
These are separate pieces of information. The current condition cannot be determined by examining only one of them.
16.2 Robot Mode
Robot Mode represents the state of the robot itself.
Examples:
NO_CONTROLLER
DISCONNECTED
BOOTING
POWER_OFF
POWER_ON
IDLE
BACKDRIVE
RUNNING
Before sending a move command, it is safer to verify that the mode is:
RUNNING
16.3 Runtime State
Runtime State indicates the program execution state.
Examples:
STOPPED
PLAYING
PAUSED
It is entirely possible for Robot Mode to be RUNNING while the program is STOPPED.
16.4 Safety Mode
Safety Mode represents the state of the safety system.
Examples:
NORMAL
REDUCED
PROTECTIVE_STOP
SAFEGUARD_STOP
SYSTEM_EMERGENCY_STOP
ROBOT_EMERGENCY_STOP
FAULT
Ideally, Safety Mode should be NORMAL before executing a move.
16.5 Protective Stop
A Protective Stop is one of the most frequently encountered types of stop.
Possible causes include:
Collision
Excessive speed
Overload
Abnormal posture
Safety monitoring
A Protective Stop is the result of a safety function operating correctly. It is not a malfunction.
16.6 Emergency Stop
An Emergency Stop is initiated by an emergency-stop button.
It has higher priority than a Protective Stop.
An Emergency Stop cannot be released through the Dashboard while the emergency-stop condition remains active. A person must release the emergency stop.
16.7 Safeguard Stop
A Safeguard Stop is triggered by external safety inputs, such as:
Safety fences
Light curtains
The robot cannot move until the safety device returns to its normal state.
16.8 Fault
A Fault indicates an internal controller abnormality or a serious error.
Recovery is more difficult than for a Protective Stop. Restarting the controller may be necessary.
16.9 Detecting Errors
In Python, the state can be checked using methods such as:
mode = rtde_r.getSafetyMode()
Example:
if mode != NORMAL:
print("Safety Error")
Periodic monitoring in a state-monitoring thread is recommended.
16.10 Recovery Through the Dashboard
Representative commands are:
close safety popup
unlock protective stop
If necessary, also execute:
power on
brake release
16.11 Recommended Recovery Sequence
Move fails
↓
Check Safety Mode
↓
Close popup
↓
Release Protective Stop
↓
Check Robot Mode
↓
Power ON
↓
Brake Release
↓
Resume movement
Perform recovery in sequence, checking the state at each step.
16.12 RuntimeError
The ur_rtde library may raise a RuntimeError when a communication error or safety stop occurs.
Example:
try:
rtde_c.moveJ(q)
except RuntimeError as e:
print(e)
If such exceptions are not caught, the entire application may terminate.
16.13 Return Values of Move Commands
Move commands may return:
True
False
However, the return value alone is not sufficient. Check both exceptions and Safety Mode.
16.14 wait_move()
After a move finishes, using:
wait_move()
to check the following can improve safety:
Current position
↓
Difference from target
↓
Robot Mode
↓
Safety Mode
16.15 reset_error()
It is useful for a high-level API to provide:
reset_error()
Internally, it executes:
close safety popup
↓
unlock protective stop
Robot Mode should also be checked as necessary.
16.16 turn_on_motor()
Turning the motors on consists of two steps:
power on
↓
brake release
Providing these operations together as:
turn_on_motor()
allows users to work without having to manage the internal sequence themselves.
16.17 Automatic Recovery
Fully automatic recovery is not recommended.
For example:
Collision
↓
Protective Stop
↓
Immediate recovery
↓
Another collision
It is important to identify the cause before resuming operation.
16.18 State-Monitoring Thread
A typical sequence is:
while True
↓
Read Robot Mode
↓
Read Runtime State
↓
Read Safety Mode
↓
Notify if an abnormal condition is detected
Monitoring is often performed at approximately 10–50 Hz.
16.19 Design in ur_ctrl.py
A high-level API is easier to use when it provides methods such as:
get_robot_mode()
get_runtime_state()
get_safety_mode()
is_protective_stopped()
reset_error()
turn_on_motor()
As with the Move API, users no longer need to operate the Dashboard directly.
16.20 Recommended Workflow for Practical Operation
Connect
↓
Power ON
↓
Brake Release
↓
Move
↓
Confirm move completion
↓
Check safety state
↓
If an abnormal condition occurs:
reset_error()
↓
If necessary:
turn_on_motor()
↓
Resume movement
Using this as a basic workflow makes it reusable across many automated operation systems.
Summary
UR safety conditions should be evaluated by combining three kinds of information:
Robot Mode
Runtime State
Safety Mode
A Protective Stop is not a malfunction; it is a stop initiated by a safety function.
By contrast, Emergency Stops and Faults require different recovery procedures.
A high-level library should provide separate APIs for:
Retrieving states
Clearing errors
Turning motors on
This design avoids requiring users to know the details of Dashboard operations.
The next chapter covers practical Python example programs, including connection, teaching, pick-and-place, state monitoring, and error recovery.