What exactly is a following error?

It's the difference between the position the controller demands of the axis at each instant and the one the encoder measures. When that difference exceeds the configured threshold, the robot stops. It means the axis can't follow the path in time, either from lack of torque or corrupted position feedback.

Why does it only trip when the robot carries load or accelerates hard?

Because under acceleration and load the demanded torque is at its peak. If the load is wrongly declared, the brake drags, the gearbox has high friction or the bus sags, the axis falls short right at that peak and the error appears.

Can I raise the error threshold so it stops tripping?

Not advisable. The threshold protects the mechanics and prevents collisions. Raising it only masks a real problem that can end in a broken gearbox or a crash. Diagnose the cause instead of silencing the alarm.

Position following error on robots: causes and what to do

The robot starts the cycle, accelerates toward a point and the alarm trips: following error (position error, or your brand's equivalent). The axis has fallen behind the position the controller demanded at that instant, the difference exceeded the configured threshold and the system stopped to protect you. This isn't a random fault: it almost always shows up under the same conditions —hard acceleration, maximum payload, a specific stretch of the path— and that repeatability is your best clue.

What this alarm actually means

The controller closes a position loop: at every instant it compares where the axis should be (setpoint) with where it is (encoder). The difference is the following error. In motion there's always a small, normal error, because the axis chases the setpoint with a minimal lag. The alarm trips when that error grows beyond tolerance, which means one of two things: the axis can't produce the torque it needs to follow the profile, or the position feedback is corrupted.

This is different from backlash or a lost mastering. A miscalibrated robot reaches a wrong position without alarming; a robot with a following error can't reach the correct position in time and stops. If you're unsure between miscalibration and mechanical play, check our guide on backlash in joints.

Causes ranked by frequency

1. Wrong payload declaration

The number-one cause, and the cheapest to rule out. If you changed the gripper, added a fixture, a cable, a sensor, or you're picking heavier parts and you didn't update the load data (mass, centre of gravity, inertias), the controller miscalculates the torque it needs. During acceleration the axis falls short and the error trips. Very typical after a tooling change that "only weighs a bit more".

2. Brakes not fully releasing

An axis brake that doesn't release completely —due to insufficient brake air on pneumatic robots, wear, or a weak brake command— drags the motion and forces the motor to overcome extra resistance. It's most noticeable on the gravity-loaded axes (1, 2, 3).

3. Worn gearbox or high breakaway torque

A worn, poorly lubricated or cold gearbox has more friction torque. In the first cycles after start-up, or on the specific axis that was already noisy or vibrating, the error shows up and then eases as the oil warms. It's a sign the gearbox needs inspection; cross-check with the abnormal vibrations guide.

4. Feedback noise or fault (encoder/cable)

If the encoder gives jumpy readings or the axis cable picks up noise, the controller "sees" the axis where it isn't and generates a phantom following error, often intermittent and with no clear mechanical pattern. It usually comes with other encoder or serial-communication alarms.

5. Low bus voltage or limited power electronics

If the DC bus sags under acceleration (limited drive, aged capacitors, weak supply), the motor lacks peak torque and falls behind. On KUKA KRC4 this can overlap with a DC bus fault.

6. Motion parameters too aggressive

Someone raised speed or acceleration in a program, or removed a smoothing, and the robot at the limit has no margin left. Usually coincides with recent program changes.

What to check and in what order

Log the exact context. Which axis, at what point in the program, at what speed/acceleration and with what load it trips. If it's always the same axis in the same move, point to mechanics or load; if it's random and switches axes, suspect feedback or electronics.
Verify load data. Confirm the declared payload matches the actual tool and part. If there was a recent tooling change that wasn't updated, fix it before touching anything else. It's free and solves a huge share of cases.
Review recent program changes. Was speed, acceleration raised or the path modified? Try lowering the override and see if it disappears: if it doesn't trip at reduced override, the dynamic margin is tight.
Listen to and feel the axis at slow speed. Noise, vibration or a hard spot point to gearbox or bearing. Move the axis manually (safely) and feel for abnormal resistance.
Check the brake. On robots with pneumatic brakes, verify air pressure. Run a brake test if your brand allows and confirm it releases cleanly.
Look at the alarm history. If encoder, serial-communication or battery alarms coexist, go to feedback first: inspect connectors and the affected axis cable (flexing, chafing, shielding).
Check if it only happens cold. If it trips in the first cycles and clears as it warms, suspect lubrication/gearbox. Cross-check oil level and condition.

Common shop-floor mistakes

Raising the error threshold to "clear the alarm". It masks the problem and you can end up wrecking a gearbox or crashing. The threshold is there to protect you.
Swapping the motor first. The motor is one of the least frequent causes. Replacing it without ruling out load, brake and gearbox is throwing money away.
Not updating the payload after a gripper change. The most expensive fault of all because it's the silliest.
Ignoring that it always trips at the same point. That pattern is telling you almost everything; write it down.

Warning signs: when to stop and call a specialist

Stop and don't force retries if:

The error comes with metallic noise, growing vibration or heating of the axis: gearbox or bearing damage may be developing.
It trips on several axes at once or erratically: points to DC bus, supply or general feedback, not a single axis.
It reappears after you verified load, brake and program: it's time for instrumented diagnosis of the loop (currents, encoder signals, gearbox breakaway torque).

A recurring following error is a developing mechanical or electronic fault, not a controller whim. A corrective diagnosis with the right tools tells in a few hours whether it's gearbox, brake, encoder or cable, and avoids replacing expensive parts blindly. If the robot is critical to the line, a preventive plan tracking load, lubrication and brake condition prevents most of these episodes.