Machine vision connectivity standards: what each one does

Two stations can look identical on the purchase order and behave completely differently on the line. One was specified around standards, the other around a datasheet page. This guide maps the standards a machine vision buyer meets — Camera Link, CoaXPress, GigE Vision, USB3 Vision and 10GigE Vision for transport, GenICam for camera control, EMVA 1288 for sensor characterization, OPC UA Vision for results — onto the decisions that follow from them. Which transport to buy, how the light controller is told to fire, and how inspection results reach the PLC or MES. Every section carries the numbers and the rule they decide, and the last is a ten-minute compatibility check for the whole parts list.

Which machine vision standards actually matter when you buy a camera?

Five transport standards carry camera data — Camera Link, Camera Link HS, CoaXPress, GigE Vision and USB3 Vision — and the 10GigE Vision extension pushes GigE Vision past 10 Gbit/s; GenICam above them controls every camera, and OPC UA Vision reports results.

The five transports are developed and maintained at the international vision standards meetings, held twice a year. There, camera, lighting, cable and software companies connect each other's devices on a common bench and fix what fails. That interoperability is tested, not assumed, which is why a GenICam-compliant camera from one maker runs under acquisition software written by another.

On top of the transports sit two software layers. GenICam defines how every modern camera is controlled, and OPC UA Vision defines how a complete vision system — one camera or forty — reports to plant software. EMVA 1288 rounds out the set. It standardizes sensor characterization rather than connectivity, but it is the reason two cameras of equal resolution can differ in dynamic range by a wide margin and still say so with comparable numbers.

The rule for a new build: specify GenICam-based transports — GigE Vision, USB3 Vision or CoaXPress — and reserve Camera Link for lines that already own the frame grabbers. Browse what that rule selects in the area scan cameras category, where interface, shutter and resolution filters sort the catalog the same way this guide does.

What does GenICam control that the cable does not?

GenICam turns every camera feature into a named node described in an XML file that ships on the device. Any GenICam-aware software reads ExposureTime, Gain and AcquisitionFrameRate the same way from any brand. The transport standard's job is to carry that XML and the pixels — nothing more.

Three parts make that work. GenApi parses the XML device description that lives on the camera itself. SFNC, the Standard Features Naming Convention, fixes what the nodes are called: exposure is ExposureTime, frame rate is AcquisitionFrameRate, image size is Width and Height, bit depth is PixelFormat. GenTL abstracts the transport, so one enumeration call lists the GigE, USB3 and CoaXPress devices attached to a PC.

The payoff arrives the day a camera is replaced: code that writes ExposureTime keeps working, because the name is standardized even when the register behind it moves. The limit shows up in the same week. Features outside the SFNC core are vendor nodes, and calling one a camera does not implement is the classic access failure — GenICam node not existing: diagnose feature access errors walks that diagnosis. Beneath the API, GigE Vision's control protocol (GVCP) reaches the same register map directly, which is how access GigE camera registers at runtime from your control code works.

When does GigE Vision beat USB3 Vision, and when does it lose?

GigE Vision wins on distance and multi-camera cabling: standard Ethernet runs 100 m per hop and several cameras share one switch, while USB3 Vision is a point-to-point link of a few metres. USB3 wins when one camera needs more than the roughly 110 MB/s a 1 Gigabit link carries.

GigE Vision rides on UDP: GVCP handles control, GVSP moves pixels. Being Ethernet buys standard switches, 100 m per hop of twisted pair, and several cameras through one network card. With multicast, a single stream can even reach several receivers at once — GigE Vision multicast receiver: control and stream setup sets that up. The 10GigE Vision extension keeps the model and scales the wire, streaming with RDMA (RoCE v2) to move more than plain UDP copies allow.

USB3 Vision trades reach for per-camera bandwidth and zero network configuration: no IP address, no switch, the host controller arbitrates. It is strictly point-to-point, so a camera that needs full speed needs its own host port. Passive copper cables run a few metres; active optical cables carry USB3 much further when the camera must sit away from the PC.

A global-shutter GigE Vision camera of the kind that ends up on trigger-driven stations:

And the USB3 Vision step for sensors large enough that a Gigabit link would throttle them:

How much bandwidth does each interface really deliver?

Line rate sets the ceiling: 1 Gigabit Ethernet moves about 110 MB/s of image payload, USB3 Vision about 400 MB/s, a CXP-12 connection about 1.25 GB/s, and 10GigE about 1 GB/s. Those are planning numbers with overhead included; never size a camera at the theoretical link rate.

The arithmetic is the whole decision. A 20 MP mono frame at 8 bit is 20 MB on the wire — and Bayer color at 8 bit is also one byte per pixel, so color does not change the wire arithmetic. At 15 fps the camera asks for 300 MB/s: a 1 Gigabit link at about 110 MB/s refuses it, USB3 Vision at about 400 MB/s takes it with margin. A 2.5 MP camera at 40 fps asks for 100 MB/s and rides 1 Gigabit comfortably. Resolution, frame rate and bit depth are the only inputs.

CoaXPress labels carry the line rate — 6.25 Gbit/s for CXP-6, 12.5 Gbit/s for CXP-12 — and 8b/10b encoding leaves 80 percent of it for payload, which is where the 1.25 GB/s figure comes from. Connections sum: a quad CXP-12 grabber carries four single-connection rates into one host. The stream lands in a frame grabber card rather than a network card, and reach is coax in the tens of metres, rate-dependent.

Where the single-camera numbers stop fitting, this is the tier most plants buy:

This is a CXP-12 camera with a global shutter and an M58 mount; the card above carries its full data sheet figures, including sensor format and resolution.

Why doesn't my light controller follow the camera standards?

Camera standards stop at the camera: light controllers expose analog dimming voltage, digital trigger I/O and serial or network commands, and no GenICam file ships inside them. Match the controller's output type and channel power to the light electrically, and treat its command protocol as vendor-specific.

Work on lighting and optics interfaces is underway in the standards groups; until it lands, the catalog is the reality. Control divides into digital and analog, and output divides into constant-voltage 24 V and constant-current, because LED lights are driven either at fixed voltage with PWM dimming or at regulated current. Commands travel over RS-232 on many models, digital I/O carries the timing-critical strobe, and network-capable series add Ethernet running vendor protocols.

The decision this forces is electrical, not protocol. Match the output type and the per-channel power to the light's rating, keep the strobe on hardware I/O where the timing lives, and treat serial or network commands as setup traffic — brightness levels, channel enables, pulse widths — never as the per-frame path. Line scan makes the split starkest, because exposure windows there are microseconds: lighting controllers for line scan cameras is its own subject for that reason. For scenes that fire several channels in order, multi channel light controller sequencing for photometric stereo shows the sequencing side.

A four-channel digital box that takes RS-232 commands and has strobe on its feature list:

How do camera, light and controller stay in sync?

One trigger event fans out to camera and light: a strobe pulse of 100 µs freezes what a 5 ms exposure would blur — at 300 mm/s belt speed that is 30 µm of blur against 1.5 mm. Controllers with built-in light channels make the wiring one cable.

The convention to specify: one master trigger — from a PLC, an encoder or the controller chassis — fans out to the camera's trigger input and the light controller's strobe input, or the controller fires the light and derives the camera trigger from that same pulse. Pulse width shorter than exposure, and both shorter than the fastest motion the inspection must freeze.

Strobing doubles as ambient rejection: the sensor integrates only while the lamp is on, so a 100 µs pulse collects a fiftieth of the stray light a 5 ms exposure would. Strobed lighting ambient rejection: measure and improve it shows how to put a number on that margin, and stabilizing vision images when lighting changes treats the trigger-side fixes for a line whose own illumination drifts.

When the first frame after a trigger comes out black, suspect exposure settling and pulse timing first — first camera frame dark: exposure settling or light timing? walks that diagnosis.

A controller class that closes the loop — cameras, strobe channels and trigger logic in one chassis:

MV-VC3301H-128G66 carries 4 built-in light channels and 5+ LAN ports, so trigger, pulse and exposure share one timing domain. Higher models in the same line add PoE camera ports and more channels, which is how a multi-camera cell keeps its strobes in step.

