Orders & Worldwide
Orders & Worldwide
When a Universal Robots system enters an Emergency Stop state, the controller is not reacting to a software crash or motion error.
The safety system has detected that the emergency-stop circuit is either:
As a result, the controller immediately removes motion permission and locks the robot into a safety state.
Typical behavior includes:
This is a hardware-enforced safety condition — not a normal runtime interruption.
UR safety architecture uses redundant dual-channel monitoring.
The controller continuously compares:
Engineering representation:
Δt = tA − tB
If the timing deviation exceeds the allowed threshold, the controller interprets the condition as unsafe and triggers a safety stop.
This is why a system can still generate E-Stop faults even when both safety LEDs appear active externally.
The controller is not only checking voltage presence.
It is validating synchronization consistency between both channels continuously during operation.
UR Emergency Stop faults usually appear in several common ways:
In intermittent cases, the failure may appear only during:
This often causes the problem to appear random even though the underlying trigger is repeatable.
The simplest cause is also the most common.
Always verify:
A partially engaged button or unstable contact is enough to keep the safety loop open.
In production environments, vibration and mechanical wear can also prevent contacts from fully resetting even when the button appears released.
UR systems may receive Emergency Stop signals from multiple sources simultaneously.
Typical configurations include:
One common troubleshooting mistake is resetting only the local pendant button while a remote safety input remains active.
In this situation:
because the external safety chain is still open elsewhere.
Always verify the entire safety loop, not only the pendant.
One of the most common UR safety faults is the safety synchronization conflict category, including:
These errors usually indicate the controller detected inconsistent timing between redundant safety channels.
Common real-world causes include:
A typical field pattern is:
These cases are frequently caused by mechanical contact instability rather than controller failure.
After robot relocation, maintenance, or controller replacement, cabinet jumper issues become extremely common.
One difficult field condition is the so-called “ghost fault” pattern:
A common cause is poor jumper contact where:
These failures are especially difficult because static continuity tests may still appear normal.
In many production environments, intermittent E-Stop faults ultimately trace back to terminal quality rather than electronics.
The teach pendant itself is part of the safety chain.
Problems involving the pendant commonly include:
Pendant-related safety faults often become worse during:
A common field symptom is:
This strongly suggests intermittent pendant connection instability.
Even when the UR controller and wiring are healthy, the safety loop may remain open because of external devices.
Typical examples include:
In these cases:
because the interruption originates upstream inside the external safety system.
In real production environments, repeated Emergency Stop faults are most commonly caused by instability in one of three areas:
| Failure Area | Typical Real-World Cause |
| Safety signal integrity | timing mismatch, intermittent channel sync |
| Mechanical wiring stability | loose terminals, vibration, cable fatigue |
| Safety-state validation | failed handshake, incomplete reset logic |
This explains why many E-Stop faults:
The controller is reacting to safety uncertainty, not necessarily catastrophic hardware failure.
Instead of replacing parts immediately, isolate the failure condition systematically.
Verify:
Do not assume the local reset clears the entire safety loop.
Check:
Intermittent contact problems frequently appear only during movement or vibration.
Look for:
These patterns strongly suggest safety-channel instability.
Inspect:
Many “robot faults” actually originate outside the robot controller.
Focus on:
The earliest warning often appears before the visible stop event.
Even after the physical safety issue is corrected, the controller may remain latched in a safety state.
This is intentional.
The controller requires manual confirmation before motion can resume.
Typical recovery path in PolyScope:
Without completing the safety confirmation sequence, the robot may remain inactive even though the electrical loop has already been restored.
Another part of the safety chain may still be open.
Common examples include:
No.
The controller must first confirm that the physical safety loop is electrically valid.
The most common causes are:
It indicates the controller detected excessive timing deviation between redundant safety channels.
This usually points toward signal synchronization instability rather than software failure.
The safety state must usually be manually acknowledged inside PolyScope before motion can resume.
Key components commonly involved in issues and replacements.
No related parts found. Please check available components in our catalog.
{"one"=>"比較する2つまたは3つのアイテムを選択します", "other"=>"選択された3つのアイテムの{{ count }}"}
コメントを残す