Resolving Pick Point Variation in Vision-Guided Robot Systems

Problem Overview

A vision-guided robot (VGR) cell is expected to deliver repeatable pick accuracy in the sub-millimetre range once the camera-to-robot transform is locked in. When a 5-10 mm scatter suddenly appears on the pick point, with no corresponding change in the camera's reported detection coordinates, the symptom is almost always in the mechanical or kinematic chain between the camera-reported pixel and the TCP (Tool Centre Point) of the gripper - not in the vision system itself. This reference documents a real field case built around an Omron FH-series vision controller paired with an FZ camera, an Omron AnyFeeder SY-series bulk parts feeder, a Yaskawa Motoman MotoMini (DX200 controller) robot, and a Siemens S7-1200 PLC acting as the data hub. The cell reported stable camera detection but a 5-10 mm pick-point scatter, including a 'miss-pick-then-pick' on the same reported coordinates. The root cause was traced to factory axis calibration of the B (wrist bend) and R (wrist rotation) axes of the MotoMini, corrected by re-mastering and resetting the work home position. This article expands that resolution into a generalised field troubleshooting workflow for any VGR integrator working with similar architectures. Typical target KPIs that this workflow protects:

• Pick repeatability: better than ±0.5 mm at the TCP across 50+ cycles
• Cycle time: under 3.6 s (operator baseline) for the full feed-pick-place cycle
• Miss rate: under 0.1 % (one in 1 000 picks)
• Vision-to-robot communication latency: under 80 ms end-to-end

System Architecture

The reference cell uses a four-subsystem VGR topology that is common to most high-mix low-volume assembly cells. The dataflow must be understood in full before any troubleshooting can begin, because every data path is a candidate failure mode.

Subsystem Responsibilities

Subsystem	Model	Responsibility	Key Interface
Vision controller	Omron FH-1050 / FH-2050	Image acquisition, edge/pattern detection, mm output	EtherNet/IP or RS-232 to PLC
Vision camera	Omron FZ-SC / FZ-S series	Captures part on AnyFeeder bed	Camera link to FH
Parts feeder	Omron AnyFeeder SY3000/SY5000	Bulk singulation, dispense, feed forward/reverse	ASCII serial from PLC
Robot	Yaskawa Motoman MotoMini (DX200)	Pick from feeder, place to downstream	EtherNet/IP (standard) or ProfiNet option board
Master controller	Siemens S7-1214C DC/DC/DC	Trigger camera, scale pixels→mm, hand off to robot	EtherNet/IP, RS-232 ASCII

The vision system outputs the location of the candidate part in millimetres, having already done the pixel-to-world conversion on the FH controller. The PLC is the data hub; it does not modify the values, it simply re-formats and forwards them. The robot applies the final user-frame-to-base-frame transform and executes the move. This separation is critical: if a fault is in any one of these layers, isolating it requires understanding where the value is being transformed.

Camera-to-Robot Calibration Methodology

The pixel-to-mm conversion factor in this cell was generated empirically with a four-point method. The integrator used a printed grid placed under the camera at the feeder bed, identified the pixel coordinates of two reference points (500,500 px and 1500,1500 px), drove the robot to each point, recorded the resulting TCP coordinates, and computed a single mm-per-pixel scale factor on each axis. The same scale factor was used to validate the result by commanding a 50 mm offset from the camera centre and confirming the robot landed exactly 50 mm away.

Hand-calculated scale factors

The general formula for an axis-aligned VGR scale factor:

Sx (mm/px) = (Rx2 - Rx1) / (Px2 - Px1)
Sy (mm/px) = (Ry2 - Ry1) / (Py2 - Py1)

Where:

• Px1, Py1, Px2, Py2 are pixel coordinates of two known reference points in the camera image
• Rx1, Ry1, Rx2, Ry2 are the corresponding robot TCP coordinates in world frame (mm)