When do results need OPC UA Vision instead of a vendor SDK?

When a PLC or MES must read pass/fail, measurements and recipe changes without linking your vision software's library, OPC UA Vision gives them an information model — status, results and parameters exposed as objects. Use the vendor SDK inside the vision cell; use OPC UA Vision at the plant boundary.

OPC UA Vision is a companion specification to OPC UA (IEC 62541) that defines objects for vision systems: device state, inspection verdicts, measurement values, recipe parameters, run statistics. The vision industry wrote the model to span the whole range, from a single vision sensor to a multi-camera inspection line, so the same client logic reads a smart sensor and a full system.

The boundary rule holds in practice: GenICam and the vendor SDK inside the cell — control the camera, run the inspection — and OPC UA Vision across the boundary, publishing what the plant needs. When the PLC is the master and the camera hangs off it directly, the checklist changes; GenICam camera on a PLC controller: what to check covers that layout. For the results path itself, read smart camera results over OPC UA into your control system shows it working end to end.

Which standards should you specify, role by role?

Specify a GenICam-based transport for the camera — GigE Vision to 110 MB/s, USB3 Vision to about 400 MB/s, CXP-12 to 1.25 GB/s — a controller whose strobe I/O matches your PLC's trigger convention, and OPC UA Vision wherever plant software consumes results. Everything else is electrical, not a standards decision.

• Camera transport: under about 100 MB/s per camera, or distances beyond USB reach — GigE Vision. One camera that needs 200-400 MB/s and sits close to the PC — USB3 Vision. Above 400 MB/s, several high-rate cameras, or coax runs into a harsh cell — CoaXPress. 10GigE Vision when that rate is wanted on Ethernet infrastructure.
• Camera control: GenICam compliance is the non-negotiable line item. SFNC names are what turn a camera swap into a configuration change instead of a rewrite.
• Light control: electrical match first — 24 V constant voltage against constant current, per-channel power against the light's rating — strobe I/O for timing, serial or network for setup values.
• Results: OPC UA Vision wherever plant software consumes verdicts or measurements; the vendor SDK stays inside the cell.
• Sensor quality: EMVA 1288 sheets report dynamic range, temporal noise and quantum efficiency measured identically for every camera — selecting low-light cameras by EMVA 1288 data shows those numbers applied to a real camera choice.

The standard answer is wrong in two cases. An existing Camera Link line with working frame grabbers is usually cheaper to extend than to convert, so Camera Link stays pragmatic there. And a smart camera hides the whole stack inside one housing, collapsing the standards question into a single item: does it hand results to my PLC in a form my PLC reads — which plain I/O or OPC UA answers.

What do you check before ordering so everything connects?

Six checks take ten minutes: the camera's transport and mount, the PC's NIC or frame grabber, jumbo-frame support on any switch, the light's voltage or current against the controller's output, the strobe wiring convention, and the software's GenTL producers for every transport bought. Mismatches found now cost nothing.

• Transport and mount: the camera's interface against the host's network card or frame grabber and a free PCIe slot; the lens image circle against the sensor format.
• Switch discipline: jumbo frames enabled end to end, the camera subnet isolated from office traffic, the switch rated for continuous image load rather than bursty office use.
• Light electrical match: per-channel power summed across all channels against the controller's total rating, and output type against the light's rated drive.
• Strobe wiring on paper: trigger edge, pulse width and trigger-to-pulse delay written into the wiring sheet before the panel is built.
• Software stack: the GenTL producer for every transport you bought installed on the host, and the SFNC features your code writes tested on the exact camera model.
• Results contract: which values cross the boundary, over which OPC UA objects, and who writes the client — settled before integration week.

Run those six and the parts list becomes a purchase order. Assemble the camera side through the camera finder, match the light side in the light controller configurator, and start the whole build at the camera step of the vision system configurator. For a station that mixes interfaces, vision controllers with several network ports and built-in light channels usually settle the timing question in one chassis — and the systems guides on the topic page carry the integration detail this overview stops at.