Key takeaways
A six-axis robot that faults out mid-cycle usually stops the whole cell with it: the weld cell waits, the conveyor backs up, the palletizer starves the line. This guide is for maintenance technicians and plant engineers who need to diagnose the common fault families on industrial robot arms and get back into automatic safely.
Every major controller displays a fault code, a sub-code, and usually the axis number. That one line is worth more than an hour of guessing, so record it before clearing anything. The alarm history also tells you whether this is a first occurrence or a chronic pattern.
One warning applies to everything below: never guess what a code means. Fanuc, ABB, KUKA, and Yaskawa Motoman each use their own numbering, and meanings shift between models, series, and firmware versions. Confirm the code in the manufacturer's alarm reference for your exact controller.
Modern robots monitor torque disturbance on every axis and stop when reality does not match the model. The usual causes, in order: a real collision, a changed payload (heavier part, part stuck in the gripper, spatter or adhesive buildup), or something new in the path such as a shifted fixture or dropped part.
Do not simply reset and press cycle start. Walk the cell, then jog away from the obstruction in the correct frame: joint jogging is safest when unsure, because world or tool frame moves can drag the arm deeper into whatever it hit. If the fault repeats with a visibly clear path, verify the payload data in the program and check for mechanical binding.
Each axis has software soft limits and, further out, mechanical hard stops. An overtravel fault means the axis crossed a soft limit, which usually traces back to a bad touched-up point, a program edit, or, more seriously, lost mastering that shifted where the robot thinks its limits are.
Related program-side errors are singularity and reach faults: the arm is asked to move through a wrist singularity or to a point at the edge of its envelope. These are path problems, not hardware failures. Reteach the points, add an intermediate position, or change the posture instead of hunting for a broken component.
Servo alarms on a robot follow the same electrical logic as machine tool drives. Overcurrent points to a short or insulation failure in the motor or cable. Overload points to a mechanism working too hard: binding, a failing reducer, or a brake not releasing fully.
Work from mechanical to electrical: confirm the axis moves freely (with the arm safely supported), then check connectors and cables, then the motor, then the drive. The patterns match the ones in our guide to servo motor failure symptoms, and the diagnosis order carries over almost unchanged.
This is the classic self-inflicted robot failure. Absolute encoders keep their position data alive with a backup battery while the controller is powered off. Let that battery die during a shutdown and the robot loses its zero positions and needs re-mastering of every axis before it can be trusted again.
The fix is pure discipline: replace encoder batteries on schedule, with the controller powered ON, exactly as the manual describes, so the encoders stay powered during the swap. On Fanuc robots the warning stage is a battery alarm; see our breakdown of the Fanuc APC alarm 300 battery fault for that case. Other brands behave the same way under different code numbers.
A robot standing still with no servo power is often not faulted at all: it is safety stopped. Estop chains, light curtains, safety scanners, and door interlocks all drop the safety circuit, and the fix lives at the cell device, not in the robot. Find which device in the chain is open before assuming the robot failed.
Teach pendant problems belong here too. A worn three-position deadman (enabling) switch causes nuisance stops while jogging, and damaged pendant cables mimic controller faults. Respect the modes: T1 limits speed for teaching, T2 allows process speed under strict conditions, automatic assumes nobody is inside.
The safety rules are absolute. Never enter the envelope without the cell in a safe state, apply lockout/tagout for mechanical work, and account for stored energy: electrical, pneumatic, hydraulic, and gravity, because a vertical axis can fall when a brake is released. Safety devices are never adjusted, defeated, or bypassed: a misbehaving curtain or interlock is handled through your safety maintenance procedure, not a workaround.
A large share of "robot down" calls end at the end effector. Low air pressure, a sticking gripper solenoid, a failed part-present sensor, or a chafed cable on axis 6 stalls a cycle just as effectively as a servo alarm. Check the tooling before the arm.
The dresspack, the cable and hose bundle on the moving axes, deserves special suspicion. It flexes millions of times, and wear produces the worst kind of problem: intermittent faults that appear only at certain poses. If an error occurs at one point in the path only, flex-test the cables at that pose.
| Symptom | Likely cause | First check |
|---|---|---|
| Collision fault mid-cycle on one axis | Crash, changed payload, obstruction | Inspect part, gripper, and path; verify payload data |
| Fault only at one pose or path segment | Dresspack or cable wear | Flex-test cables at that pose, inspect the dresspack |
| Position errors on all axes after a shutdown | Encoder battery dead, mastering lost | Alarm history for battery warnings; re-master per the manual |
| Arm stopped, no servo power, no robot alarm | Open safety circuit | Estops, light curtains, door interlocks, scanner status |
| Overload alarms on one axis under load | Binding, brake drag, failing reducer | Free-movement check with the arm supported, brake function |
Robot arms stay reliable when four habits hold. Replace encoder batteries on the calendar, not when they die. Test brakes at the manufacturer's interval, because a slipping brake is both a fault source and a safety hazard. Lubricate each axis per its service interval, since reducers fail slowly and expensively.
Above all, back up the controller and programs regularly and keep a copy off the robot. A dead controller with no backup is not a repair, it is a rebuild, with every point retaught from scratch.
Recovery gets the shift moving; measurement gets the problem engineered out. Log every robot fault as a downtime event with a cause code (collision, servo, battery, safety stop, tooling), then track MTBF and MTTR per robot. A cell that faults briefly but daily can cost more availability than one dramatic breakdown, and only the numbers make that visible in your OEE.
This is also where a maintenance system earns its keep in automated cells: fault history, battery and lubrication schedules, and backup tasks in one place. We cover the setup in our guide to CMMS software for industrial robotics and automated cells.
Fabrico is computer-vision-verified OEE plus closed-loop maintenance execution: cameras catch stops and micro-stops that manual logs and sensors miss, and maintenance work orders close the loop from detection to fix. For a robot cell, that means the two-minute collision resets nobody writes down still show up in the data, with a work order trail from detection to the engineering fix. Book a Fabrico demo to see it on your own cells.
Either the arm is genuinely contacting something, or the torque model is wrong. Check for obstructions and tooling shift first, then verify the payload data matches the real part and gripper, then look for mechanical binding or brake drag on the faulting axis.
If it dies while the controller is powered off, the absolute encoders lose their reference and the robot loses mastering. It will not run until every axis is re-mastered per the manual. Replace batteries on schedule with the controller powered ON to avoid this entirely.
No. It is a safety stop: the safety circuit opened and the controller removed servo power as designed. Find and restore the open device (curtain, estop, door interlock) through normal procedures. Never bypass or defeat a safety device to keep running.
Not safely. Inspect the cell, clear the fault, jog clear in T1 at reduced speed, and dry-run the path at low override first. Returning to automatic on an unverified path is how one fault becomes a crash.
After every program or configuration change, and on a fixed schedule regardless. Store copies off the controller. Without a current backup, a controller failure means reteaching the entire application.
Anmeldung
Blog
