# 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: ```python mode = rtde_r.getSafetyMode() ``` Example: ```python 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: ```python 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: ```python 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: ```python 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: ```python 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: ```python 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.