FANUC SRVO-050 Collision Detect: When the Robot Stops and There Is Nothing in the Way

The robot stops mid-cycle. The screen says SRVO-050 Collision Detect on G1 A1. The operator swears nothing hit anything. You walk the tool path, look at the fixturing, find no marks, no rubbing, no part out of place, and the alarm clears on reset. Then it happens again twenty cycles later. SRVO-050 is one of the most misunderstood servo alarms in the FANUC catalogue, and the fix almost never lives where the operator wants to look. We see this weekly at Probot Systems on R-30iB Plus cells running payload schedules that drifted out of sync with reality.

This post is written for technicians and integrators chasing SRVO-050 on LR Mate 200iD, SR-6iA, R-30iB, R-30iB Plus, and CRX cobot cells. The diagnostic logic carries across cabinets, though CRX adds a contact-stop wrinkle worth knowing about.

What this error actually means

SRVO-050 is the Collision Detect alarm. The PNT1-114 echo on page 1028 of the FANUC error code manual makes the path explicit: “PNT1-114 Collision alarm Cause: This alarm is echoed to the PLC when a SRVO-050 SERVO Collision Detect alarm (G:%d A:%d) is posted. Refer to the Teach Pendant alarm screen for the group and axis number. Refer to SRVO-050 for the cause.” That is FANUC’s way of telling you the controller has a Collision Guard threshold on each joint, and the disturbance torque it observed exceeded that threshold.

Mechanically, the controller estimates what torque each joint should need to follow the path. It uses the payload schedule, the motion model, and the friction model to do that. Then it compares estimated torque to measured torque. If the difference exceeds the Collision Guard sensitivity for that joint, SRVO-050 fires. So you can hit something for real, or you can give the controller a wrong model and watch it call a phantom collision.

Most common causes, in order of probability

In order of how often we land on each one on a service call:

1. Payload, TCP, or center of mass not configured for current tooling. A gripper swap, a tool change, a part dimension change, anything that moves mass and the controller does not know about it. The motion model is wrong, the torque estimate is wrong, the alarm fires. A Reddit user chasing SRVO-050 on a 90kg payload arm landed here after ruling out hardware (reference thread).
2. Collision Guard sensitivity set too tight for cycle. Cycles that run faster than they were originally tuned for, or cells with new programs running on an old sensitivity setting, trip SRVO-050 on motion the robot is fully capable of executing. The DIY Robotics thread on combined SRVO-046 and SRVO-050 confirms how often this is missed (forum reference).
3. Cold mechanics on the first cycle of the shift. Gearbox friction is higher when the robot is cold. The torque estimate uses the warm friction value, so the cold cycle looks like a collision. Clears once the joint warms up.
4. Mechanical bind, harness pulling on the wrist, or gripper hitting a fixture. Real but often subtle. A dress pack that worked loose, a hose against a fixture, a part that landed half a millimeter off. The torque the controller sees is real, the cause is not the program.
5. Failing motor, encoder, or reducer on the affected joint. Last on the list because it is the most expensive guess, but real on older arms. A poster on the Fanuc subreddit confirmed that on bigger arms with separable motor and encoder, this is a viable cause once payload and program have been ruled out (Fanuc subreddit).

How to diagnose in under 10 minutes

Step 1. Note the group and axis on the alarm screen. SRVO-050 always names G: A:. Take it to the program.

Step 2. Single-step the move that fires the alarm. The exact point along the path tells you where to look. If it always trips at the same line, you have a payload or program issue at that point. If it trips at random points, lean toward friction or sensitivity.

Step 3. Open MENU > SYSTEM > Motion > Payload. Confirm the active payload schedule. Check mass, CoG, and inertia against the real tooling. If anything is off, fix payload first.

Step 4. Run PAYLOAD ID with the actual tooling installed. PAYLOAD ID measures dynamic response and is far more accurate than typing in numbers from a CAD model.

Step 5. Bump Collision Guard sensitivity up ten to twenty percent temporarily and run the program. If the alarm goes away, the payload model is the problem and you should not leave the sensitivity loose. Tighten back up after fixing payload.

Step 6. Inspect the path for harness snagging, dress-pack interference, or fixture contact. Anything physical resisting the motion will read as collision torque (reference thread).

Step 7. If SRVO-050 only fires on the first cycle of the shift, add a slow warm-up program before production. Cold-cycle trips are a classic pattern.

How to fix it

Match the fix to what you found.

If payload data was wrong: run PAYLOAD ID with the current tooling installed, save the result to the correct schedule, and call SELECT PAYLOAD[n] from any program that swaps tools. Maintain a payload schedule per tool, do not overwrite payload 1 every time. Then run a full-speed test cycle to confirm.

If Collision Guard sensitivity was too tight: open MENU > SYSTEM > Motion > Coll Guard for the affected joint. Increase sensitivity in small steps (5 to 10 percent at a time) until SRVO-050 stops, then verify the cell still detects real crashes by simulating a low-speed contact with a soft target. Do not just disable Collision Guard.

If cold-start is the pattern: add a slow warm-up program at start of shift that exercises every joint through its working range. Two to three minutes of low-speed motion is usually enough.

If a mechanical bind is the cause: fix the physical problem, then run the diagnostic again. Do not raise sensitivity to mask a real bind.

If motor, encoder, or reducer is the suspect: this is service-call territory on a production cell. Mastering data has to be backed up, the part has to be ordered correctly for the arm variant, and the swap has to be planned around production. The Fanuc subreddit user reached this conclusion only after ruling out everything cheaper (Fanuc subreddit).

When to call a specialist

Call us when payload is correct, sensitivity is tuned for the cycle, no mechanical bind is present, and SRVO-050 still drops on the same joint. At that point you are looking at motor, encoder, or reducer work, all of which want mastering preserved and a known-good replacement part ordered for the right arm variant.

Same goes for CRX cobots throwing SRVO-050 around contact-stop tuning. The collision detect logic interacts with the contact stop function on CRX, and changing one without understanding the other has put more than one CRX cell into a confusing state.

contact us for a service intervention, or set up a maintenance preventive contract so payload schedules, dress packs, and Collision Guard sensitivities are audited before SRVO-050 starts dropping at 11pm on a Sunday.

Related errors to check

• SRVO-046 OVC alarm: peak overcurrent on the same axis. Often logs with SRVO-050 on cells with stale payload schedules. Same diagnostic family.
• SRVO-043 SERVO DCAL: thermal version of an aggressive cycle. If both appear, the cycle is asking too much of the affected joint.
• SYST-212 Need to apply to DCS param: on CRX cells, changes to payload schedules need a DCS apply. SRVO-050 plus SYST-212 in the same shift points there.

Probot Systems is a FANUC integrator based in Lévis, Quebec. We commission and maintain LR Mate, SR-6iA, R-30iB Plus, and CRX cells across Canada and the US, and SRVO-050 is one of the alarms our preventive maintenance contracts are designed to keep off the floor. If you want a payload and sensitivity audit before the next product change, that is a contact us conversation.