ABB integrated vision with a third-party camera: your options

You have an IRB 1200 on an IRC5 controller and want to guide it with a camera that did not come from the robot maker's vision package. The direct answer: ABB Integrated Vision will not take it. The system is built around one supported smart-camera family — rebranded units carrying ABB-specific firmware — and a standard camera of that same family, or any other make, will not connect through RobotStudio's vision environment. That gate is firmware, not a setting you can change.

What you can do instead is run your camera in its own environment and hand the result to the robot yourself. Below: why the integrated path is closed, the three open architectures that work, what RAPID needs on its side, the coordinate transform into the robot base frame, and a worked lens and timing example for a fixed camera over a pick area.

Why Integrated Vision rejects cameras it does not know

Integrated Vision is a complete hardware-plus-software package: a smart-camera family with embedded image processing and an Ethernet interface, wired to the IRC5 controller and programmed from the RobotStudio vision environment. The supported cameras carry ABB article numbers DSQC1020 and DSQC1021. The gate is firmware. The Integrated Vision application manual lists camera firmware 4.08(22) as required and 4.10.2 as recommended, and the current camera firmware ships inside the RobotStudio installation. A camera without that ABB-specific firmware never appears in the vision environment, and there is no published conversion for a standard unit of the same camera family — let alone another make. Nothing you change in RobotStudio opens that door.

If you do run the supported cameras, the network side of that setup — ports, IP addresses and I/O to the IRC5 — is covered in ABB IRC5 integrated vision camera setup.

Three architectures that do work

Your camera never has to speak to Integrated Vision. It has to produce one result — part found, X, Y, angle — and deliver it to RAPID over the network. Three architectures do that:

Path A keeps the cell PC-free. On-camera image processing shows how much detection work fits on the device, and AI vs rule-based smart camera inspection settles the tool question before you buy. The LS-SMC-0063 is the shape of path A: a 1.6 MP smart camera with a 16 mm lens and its own white light, GigE on the wire.

Path B is the workhorse for multi-camera cells: camera ports, light channels and a licensed software stack in one fanless box. When a PLC sits in the loop as well, reading smart camera results over OPC UA is the alternative transport. The MV-VC3301H-128G66 fits here: a vision controller with 5+ LAN ports, 4 built-in light channels, 8 GB of memory and a VM6200Pro vision software license included.

Path C reuses what you already have. Standard GigE Vision cameras connect to any GenICam-capable stack — connecting a GenICam camera to an industrial controller over Ethernet covers discovery and wiring, and open source machine vision software the software tradeoffs. For scenes with motion, the 2.5 MP MV-CU020-90GC brings a global shutter on a C-mount.

What RAPID needs on its side

The socket path has two documented prerequisites: the IRC5 on RobotWare 5.13 or later, and the 616-1 PC Interface option in the controller. With those in place the flow is plain request-response. RAPID opens the connection, sends a trigger request with SocketSend, waits on SocketReceive for one line, parses the fields with RAPID string functions, transforms the coordinates and moves.

Keep the message boring on purpose: one ASCII line — part ID, X in mm, Y in mm, angle in degrees, pass flag — separated by semicolons, ended with a carriage return and line feed, exactly one line per trigger. A line that short parses in well under a millisecond, so exposure and detection own the timing, not the network.

Two rules make the link dependable. Set a receive timeout and an error routine, so a dead camera stops the cycle with a diagnosable fault instead of freezing the program — GigE camera disconnected detection makes the case. And decide who triggers: RAPID request-response for a stationary scene, or a PLC hardware trigger with the result pushed — vision picking request timing shows how to overlap that exchange with robot motion. The full handoff, field by field, is in send camera part coordinates to a robot controller over TCP, and vision controller to PLC TCP ports and firewall rules covers what must be open when a controller or firewall sits in between.

From camera pixels to the robot base frame

A fixed camera over a flat presentation surface needs a 2D calibration: a scale in mm per pixel, one rotation angle and an offset, taught with a dot grid or by touching points with the robot tool. Pixel X and Y almost never align with robot base X and Y. Mount the camera square to the tray edge and the rotation shrinks to a few degrees — measure it anyway, and never assume zero. Fixing rotated camera axes in RAPID walks that exact correction through a vision-guided cell, and the same math applies to your own pipeline.

