Erratic robot motion after camera locate: check the active TCP

The locate returned a part, the program stepped on, and the arm still swung wide, missed high by a hand's width, or dove toward the fixture. Before you blame the vision job, look at the tool each move statement carries: in most of these cases a move after the camera locate is executing under a different tool center point (TCP) than the point was taught with. This guide is for anyone integrating a wrist or fixed camera into a robot cell. You will learn how a correct locate produces wrong-looking motion, how to compute the error from two tool offsets, which TCP each move must carry, and the checks and conventions that keep the mismatch from returning after the next edit.

Why does the robot move erratically after a camera locate?

In most cells the motion is not erratic at all: the controller is putting the wrong tool tip on the coordinates the locate returned, because a move after the locate runs under a different TCP than the point was taught with.

The classic sequence: the linear move after the locate — a moveL on many pendants — was taught with the camera tool active, TCP11, and someone later edited that statement to the gripper tool, TCP2. From that edit on, every good locate is followed by motion that looks wrong, and the vision job takes the blame. The arm is not lost; it is putting the selected TCP exactly where the taught coordinates say.

Test in this order, because the first two are program-side and take minutes: a statement whose tool was changed after its point was taught; a TCP whose numbers were edited while taught points still used it; a point re-taught under a third tool by accident. Only when all three come back clean does the vision side move to the top of the list. The tell is in the error's signature: a constant miss, same size and direction, points at a tool or calibration fault; a miss that changes every cycle points at vision.

How can a correct locate still put the arm in the wrong place?

The locate and the moves are independent: the camera returns part coordinates; the controller then drives whichever TCP is active to the taught point. Swap a 180 mm gripper tip for a 120 mm camera tip on a taught move and every point shifts 60 mm along tool Z.

A move statement stores a Cartesian target for the tool named in that statement. Keep the target and change the tool, and the controller puts the new tip exactly on the old coordinates, dragging the whole flange with it (offsets along tool Z, tool pointing down):

Lateral offsets repeat the arithmetic sideways: a TCP2 recorded with a 25 mm X offset that TCP11 lacks lands every point 25 mm to the side, a constant side-miss that mimics a calibration error. Orientation adds the drama: reorientations and blends are computed for the active tool, so a move taught under one TCP executes a different joint path under another, and the wrist sweeps a new arc mid-move even though start and end coordinates are unchanged. That arc is the erratic look — the arm is obeying the point under the wrong tip.

Which TCP should each move after the locate use?

One tool for everything the camera does and one for everything the gripper does: snapshot, calibration and the locate run under the camera TCP; approach, grasp and retreat run under the gripper TCP. The dangerous statement is a move whose tool was edited after its point was taught.

The mapping is mechanical once written out:

Teach the camera tool once, as the optical center at the working focus distance, and then leave its numbers alone; Robot-held camera calibration with a TCP tool frame walks through building that frame properly. The one swap that must never happen is a tool change on a statement whose point was framed under the other tool — that single edit produces the 60 mm class of error from the worked example above.

How do you check the tool on every move after the locate?

Every move statement carries its own tool field, and that field is the whole diagnosis: open each statement from the locate to the grasp, read the tool, and compare it with the tool the point was taught under; the mismatch usually sits within two moves of the locate.

1. Open the program and read the tool the locate node declares; on a healthy cell that is the camera TCP.
2. Step through every move statement from the locate to the grasp and read the tool field in each. Flag any statement whose tool differs from its neighbors.
3. For each flagged statement, establish the tool that was active when the point was taught — the program comment, the pendant's teach history or the person who framed the point.
4. Touch-off test: command the arm to the taught point with the gripper tool active, at low override, and gauge the fingertip-to-part distance. A taught 5 mm clearance that gauges 65 mm is the 60 mm mismatch, measured in metal.
5. Fix the statement by setting its tool back, not by patching the point's coordinates. A coordinate patch hides the mismatch until the next tool edit moves it somewhere new.

Does editing a TCP shift the points you already taught?

Yes: stored coordinates fix where the TCP must go, so new offsets put that TCP somewhere new at every point that uses them. Lengthen a gripper TCP's Z from 175 mm to 185 mm and every grasp taught with it lands 10 mm deeper.