The Omron FH applies a similar internal transform in the calibration scene; see the FH Vision System User's Manual (Cat. No. Z365) for the camera calibration scene parameters. The user-frame approach used in this cell - where the camera and the robot base are parallel and the scale factor is hard-coded - works well for planar pick surfaces but is sensitive to any mechanical drift in camera mounting or feeder height. A user frame at the robot that matches the camera origin is the recommended long-term fix to decouple these two.

Diagnosing Pick Point Variation

The diagnostic workflow below was followed in the field and is generalised so it can be applied to any VGR cell reporting the same symptom.

Step 1 - Confirm the camera output is stable

Watch the FH scene's measured XY and θ across 30+ cycles on a stationary part. If the camera reports the same value to within the resolution of its floating-point output (typically 0.01 mm), the vision chain is not the source of variation. In this case, the camera output was confirmed stable and the integrator verified that the values reaching the robot (echoed back via the PLC's holding registers) matched the camera output bit-for-bit.

Step 2 - Confirm the data path is lossless

Three points of failure to check:

1. Integer truncation in the PLC: a 32-bit REAL scaled to a 16-bit INT loses 0.001 mm at full scale, but a 16-bit INT with the wrong byte order can shift the decimal point by orders of magnitude. Always use REAL/DINT across the EtherNet/IP assembly.
2. Sign or scaling mismatch in the robot: the Motoman DX200 reads positions in 0.001 mm/pulse for linear axes. A 1000x scale error in the scaling block will be invisible at the data-display layer but catastrophic at the motion layer.
3. Endianness: the Omron FH uses little-endian on EtherNet/IP; the Siemens S7 uses big-endian on ProfiNet. The DX200 expects big-endian on the standard option board. If a swap card is used, verify it.

Step 3 - Eliminate mechanical causes

A 5-10 mm scatter that is random across all positions and all angles - not biased by location or orientation - is a strong indicator of a master/zero issue on a wrist axis. The wrist axes (B and R on the Motoman MotoMini) are the most common source because they are mastered at the factory using fixture-based absolute encoders, and any small fixture error compounds into a large TCP error at the end of the kinematic chain. A simple test: command the robot to move the same pick point 20 times in a row using a fresh image for each move. If the scatter is large, the mechanical chain is the most likely culprit. If the scatter is small, the motion-execution layer (IMOV, blend, deceleration) is suspect.

Troubleshooting Matrix

Symptom	Most Likely Layer	Specific Test	Fix
Consistent offset in one axis only	Pixel-to-mm scale	Re-measure 4-point calibration	Update Sx/Sy in FH calibration scene
Offset proportional to distance from origin	Robot user frame or scale	Verify user frame origin matches camera origin	Set/reset user frame at camera centre
Random 5-10 mm scatter across all positions	Wrist axis mastering (B, R)	Master B and R per Motoman procedure	Master B/R, reset work home position
Miss-then-pick on same reported XY	Kinematic or motion-execution	Check IMOV sequencing, check for missed approach height	Add explicit Z pre-position, single-shot IMOV
Out only at extreme angles (θ near ±180°)	Theta resolution or sign convention	Plot reported θ vs measured θ	Verify FH outputs degrees vs radians, sign convention
Out only on first pick after homing	Absolute encoder drift or cold start	Add absolute-encoder confirmation read in PLC	Hold first pick until encoder status OK
Consistent +N mm offset on the first cycle only	Image acquired before parts settled on AnyFeeder	Add 200-300 ms settle delay after dispense	Lengthen interlock timer in PLC

Root Cause Analysis: Robot Axis Mastering

The Yaskawa service engineer who visited the cell identified that the B (wrist bend) and R (wrist rotation) axes of the Motoman MotoMini were not mastered correctly at the factory. This is a known field concern for new MotoMini units and any MotoMini that has been transported with the wrist unlocked.

Why B and R matter disproportionately

On the Motoman MotoMini (4-axis SCARA variant with a parallel-jaw gripper), the kinematic chain from base to TCP is:

TCP = T_base→S * T_S→L * T_L→U * T_U→B * T_B→R * T_R→TCP

