Error C403A0: A Clamp Guard, Not a Tool-Collision Fault

The flange approaches the lower arm with roughly 15 mm of visible clearance, yet the UR5 e-series running software 5.8 enters protective stop mode with C403A0: Danger of clamping between the robot lower arm and tool. The stop comes from an internal flange-to-forearm clamping model, not from the configured tool geometry or a conventional tool-collision calculation. Plan the path against that internal envelope before changing motion or safety settings.

Why do the usual fixes fail?

Several intuitive responses act on the wrong part of the signal chain. The controller derives robot geometry from joint position, evaluates the modeled flange and forearm separation, and commands a protective stop when the internal clamping condition becomes true. A separate collision planner operates upstream and cannot suppress that decision.

Do not treat a successful application-level collision check as proof that the command is admissible. The controller evaluates its own condition after receiving the commanded motion.

What actually generates C403A0?

The measured inputs are the robot joint positions. Forward kinematics place the forearm and flange in a common robot coordinate system. The controller then compares simplified protective shapes around those components. When their calculated separation crosses its internal boundary, the controller identifies a possible clamping region and engages protective stop mode.

This explains why the alarm can precede physical contact. The monitored geometry contains deliberate clearance outside the visible parts. It also explains why changing the modeled end-effector outline alone does not remove the alarm: the relevant monitored point is centered on the flange.

A reported triggering configuration contained these six joint values:

136.46°  4.19°  63.94°  98.65°  -133.19°  -10.6°

The joint order was not separately identified, so preserve the robot's displayed order when using this tuple as a regression case. Do not relabel or reorder the values inside an offline model without checking its joint convention.

Which geometric boundary applies to the UR5e case?

For the UR5 e-series installation running software 5.8, the working model used two controller envelopes:

• A cylinder of radius 37.5 mm around the forearm.
• A sphere of radius 37.5 mm centered at the flange.
• A trigger when the distance between those shapes is less than 28 mm.

Interpret each 37.5 mm value as the radius of the simplified shape itself. Model the forearm with a cylinder centered on its modeled axis; do not measure the physical arm radius and add another 37.5 mm. Model the flange region as a complete 37.5 mm-radius sphere centered at the flange, not as a sphere centered on the tool center point.

The phrase “distance between the shapes” must map to the distance function used by the planning library. Use the minimum surface-to-surface separation between the finite forearm cylinder and the flange sphere, then reject a state below 28 mm. If a library returns centerline-to-center distance instead, convert it to surface separation before applying the threshold. For a point projected onto the cylindrical span, the radial surface-gap assumption gives:

surface_gap = centerline_to_flange_distance - 37.5 mm - 37.5 mm
reject when surface_gap < 28 mm

Under that stated radial assumption, rejection begins below a centerline-to-flange distance of 103 mm. Near either end of a finite cylinder, use a true sphere-to-cylinder distance calculation rather than the radial shortcut.

Can the UR5e dimensions be reused for a UR10e?

No model transfer should occur without measuring the stop boundary. A UR10e running software 5.12.2 was reported to stop with an apparent physical clearance closer to 4–5 cm, and the UR5e values did not reproduce its observed boundary. That difference makes robot model and software revision part of the diagnostic record.

Use the following decision path:

1. Record the exact robot model and software version from the controller.
2. Capture the six joint values at several repeatable near-boundary states.
3. Calculate flange-to-forearm clearance using the candidate model.
4. Compare predicted crossings with the actual C403A0 transition.
5. If a single boundary does not classify both stopped and accepted states, do not compensate by adding an arbitrary margin. Request the applicable geometry and distance definition from Universal Robots.

A larger visible gap may come from different internal geometry, a different reference point, or a different interpretation of shape distance. The boundary test separates those cases more reliably than measuring the shortest visible gap with a ruler.

How should the trajectory planner handle the clamp envelope?

Run the controller-envelope test alongside the application's detailed collision test. Neither replaces the other: the detailed model protects the actual tool and workcell, while the simplified test predicts whether the controller will accept the robot configuration.

1. Import or calculate each candidate state's six joint positions.
2. Use forward kinematics to calculate the flange frame and forearm axis in one coordinate system.
3. Create the forearm cylinder with radius 37.5 mm and the flange sphere with radius 37.5 mm for the documented UR5e 5.8 case.
4. Calculate the minimum surface distance between the sphere and the finite cylinder.
5. Reject the state when that distance is below 28 mm.
6. Evaluate the interpolated path between waypoints, not only the endpoints. A clear start and finish can still pass through the protected region.
7. Run the application's real-tool and workcell collision checks on every state that passes the controller-envelope test.
8. Move or replace the conflicting waypoint, then regenerate the path and repeat both checks.

Keep the controller-envelope result separate in planner diagnostics. A useful rejection record contains the joint state, calculated flange center, closest point on the forearm cylinder, surface gap, robot model, and software version. This makes a C403A0 prediction distinguishable from a collision involving the real end effector.

How do you diagnose an existing path before adjusting it?

Measure first. Trend the calculated surface gap over path progress and place the protective-stop event on the same trace. The useful question is not how much air appears between the parts at rest, but where the model reaches its minimum separation during the commanded move.

1. Preserve the original program and record the configuration that produces C403A0.
2. Record nearby accepted configurations on both sides of the failing region where practical.
3. Replay those states in the offline model without commanding the robot.
4. Plot or log the sphere-to-cylinder surface gap for each interpolated state.
5. Check frame definitions, unit conversion, joint order, and flange-frame selection if the predicted minimum occurs at a different location.
6. Modify geometry only after the calculated boundary aligns with the observed stop transition.

Tuning does not fix geometry. Reducing speed may make a test easier to observe, but it does not move a waypoint outside a proximity envelope. Likewise, changing a tool center point used by the application does not necessarily move the flange center used by this check.

How is the corrected path verified?

Verification must show both controller acceptance and application collision clearance. Passing only one test leaves either a nuisance stop or an unprotected physical interference.

1. Run the planner against the known triggering six-angle configuration and confirm that the UR5e 5.8 envelope rejects it.
2. Test accepted configurations near the boundary and confirm that the planner does not reject every nearby state because of a frame or radius error.
3. Check every interpolated segment of the revised path for a surface gap of at least 28 mm under the documented model.
4. Re-run the detailed end-effector, robot-link, fixture, and workpiece collision checks.
5. Execute the revised motion under the site's controlled commissioning procedure and verify that C403A0 no longer occurs.
6. Store the robot model, software version, geometry constants, distance convention, and regression configurations with the planner configuration.

The reported UR5e implementation stopped encountering the alarm after these shapes were incorporated into trajectory planning. Treat a software update, robot-model change, or unexplained change in the observed boundary as a reason to repeat the boundary validation.

FAQ