If the camera rides on the gripper, calibration becomes a tool-frame problem: robot-held camera calibration with a TCP tool frame covers the eye-in-hand case. The full sequence — trigger, result, approach, grip — is laid out in 2D vision guided robot pick place grip: how the cycle works.

Worked example: a 20 MP camera over a 300 × 225 mm pick area

The inputs, and where each comes from:

• Pick area: 300 mm × 225 mm — a presentation tray in front of the robot, the typical fixed-camera case for a small cell.
• Working distance: 450 mm — the stand height the cell allows above the tray.
• Camera: a 20 MP model on a 1-inch sensor — 5472 × 3648 pixels at 2.4 µm, which works out to 13.1 mm × 8.8 mm of active area.
• Parts: stationary at the trigger moment, height within ±10 mm.

The rule in words: magnification is sensor width over field-of-view width, focal length follows from working distance and magnification, and depth of field follows from the blur budget.

The arithmetic, step by step:

1. Magnification: m = 13.1 mm / 300 mm = 0.0437.
2. Focal length: f = 450 mm × 0.0437 / 1.0437 = 18.8 mm.
3. 18.8 mm is not a standard C-mount focal length. The nearest shorter one, 16 mm, keeps the whole tray in frame: m = 16 / (450 - 16) = 0.0369, so FOV = 13.1 × 434 / 16 = 355 mm wide and 8.8 × 434 / 16 = 238 mm high — an 18% margin over 300 mm in width, and the 225 mm height fits with room to spare.
4. Sampling: 5472 px / 355 mm = 15.4 px/mm, so one pixel spans 0.065 mm. A 2 mm feature covers 31 px, and a centroid good to 0.1 px places the part to 0.0065 mm — far below the mechanical repeatability of a small six-axis robot, so the vision side will not be the accuracy limiter.
5. Aperture: with the acceptable blur circle at two pixels (c = 0.0048 mm), DOF ≈ 2 × 0.0048 × N × 1.037 / 0.0369² = 7.3 × N mm. At f/4 that is ±15 mm, and the ±10 mm part spread fits inside it. At f/8 it is ±29 mm — stop down only if presentation height varies that much, and pay for it in light.
6. Exposure: parts are static, so 5 ms with a white area light is the starting point. If the tray indexes under the camera, cap blur at one pixel: 0.065 mm / 100 mm/s = 0.65 ms — strobe or overdrive territory.

The decision: order the 16 mm C-mount lens; run f/4 on a flat tray, f/8 for ±30 mm height spread; lock exposure at 5 ms; and book 50 ms in the cycle plan for exposure plus detection until you measure the true figure on the hardware. If the tray ever grows past 350 mm, fit a 12 mm lens rather than raising the camera.

The camera behind these numbers is the MV-CS200-10GC: 20 MP, GigE, a 1-inch IMX183 sensor and a C-mount.

Run your own tray size and mounting height through the same calculation before ordering the lens:

Checks before you order anything

• RobotWare 5.13 or later and the 616-1 PC Interface option confirmed on the IRC5; without them the socket path does not exist.
• Going integrated after all: article numbers DSQC1020 or DSQC1021, camera firmware 4.08(22) minimum and 4.10.2 recommended, with the RobotStudio vision plugin on a matching version.
• One switch or VLAN for camera, vision controller and robot controller; if a second camera may join later, two GigE cameras on one host sizes the ports and bandwidth.
• Lens field of view at least 15% larger than the tray on both axes, and at least 20 pixels across the smallest feature you must find.
• Exposure and gain locked after commissioning, not left on auto — feedback between auto exposure and detection is a known instability, explained in auto exposure ROI instability.
• A receive timeout and an error routine in RAPID, so a lost camera faults the cycle instead of hanging it.
• A vision result is not a safety signal: interlock the cell so nobody reaches the pick area while the robot moves.

When the supported camera is still the right answer

Buy DSQC1020 or DSQC1021 when the plant standard is RobotStudio-only engineering, when your team already works inside the integrated vision environment, and when one support chain covering robot and camera is worth more than sensor choice. For a first vision-guided cell, the integrated package commissions faster.

It stops being the right answer the moment you need a sensor or resolution it does not offer, a second viewpoint, image archiving or AI models you retrain yourself. The socket path does all four, with the same coordinate transform and the same robot accuracy, because the handoff work is identical either way. Start with smart cameras and area scan cameras, size the whole cell in the system configurator, or filter by sensor and mount in the camera finder. For a recommendation matched to your cell, use the contact page.