The path check reported 100% passed, and the robot hit the fixture on the first run anyway. That gap between a green report and a damaged torch is one of the most common traps in offline-programmed cells, and it has four causes you can test in order: a detector that is not assigned to the motion type where the hit happens, a tool collision body smaller than the real torch, a report that went stale after a manual edit, and a layout that no longer matches the cell on the floor. This guide gives you the test and the fix for each cause, a worked example for sizing the tool body, and the 3D-scan step that closes the gap between the simulated cell and the built one. It is written for anyone who programs weld or handling paths offline and runs them in a cell that also carries vision.
What a green report actually certifies
A path check tool is a collision detector: it steps the simulated robot along the programmed path and tests whether simplified bodies intersect — the same collision detection problem every 3D engine solves. It can only report on two things: the geometry you gave it, and the motion types you pointed a detector at.
Both are settings, and both start narrower than the physical cell. A report of 100% passed means no intersection was found among the checks that ran. It does not mean the real robot is clear, and it cannot: the checker has never seen your torch nozzle, your fixture shims or your cable bundle.
So the useful question is not whether the check is any good, but what this check actually looked at. The triage below answers that in one pass.
Triage: find your cause in one pass
| What you see | Most likely cause | Test that confirms it |
|---|---|---|
| Green report, hit while the torch searches for the joint | Detector not assigned to the Search motion type | Robot collision detectors setup: list the ticked motion types |
| Green report, hit with the torch body behind the tip | Tool collision body smaller than the real torch | Edit Detectors: compare the body envelope with the physical tool |
| Green report, hit returns after you adjusted path points | Stale check result | Re-run the whole path check from scratch |
| Green report, hit where the CAD layout shows room to spare | As-built cell differs from the layout | Scan the cell and compare the point cloud with the CAD |
The first two causes cover most first-time cases: the check never looked at the move, or it looked with the wrong geometry. The last two are quieter — the check was correct when it ran, for a path or a cell that no longer exists.
Cause 1: the detector is not assigned to every motion type
In the offline programming (OLP) welding workflow, the robot settings in the Program tab — the gear next to the Cal tools — open the Robot collision detectors setup. That page, not the simulation view, decides which detector the path check tool uses and on which motion types it uses it.
The welding workflow checks four motion types: Via, Process, Search and Nozzle touch. Each can carry its own detector, and each must be ticked for the check to inspect it. If the detector is only ticked for Process, the report stays green while the hit happens on the first Search move — the move that probes for the joint and runs closest to the part.
Per-class assignment is a feature. You can legitimately run a detector that ignores an enclosure panel on Process moves so it stops flagging the panel as an obstacle. The rule is that some detector must still cover the classes where that panel can be struck: Via, Search and Nozzle touch.
Test: open the Robot collision detectors setup, write down which motion types carry a detector, and compare the list with where the real hit happened. An unticked class at that point in the path is your answer. Fix: tick the class, assign the correct detector and re-run the check.
Cause 2: the tool collision body is smaller than the real torch
The detectors themselves are edited under Edit Detectors in the Program tab. A common default is a sphere or short capsule at the tool flange. That represents the flange and ignores the torch: everything the tool adds beyond the flange — body, nozzle, gun arms — is invisible to the check for as long as the body stops at the flange.
The body has to wrap the whole tool, and two dimensions decide whether it does:
- Radius: at least half of the widest physical dimension of the tool, plus a clearance margin.
- Length: far enough to reach the tool tip, nozzle face or gun arms, whichever sticks out furthest.
The worked example below runs the arithmetic for a typical welding torch. Once the body passes those two dimensions, a green report describes the real tool.
Worked example: 60 mm torch body, 120 mm nozzle, 25 mm clearance
Inputs for a typical MIG torch (example values — measure them on your tool):
- Widest dimension across the torch body: 60 mm
- Nozzle protrusion beyond the flange face: 120 mm
- Clearance margin: 25 mm, chosen to absorb fixture placement tolerance and torch deflection
The rule: the collision body is a capsule that wraps the tool, so its radius is half the widest dimension plus the clearance, and its length equals the full protrusion.
The arithmetic: r = 60 / 2 + 25 = 30 + 25 = 55 mm, so the envelope diameter is D = 2 × 55 = 110 mm, and the capsule reaches 120 mm past the flange. Compare that with the flange sphere many layouts ship with. A 40 mm radius sphere clears any gap wider than 2 × 40 = 80 mm. The real torch needs 110 mm. A 90 mm gap in the fixture therefore passes the check — 90 mm is wider than 80 mm — and stops the torch cold, because 90 mm is narrower than 110 mm.
Decision: before trusting a green report, open Edit Detectors and confirm the tool body meets both dimensions. If the radius is below d / 2 + c or the body stops short of the tip, fix the body and re-run. For a torch of this size, clearance between 20 and 30 mm works: above it the body starts producing false alarms on tight joints, below about 15 mm it no longer covers fixture tolerance.
Cause 3: the report goes stale after a manual edit
A path check result belongs to the path exactly as it stood when the check ran. Edit one point and the result no longer describes that path. The failure is sneakier than a wrong total: after a manual adjustment, the event list can clear the collision at the edited point and mark the spot as fine now, while events on other moves remain and the overall pass state lags behind the current path.
The habit that prevents this costs one click: after every manual edit, re-run the whole path check, not the single point. Sort the remaining events by motion type so you can see at a glance whether survivors sit on Search or Nozzle touch moves, then close those with the detector assignment from Cause 1.
Cause 4: the cell on the floor is not the cell in the CAD
When the settings are all correct and the check still misses the hit, the input data is wrong: the simulated cell no longer matches the built one. Fixtures get shimmed, clamps sit open where the CAD drew them closed, the part is present where the layout assumed absent, and dress packs and cable bundles rest wherever gravity left them. A 15 mm fixture offset against a 25 mm clearance leaves 10 mm on exactly the move the check cleared.
That offset is measurable, and vision measures it:
- Capture the fixtures, clamps and tooling with a 3D sensor — a laser profiler swept along the fixture gives accurate surfaces, a ToF sensing camera gives a fast coarse layout of everything inside the robot envelope.
- Convert the capture to a point cloud; the 2.5D height map to point cloud conversion covers the pixel-to-XYZ step for profiler output.
- Register the cloud against the layout with point-cloud template matching and deviation measurement and read off every position that sits further from the model than your clearance.
- Move the layout to the measured positions and re-run the path check on the corrected geometry.
One sensor for accurate surfaces and one for coarse layout covers most cells:
- Type
- Laser profiler
- Type
- Depth / ToF camera
The controller that runs the verification lives in the cell cabinet:
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
The MV-VC3301H-128G66 vision controller includes the VM6200Pro vision license and pairs an Intel Core i3 processor with 8 GB memory. Its 5+ LAN ports take the profiler, the depth camera and the cell network without added hardware.
Checks before you trust the next green report
Run this list before you release the next revision of a path:
- Every motion type — Via, Process, Search, Nozzle touch — carries the correct detector in the Robot collision detectors setup. Why: an unticked class is invisible to the report.
- The tool body in Edit Detectors wraps the full tool, with radius at least half the widest dimension plus clearance and length to the tip. Why: the check can only see the geometry you gave it.
- The check has been re-run in full after the last manual edit. Why: a result describes the path as it stood when it was generated.
- The layout matches an as-built scan of the cell within the clearance margin. Why: simulation geometry drifts away from the floor one shim at a time.
- The simulation ran once with detectors enabled, watching the Search and Nozzle touch moves. Why: the 3D view shows hits the report can skip.
Next step
Close the four causes in order and the green report and the floor agree. To add the as-built verification to an existing cell, start from the 3D sensors and vision controllers pages, or filter by sensor type in the camera finder. If you want a second pair of eyes on the registration plan, send the layout through the contact page. The systems integration guides collect the rest of the checks, including 3D camera and robot integration compatibility and the fix for erratic robot motion after a camera locate.
Questions
Why does the path check say 100% passed if the robot collides?
The report certifies only the checks that ran: the motion types a detector was assigned to, and the geometry of the collision bodies. A class without a detector, or a tool body smaller than the real torch, gives a clean report and a real hit. After you correct the assignment and the body, re-run the check; if the report changes, the earlier green was a blind spot rather than a software fault.
How large should the torch collision body be in Edit Detectors?
Wrap the whole tool in a capsule: radius at least half of the widest physical dimension plus your clearance margin, and length enough to reach the nozzle face or the gun arms. For a torch 60 mm across with a 120 mm nozzle and 25 mm clearance, that is a 55 mm radius capsule reaching 120 mm past the flange. Weld guns need a body for both the open and closed states, and the path checked against both.
Can I trust a green point status after adjusting one path point?
Treat it as a hint only. The event list can clear the collision at the point you just edited while events on other moves remain, and the overall pass state lags behind the current path. Re-run the complete path check after every manual edit, and sort the surviving events by motion type to see quickly whether they sit on Search or Nozzle touch moves.
How do I confirm the built cell matches the simulation layout?
Scan the fixtures, clamps and tooling with a 3D sensor, register the point cloud against the layout, and read the deviations. Correct every position that sits further from the model than your clearance margin: with a 25 mm margin, a fixture found 15 mm off leaves only 10 mm on the cleared moves, so it must be moved in the layout before the next check run.
Is a passed path check enough to release the program to production?
No. The check covers simulated geometry only; it knows nothing about safeguard circuits, speed overrides or a part that has shifted in the gripper. Release with the first cycles at reduced speed and safeguards active, watch one full cycle for each part type, and only then switch to automatic operation. Re-run the check whenever the tool, fixture or part changes.