Where S, L, U, B, R are the rotation/translation transforms for each axis. A 1° error in the master zero of the B axis propagates linearly into a position error at the TCP. The arm length from the B-axis output flange to the TCP on a MotoMini is approximately 100 mm. Therefore a 0.057° master error on B produces a 0.1 mm TCP error, and a 0.57° error produces 1 mm. A factory-scale 3° error - plausible if the wrist fixture was off-centre at mastering - produces a 5 mm TCP error, exactly the symptom observed. The R axis (wrist roll) is even more sensitive to the gripper being off-axis: a 3° R error at a 50 mm offset from the wrist centre produces a position error of:

Δ = 2 * 50 * sin(3°/2) = 2.6 mm per side, or ~1.3 mm at the gripper fingertips

This explains why the original cell saw the variation more strongly when the part was off-centre in the gripper approach (i.e. when the AnyFeeder dispensed parts to the edge of the bed).

Yaskawa Master and Work Home Procedure (DX200)

The procedure below is the Yaskawa-recommended sequence. Always refer to the DX200 Operator's Manual (Part No. RE-CKI-A203) for the latest safety interlocks before performing any mastering operation. Do not master with the tool attached unless the procedure explicitly requires it.

1. From the teach pendant, navigate to SETUP → FUNCTION ENABLE → MASTER → B AXIS. Confirm the controller is in ENABLE mode for the B axis only.
2. Use the manual jog to align the B-axis alignment mark per the MotoMini mechanical drawing (the B-axis alignment is typically a scribe line on the wrist housing).
3. Set the master count: DATA → MASTER → B AXIS and enter the value from the MotoMini nameplate (typically 0 ± 0 pulses for a fresh unit; this is what was wrong in the field case).
4. Repeat for the R axis: DATA → MASTER → R AXIS. The R axis master value for a MotoMini is normally 0 ± 0 pulses.
5. Power-cycle the controller. On reboot, navigate to SETUP → WORK HOME POSITION and re-teach the work home position to the camera origin (the 0,0 reference used by the FH mm output).
6. Run the four-point pick validation: pick a stationary jig at each of the four calibration points, measuring the actual pick with calipers or a dial indicator. The residual must be under 0.5 mm at all four points before continuing.

Robot Move Type Considerations (IMOV vs MOVL)

The integrator used IMOV (Incremental Move) commands on position variables P000, P001, and P002 to perform the approach, descend, and retract motions. IMOV is a relative move command on the Motoman DX200/MotoMini and is implemented in INFORM as:

IMOV P000 V=50.0 PL=0
IMOV P001 V=10.0 PL=0
IMOV P002 V=80.0 PL=0

Where P000 carries the X/Y/θ from the camera, P001 carries the Z descent, and P002 carries the Z retract. Because the integrator always returned to a fixed 0,0 staging point before issuing the IMOV, each pick was repeatable in principle. The actual pick error in the field case was not in the IMOV arithmetic but in the underlying mastered zero of B and R.

When IMOV is the right choice

• Pick from a moving conveyor with a vision-derived offset (relative-to-current-position)
• Stacked picks from a feeder where the next pick point is computed incrementally from the previous
• Calibrated offsets where the absolute target is unreachable in a single MOVL but the relative offset is small

When MOVL/MOVJ is the right choice

• Absolute pick from a known camera origin (the integrator should switch to MOVL once B/R mastering is correct)
• Place operations where the target is a fixed downstream fixture
• Anywhere a user frame is in use (IMOV bypasses user-frame awareness in some MotoMini firmware revisions)

The recommended refactor after mastering correction is:

; Refactor suggestion for the MotoMini INFORM job
; Pre-condition: Work home position is the camera origin
; P010 = camera X, P011 = camera Y, P012 = camera theta (Rz)
; Pre-position 50 mm above the part
SET B000 P010
ADD B000 P011  ; combine X+Y into a single base-offset pulse set
MOVL P000 V=200.0 PL=2   ; approach at 200 mm/s, position-level blend 2
MOVL P001 V=20.0 PL=0    ; descend at 20 mm/s, no blend
DOUT OT#(10) ON          ; gripper close
TIMER T=0.1              ; 100 ms settle
MOVL P002 V=80.0 PL=0    ; retract at 80 mm/s