Two edits behave differently. Changing a tool's numbers — the 175 mm to 185 mm case — moves every point that uses it, by the change, along the tool axes. Changing which tool a statement uses is subtler on pendants whose waypoints store joint angles: the stored joints do not follow the new tool, so enable the statement's recalculate option where the TCP changes — the option is named Recalculate on some pendants — or the new tool is not taken into account at all.

A locate-node calibration update shifts waypoint meaning the same way, and the fix is to recalculate or re-teach the affected points rather than patch coordinates; Locate node calibration change: why waypoints move too shows how far those shifts reach. After any of these edits, re-gauge one taught point per tool before releasing the program to production speed.

When is the vision result actually at fault?

Rule vision in or out with one test: run the locate ten times on a part you have not moved and compare the returned X, Y and Z. A constant miss — same direction and magnitude every cycle — is a frame or TCP problem; scatter points at vision.

If the returned coordinates are stable but the pick misses by a constant vector, the fault is downstream of the camera: the tool fields from the sections above, or the hand-eye calibration itself — Camera mounted on the gripper: which tool-frame offsets actually work covers how those offsets behave. If the coordinates themselves scatter, work the causes in this order: a result consumed after the part moved, fixed by triggering a fresh measurement per pick (Vision result stale every cycle: trigger a fresh measurement per pick has the program pattern); a snapshot fired before the arm has settled back at the snapshot position (Camera locate snapshot position: why the robot must return first); a teach-time setup that differs from run time, classically streaming during teach and snapshotting at run (Vision locate works in teach but fails at run time: stream vs snapshot); and last, exposure or glare drift between cycles. Note that three of those four are trigger and program order, not image quality.

Which fault explains the symptom you are seeing?

Match the symptom's signature to the fault: a constant offset means tool or calibration, a new mid-move arc means orientation blended for the wrong tip, and scatter that changes every cycle means the vision side. The table turns each signature into the first check to run.

Two minutes with this table and the program editor settles most cases; the next section makes the fix permanent.

How do you stop the wrong TCP from coming back?

Make the tool assignment structural, not habitual: name tools by function, declare the tool inside or directly beside every move, and add one assertion before each pick that the active TCP is the gripper tool. Programs written this way survive the next engineer, the next edit and the next copy-paste.

Four conventions carry the fix:

• Name tools by function and offset — CAM_SNAP, GRIP_FINGERS — so a program reads wrong at a glance when the tool is wrong.
• Declare the tool in each move where the language allows; where only a global active tool exists, switch it immediately before the block that needs it, never inside a nested subroutine.
• Comment each taught point with the tool that framed it; a point without a tool note is a point waiting to be re-taught wrongly.
• Before each pick, assert the active TCP is the gripper tool and stop otherwise; one comparison line prevents the 60 mm class of crash outright.

Which hardware hands the locate result to the robot cleanly?

The mismatch lives in the program, not the camera, so any locate camera that returns a repeatable part frame does the job. On-device smart cameras keep locate, result flag and handoff in one unit; larger cells stream the part frame from a vision controller to the robot.

An on-device smart camera runs the locate where the trigger lives and hands the robot a part frame plus a result flag over Ethernet. The LS-SMC-0063 pairs a 1.6 MP sensor with a 16 mm lens at 60 fps. For tighter locates in color, the MV-SC3050XC-16M-ATN-H combines a 5 MP color sensor, a global shutter and an M12 mount on Fast Ethernet. Cells with several cameras centralize on a vision controller such as the MV-VC2140-128G40-1T, which brings four built-in light channels, 8 GB of memory, three to four LAN ports and two USB 3 ports for the camera and robot links. The TCP rule from this guide is identical whichever of the three produces the coordinates.

Decision, restated for both cases: if the arm moves wrong after a locate, check the active TCP on the following moves first and the vision job second. If you are rebuilding the locate hardware instead, the smart camera finder filters cameras by resolution and interface, contact reaches the applications team with your robot interface and cycle time, and more program-side fixes like this sit on the robot vision systems guides page.