FANUC Payload Setup After Calibration: PAYLOAD ID, Collision Sensitivity, and the SRVO-050 Trip You Keep Resetting

You finish a new tool install on an LR Mate 200iD or a CRX-10iA, the cell looks like it should run, and within ten cycles you are looking at SRVO-050 Collision Detect on G1 A1. Or the robot vibrates on stop. Or it drops the part in auto mode. The operator swears nothing is hitting anything, the program “ran fine on the old gripper”, and yet here we are. Payload is the answer about ninety percent of the time, and the fix is not typing a number into a screen. At Probot Systems we walk customers through payload setup after every tool change and after every calibration, because skipping it is the most reliable way to lose a shift to phantom collision trips.

This post is written for technicians and integrators setting up payload on LR Mate, CRX cobots, and R-30iB Plus cells after tooling changes, calibration, or controller swaps. It covers PAYLOAD ID, payload schedules, collision sensitivity interaction, and the DCS apply step CRX users keep forgetting.

What this error actually means

There is no dedicated “payload alarm” code, but the symptoms surface as SRVO-050 Collision Detect and SRVO-043/046 servo current alarms when the controller’s motion model does not match real-world load. The PNT1-114 echo on page 1028 of the FANUC error code manual confirms the path: “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 cross-reference shows that the controller is comparing predicted torque to measured torque on the named axis. Wrong payload means wrong prediction, which reads as phantom collision.

On CRX cells, SYST-212 Need to apply to DCS param compounds the issue. Per the manual on page 1799: “SYST-212 Need to apply to DCS param Cause: Mastering data or robot parameters are changed, but they are not applied to the DCS parameter. Remedy: Press F3(APPLY) in the DCS menu.” Payload changes on a CRX often need a DCS apply before auto run will start, and missing that step leaves the cell stuck.

Most common causes, in order of probability

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

1. Payload mass and CoG not updated after tool change. This is the single most common one. Mass changed, CoG shifted, controller still planning motion with the old numbers. SRVO-050 trips on the first aggressive deceleration. Multiple Reddit and DIY Robotics threads document this exact failure, including a CRX10i recovery where DCS parameters had to be reapplied after editing payload schedules (CRX-10i thread).
2. PAYLOAD ID never run, only static numbers entered. Typing mass and CoG from a CAD model gives you the static figures. PAYLOAD ID measures dynamic response on the real arm with the real tooling. The two are not equivalent. The DIY Robotics thread on payload error after calibration is one of many that lands on this difference (reference thread).
3. Wrong payload schedule selected at runtime. The cell has multiple grippers, the program does not call SELECT PAYLOAD[n] before motion, and the active schedule is for a different tool. A thread on increasing the number of payloads on a FANUC controller confirms the DCS apply requirement for any payload change (payload schedule thread).
4. Cold mechanics on the first cycle of the shift. Cold gearboxes have higher friction. The torque model assumes warm friction. The first cycle reads as collision. Clears once the joint warms up, returns the next morning.
5. Collision sensitivity not retuned for new tooling. Sensitivity that worked for the old gripper may be too tight for the new one, even with payload correct. CRX cells have an extra contact-stop layer that interacts with collision sensitivity, and disabling contact stop without understanding the interaction has caused at least one cell crash documented on Reddit (CRX thread).

How to diagnose in under 10 minutes

Step 1. Read the active payload from MENU > SYSTEM > Motion > Payload. Note the schedule number, the mass, the CoG (x, y, z), and the inertia values. Compare against the actual tooling. If anything is off, fix payload before anything else.

Step 2. Confirm which payload schedule the running program selects. If you do not see a SELECT PAYLOAD[n] line near the top of the program, the cell is running on whatever schedule was last active, which is rarely the right one in a multi-tool cell.

Step 3. Identify when the alarm fires. Always at the same point in the cycle is a payload or program problem at that point. Always on the first cycle of the shift is a cold-friction problem. Random is more likely a mechanical bind or harness interference.

Step 4. On a CRX, check MENU > SYSTEM > DCS for any “Need apply” markers. Payload changes on CRX need a DCS apply before they take effect (CRX thread).

Step 5. Walk the cell physically. Look for dress pack interference, hose against fixture, part landing off-center. The robot felt something. Sometimes that something is real.

How to fix it

Match the fix to what you found.

If payload data is stale: run PAYLOAD ID with the current tooling installed. Procedure: install the tool, hold a known mass at the TCP if the application allows, go to MENU > SYSTEM > Motion > Payload, pick the correct schedule number, run PAYLOAD ID, save the result. PAYLOAD ID exercises the arm through a measured sequence and computes mass, CoG, and inertia from dynamic response. The Reddit SRVO-050 thread confirms how reliably this fixes phantom collision trips (Reddit thread).

If the program does not select the right schedule: add SELECT PAYLOAD[n] at the start of any program that uses a specific tool. Maintain a schedule per tool, do not overwrite schedule 1 every time. The DIY Robotics thread on payload schedules makes the same recommendation (payload schedule thread).

If you are on a CRX cell: after any payload change, go to MENU > SYSTEM > DCS, set the code-num, and press F3(APPLY). Then cycle the controller. Skipping the apply leaves the cell in pending state and auto run will not start (CRX thread).

If cold-start is the pattern: add a slow warm-up program at start of shift. Two to three minutes of low-speed motion through every joint usually clears it.

If sensitivity is the issue: tune Collision Guard sensitivity for the affected joint in MENU > SYSTEM > Motion > Coll Guard. Move in small steps. Do not just disable Collision Guard.

After every payload change, run a full-speed test cycle to verify. The Reddit SRVO-050 thread is explicit about this final verification step (Reddit thread). Phantom collision trips do not show up at jog speed.

When to call a specialist

Call us when payload schedules are correct, PAYLOAD ID has been run, sensitivity is tuned, and the cell still drops collision alarms during normal cycle. At that point you are looking at deeper diagnostics on the motor, encoder, or reducer for the affected joint, or a controlled-start audit of the payload-related system variables. On a CRX with contact stop in the mix, the diagnostic gets tangled enough that a remote screen-share is usually faster than another shift of guessing.

Same applies when an operator has been editing DCS parameters to chase a payload error and is no longer sure what the original state was. We restore from backup, verify DCS signatures, and document the production state so the next change has a known starting point.

contact us for a service intervention, or set up a maintenance preventive contract so payload schedules, PAYLOAD ID timestamps, and DCS signatures are reviewed before a tool change causes downtime.

Related errors to check

• SRVO-050 Collision Detect: the headline alarm. Payload is the most common root cause.
• SRVO-046 OVC alarm: overcurrent on the same axis. Often logs alongside SRVO-050 on cells with stale payload schedules.
• SRVO-043 SERVO DCAL: thermal alarm on the amplifier discharge resistor. Same payload-related root family.
• SYST-212 Need to apply to DCS param: on CRX cells, this fires every time a payload schedule is edited without a DCS apply.

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. Payload setup after calibration is one of the items our preventive maintenance contracts catch every cycle, because skipping it is the most reliable way to surface phantom collision trips. If your cell is dropping SRVO-050 after a tool change, that is a contact us conversation.