This refactor replaces the three IMOV calls with explicit absolute MOVL calls, removing the relative-move ambiguity entirely. It also adds a 100 ms gripper-close settle to ensure the part is captured before retract, which is the second-most-common cause of intermittent pick failure in VGR cells.

Handshaking and Triggering

A VGR cell only works when the trigger flow is deterministic. The reference cell used a handshake pattern with the following sequence:

Siemens S7-1200 Register Map (TIA Portal)

Symbol	Address	Type	Direction	Purpose
VH_CAM_TRIG	%Q0.0	BOOL	PLC → FH	Image trigger pulse (50 ms)
VH_CAM_RDY	%I0.0	BOOL	FH → PLC	Data valid flag
VH_CAM_X	%ID100	REAL	FH → PLC	Part X (mm)
VH_CAM_Y	%ID104	REAL	FH → PLC	Part Y (mm)
VH_CAM_TH	%ID108	REAL	FH → PLC	Part θ (deg)
VH_RBT_X	%QD200	REAL	PLC → DX200	Robot X target (mm)
VH_RBT_Y	%QD204	REAL	PLC → DX200	Robot Y target (mm)
VH_RBT_TH	%QD208	REAL	PLC → DX200	Robot Rz target (deg)
VH_RBT_REQ	%Q0.1	BOOL	PLC → DX200	Pick request
VH_RBT_DONE	%I0.1	BOOL	DX200 → PLC	Pick complete
VH_RBT_ERR	%IW10	INT	DX200 → PLC	DX200 error code

Watchdog pattern for the data handshake

In TIA Portal, the recommended interlock is a 200 ms watchdog on VH_CAM_RDY after the trigger edge, plus a 2 000 ms watchdog on VH_RBT_DONE after VH_RBT_REQ. Either watchdog tripping should latch a fault and stop the cycle. The handshake must be strictly edge-triggered, never level-triggered, to avoid the 'stale image' failure mode where the robot re-acts on a previous cycle's coordinates.

