PC-based robot vision guidance with a GigE Vision camera

You want a robot to pick parts a camera locates, the maker's integrated vision option stretches the budget, and the question becomes: can an ordinary camera, even a webcam, plug straight into the controller? Direct answer: no for a direct connection, yes with a PC in the middle. This guide gives you the architecture that works, the cycle-time arithmetic, a camera and lens worked example at 600 mm working distance, and the handshake that hands X, Y and rotation to the robot program. It is written for the engineer building a first vision-guided cell around an R-30iA-class controller with standard machine-vision parts.

What the controller accepts, and what it refuses

An R-30iA or R-30iB controller recognizes cameras only through its own licensed vision option (iRVision on FANUC controllers), and that option supports a fixed list of GigE models. There is no generic USB camera input: the ports on the controller and pendant exist for memory sticks and peripherals, not video. A third-party GigE Vision camera is not enumerated by the integrated option either, because the option checks its supported-camera list at startup. Wiring a camera straight to that controller therefore means buying a supported model plus the vision license — which is the integrated option itself, priced per controller. For how that path works on a current controller, see configuring a GigE camera on a FANUC CRX robot. The refusal to talk to standard cameras is a licensing and calibration model, not a protocol gap a cable can bridge.

The architecture that works

Put a PC — or better, a fanless vision controller — between camera and robot. The chain has four blocks:

1. A GigE Vision camera over the pick point, hardware-triggered.
2. The PC acquires through GenICam and runs your locating tool: template match, blob analysis or edge fitting.
3. The pixel result converts to millimetres and then into the robot's user frame.
4. The result travels to the robot over TCP, digital I/O or fieldbus; the robot applies it as a frame offset and picks.

The robot starts every cycle with a ready pulse; the PC answers with one result and a rolling sequence number. Nothing else flows between them.

Cycle time: where the milliseconds go

Start with the link, because it dominates. A 1000BASE-T connection moves about 105 MB/s of image payload after protocol overhead (125 MB/s line rate minus headers and inter-frame gaps). A 6 MP mono frame is 6.2 MB of 8-bit pixels, so transfer alone is 6.2 / 105 ≈ 59 ms. A 2.5 MP frame is 2.5 MB, about 24 ms. Cropping to the search ROI cuts that in proportion: search half the frame and you move 3.1 MB.

Processing adds 10-50 ms for a template match or blob on a current x86 core. The result message is 20-30 bytes over a LAN socket, a 1-5 ms round trip; a fieldbus or digital-I/O scan stays under 10 ms. Add it up for a stationary part: 8 + 59 + 25 + 5 ≈ 97 ms. Plan 150 ms in the robot sequence for a 6 MP camera, and 80 ms for a 2.5 MP camera or a halved ROI. For everything the robot side adds to the loop, read image based control latency: budget the full feedback loop.

Choosing the camera

Three choices drive the camera: interface, shutter, resolution. Take GigE over USB3 whenever the camera mounts on a cell frame — one cable with Power over Ethernet, 100 m reach, and the trigger traffic stays on one switch. Take mono over color: color triples the bytes and adds demosaicing for no locating accuracy. Take a global shutter if the part moves when you grab; a rolling shutter is fine when the part rests in a fixture.

For resolution, aim at 0.1 mm per pixel or finer on small parts, and give the smallest feature you locate at least three pixels. A 350 mm field then needs about 3,500 pixels across, which a 6 MP sensor supplies with margin. The industrial camera specifications buyer's guide covers sensor formats and interfaces in depth; browse area scan cameras with the mount and shutter filters in the camera finder.

For a stopped-part cell, the workhorse pick is a 6 MP mono GigE camera with C-mount:

The MV-CU020-90GC is the moving-part alternative: 2.5 MP, global shutter, GigE and C-mount. Its frames also clear the link in about a quarter of the time of a 6 MP image, which matters once the cell runs fast.

Where the software runs

The processing box decides how the cell ages. An office PC works on a bench; on the floor, take a fanless vision controller — terminal-block power, no fans to clog, and light channels with strobe output built in, so the camera trigger and the light pulse come from the box you program.

The MV-VC3301H-128G66 pairs a Core i3-8100 with 8 GB of RAM, five or more LAN ports, four built-in light channels and an included VM6200Pro vision-suite license, so the software ships with the box instead of becoming a separate hunt. The MV-VC2140-128G40-1T is the smaller cell box: an Intel N-series processor, 8 GB of RAM and the same four built-in light channels for one camera.

Whichever box runs it, the camera side is plain GenICam. The IP addressing, packet-size and firewall settings that bite first are covered in connect a GenICam camera to an industrial controller over Ethernet. A webcam frames into the same libraries, but it has no hardware trigger, no strobe sync and a lens that drifts — leave it on the bench.

Worked example: bracket picking at 600 mm

The part is a 120 mm steel bracket presented in a 300 × 200 mm fixture window, position scattered ±20 mm, rotation ±15°. The camera looks straight down from 600 mm on a rigid stand.

Sensor first. A 6 MP sensor in the 1/1.8-inch format is about 3100 × 2060 pixels on a 2.4 µm pitch, so its active area is 3100 × 0.0024 ≈ 7.4 mm by 2060 × 0.0024 ≈ 5.0 mm. Cover the window with 20% margin: plan a field of about 360 × 240 mm. Then:

m = 7.4 / 360 = 0.021, and f = 600 × 0.021 / 1.021 = 12.1 mm — fit a 12 mm C-mount lens, the standard size just under the computed value.

Check it: at 600 mm the 12 mm lens gives m = 12 / 588 = 0.0204, so the field is 7.4 / 0.0204 = 363 mm wide and 5.0 / 0.0204 = 245 mm high — margin on both axes. One pixel is 363 / 3100 = 0.117 mm, and the 120 mm bracket spans about 1,030 pixels. A centroid fitted to 0.2 px locates it to 0.2 × 0.117 = 0.023 mm. Two features 80 mm apart fix the angle to 2 × 0.023 / 80 = 0.0006 rad ≈ 0.03°, finer than the robot's own path accuracy, which is ±0.02-0.05 mm repeatability on a mid-size six-axis.

Exposure and depth of field: the part is stationary at handshake, so 8 ms at f/4 under a diffused ring light is plenty. Depth of field at f/4 with a two-pixel circle of confusion (0.23 mm on the object) is 2 × 4 × 0.0048 × (1 + 0.0204) / 0.0204² ≈ 95 mm total, so brackets sitting ±10 mm high stay sharp. If the part ever runs past at 200 mm/s, motion blur is 200 × t; keeping it under one pixel caps exposure at 0.117 / 200 ≈ 0.6 ms, so strobe a 200 µs pulse — that leaves 0.04 mm of blur, a third of a pixel.

The cycle: 8 ms exposure + 59 ms transfer (6.2 MB at 105 MB/s) + 20 ms template match + 3 ms socket write = 90 ms per part. Budget 150 ms; the robot's approach moves cost far more than the vision step. Run your own numbers in the lens focal length calculator or the calculator below.

Mount the camera on a stand from camera stands, bolted to the cell frame and never to the robot — arm vibration becomes blur at exactly 0.117 mm per pixel. If a cell ever shows slow image drift, detecting camera vibration with OpenCV frame tracking tells you whether the stand or the floor is at fault.

Sending the result to the robot

Three channels, one recommendation. Digital I/O wins for a fixed result: wire the PC's output card or the vision controller's outputs to group inputs, send X and Y as 32-bit counts in 0.01 mm and angle in 0.01°, toggle a data-valid bit per result, and the robot latches on the edge. A TCP socket wins when the record varies — about 30 bytes of ASCII, X+012.40 Y-003.10 R+002.50 — because part IDs, error codes and second candidates ride the same stream; the robot-side program listens while the PC connects. EtherNet/IP or Modbus/TCP earns its keep only when a PLC already owns the cell network: see vision controller Modbus communication with a PLC and GenICam camera on a PLC controller for that wiring.

Whatever carries it, send the result as an offset in a taught user frame, never as absolute joint data — handling user-frame offsets in FANUC vision guidance is the pattern the robot program expects. Hold the handshake discipline: robot requests, PC answers once per request with a sequence number, 500 ms timeout, and on timeout the robot returns home instead of picking on stale data. Vision project start stop handshake troubleshooting covers the failure modes when the two sides disagree, and collaborative robot vision inspection: plan a reliable cycle sizes the full inspection beat.

Calibration and the accuracy budget

Calibrate with the robot itself when you can. Teach a user frame on the fixture plate, jog the tool point onto a 3 × 3 grid of scribed crosses, and record the pixel reading at each. Nine points fit the pixel-to-frame map; residuals should land under 0.5 px — 0.06 mm at this scale. Larger residuals point to lens distortion or a fixture that moves between shots. To turn that map into base-frame picks, follow use eye-to-hand calibration results to compute robot-base picks; after a week of production, eye-to-hand calibration: verify the camera-to-base result shows what drifted and by how much.

The budget, honestly: vision locating 0.023 mm, calibration residual 0.06 mm, robot repeatability 0.05 mm. Root-sum-square gives √(0.023² + 0.06² + 0.05²) ≈ 0.08 mm end to end. A gripper that clears the part by ±0.5 mm never notices. When you need tighter, the fix is a stiffer stand and a better calibration grid, not more megapixels.

When the maker's integrated vision option is the better buy

Say it plainly: the integrated option saves setup time, and that is a real cost. Buy it when any of these hold — the cell must pick within a week and nobody on staff has written image-processing code; you need line tracking, where the robot follows a moving conveyor off its own encoder input and rebuilding that timing PC-side is weeks of work; or the task is 3D bin picking, where an integrated 3D sensor and solver beat a home-built pipeline. Otherwise the PC-based chain wins on camera freedom, one calibration method reused across every cell, and no per-controller vision license. The two also mix: many cells run the integrated option for tracking and a PC camera for inspection.

Checks before you order

• Controller options: socket messaging or the fieldbus card on the robot, plus a spare LAN port and PoE budget on the switch.
• Roles fixed before code: who is socket client, who is server, and the record format on both sides.
• Lens margin: computed focal length rounds down to the standard size, and the field keeps 15-20% margin on both axes.
• Light before software: a diffused, strobe-capable light solves more locating problems than an extra megapixel.
• Trigger wiring: camera hardware trigger and strobe pulse driven from the same box, so exposure and light never drift apart.
• Stand rigidity: camera on the cell frame, not the arm; check floor vibration if the cell shares a slab with presses.
• Calibration artefact: a 3 × 3 target grid you can re-datum after any collision.
• Safety unchanged: curtains and interlocks stay on the robot controller; vision only positions parts.

When the parts list is settled, run it through the system configurator to check camera, lens and light against one another, or send the cell drawing through the contact page and we will size it with you. In-stock items ship within one business day, so the longest lead item is usually your first calibration grid.