// SCL example: trigger-and-wait for camera data
IF "FEEDER_DONE" AND NOT "CAM_BUSY" THEN
    "CAM_BUSY" := TRUE;
    "VH_CAM_TRIG" := TRUE;     // 50 ms pulse via TON
    TON_DB("TRIG_PULSE", IN := TRUE, PT := T#50ms);
END_IF;

IF "TRIG_PULSE".Q THEN
    "VH_CAM_TRIG" := FALSE;
    "CAM_WATCHDOG".TON(IN := TRUE, PT := T#200ms);
END_IF;

IF "VH_CAM_RDY" THEN
    "CAM_BUSY" := FALSE;
    // Forward to robot registers - copy verbatim, no scaling
    "VH_RBT_X" := "VH_CAM_X";
    "VH_RBT_Y" := "VH_CAM_Y";
    "VH_RBT_TH" := "VH_CAM_TH";
    "VH_RBT_REQ" := TRUE;
END_IF;

The data path is single-shot. Each trigger generates exactly one image, the FH returns one data packet, the PLC forwards it once, and the robot executes one pick. There is no batching or re-trigger, which means a 'stale image' failure cannot occur. The integrator in the field case confirmed the data matched at every leg, so the data path was eliminated as a fault source.

AnyFeeder Integration Notes

The Omron AnyFeeder SY-series is a flexible feeder that uses a parallel-linkage singulation mechanism driven by a stepper. The PLC controlled the feeder via ASCII serial commands. The integrator discovered that the ASCII command set must be re-loaded on every power-up - the AnyFeeder does not retain its programmed command set across a power cycle, unlike most modern feeders. This is documented in the Omron AnyFeeder SY Series User's Manual and is a known field quirk; the integrator's solution was a 'reload ASCII' button in the HMI that must be pressed after every cold start.

AnyFeeder ASCII command set (excerpt)

Command	Syntax	Function
Dispense	DISP,1,1\r\n	Singulate one part to pick position
Feed forward	FFWD,100\r\n	Move bed 100 steps forward
Feed reverse	FREV,100\r\n	Move bed 100 steps reverse
Stop	STOP\r\n	Immediate stop
Status	STATUS\r\n	Return ready/busy/error state

The dispense-to-pick delay must be tuned. The integrator used approximately 300 ms after the dispense command before triggering the camera. Under 200 ms, parts were still settling on the bed and the FH reported a 1-2 mm biased offset on the first pick after a long pause. Over 500 ms, the cycle time budget was blown. The 300 ms value is field-tested for the SY5000 with a typical 30 g part.

Resolution and Verification

The fix sequence in the field case was:

1. Yaskawa service engineer re-mastered the B and R axes of the Motoman MotoMini at the work home position.
2. The work home position was re-taught to the camera origin (the 0,0 of the FH mm output).
3. A 4-point validation was run; the residuals were under 0.3 mm at all four points (down from 5-10 mm before).
4. 50 consecutive picks were run on a stationary jig; the pick repeatability was measured at ±0.4 mm at the TCP.
5. The full cycle was run for 500 cycles; the miss rate dropped to 0 (from approximately 8 % before).

Verification matrix

Test	Acceptance	Tool	Pass criterion
Static 4-point pick	≤ 0.5 mm residual at each point	Dial indicator on TCP	All four ≤ 0.5 mm
Dynamic repeatability (50 cycles)	≤ 0.5 mm TCP scatter	Vision system overlay	σ ≤ 0.25 mm
500-cycle soak	0 misses	Cycle counter + reject bin	0 misses
Cycle time	≤ 3.6 s	PLC timer	Mean ≤ 3.4 s
Camera-robot data echo	Identical values at both ends	PLC HMI display	X match to 0.01 mm, θ to 0.01°

Preventive Maintenance and Field Hardening

Once the cell is stable, the following hardening steps prevent recurrence:

• Lock the wrist transport fixture: ensure the B and R axes of the MotoMini are mechanically locked whenever the robot is transported. The factory mastering is only valid as long as the wrist hasn't moved in transit.
• Add a mastering check at cold start: in the DX200, DATA → MASTER COUNT should be read at every cold start and compared to the nameplate value. Any deviation greater than 100 pulses should raise an HMI warning.
• Daily camera re-calibration: re-run the FH calibration scene on a daily basis, or whenever the feeder is cleaned. The Omron FH Vision System supports an auto-calibration scene that the integrator can trigger from the PLC.
• AnyFeeder ASCII reload: keep the 'reload ASCII' HMI button as a standard cold-start step, and add a confirmation prompt that the operator cannot skip.
• Watchdog alarms: the two watchdogs described in the handshake section should be wired to the HMI alarm log with timestamped entries so any cycle that timed out can be reviewed.
• Tool Centre Point (TCP) re-teach quarterly: the TCP is set per the gripper manufacturer and must be re-taught if the gripper is removed for maintenance. On the DX200, this is SETUP → TOOL → TCP.

References and Standards

The following manufacturer documentation and standards are the authoritative source for the procedures described above. Always verify against the current revision before performing any mastering or commissioning operation.

• Omron FH Vision System User's Manual (Cat. No. Z365)
• Yaskawa Motoman DX200 Operator's Manual (Part No. RE-CKI-A203)
• Yaskawa Motoman MotoMini Mechanical Drawing (DX200-MAN-MotoMini)
• Omron AnyFeeder SY Series User's Manual (Cat. No. I569)
• Siemens S7-1200 Programmable Controller System Manual (Entry ID: 109759320)

For background on VGR architectures and applications, see the Vision-guided robot systems reference, the Cognex VGR application note, the Keyence VGR industry page, and the ResearchGate survey on vision-guided robot gripping systems.

FAQ