Camera compatibility with vision software: what GigE Vision guarantees

You are choosing a camera for vision software that did not come from the camera maker, and the compatibility list you were handed is short and stale. The answer is a standard, not a list. Any camera that implements GigE Vision and carries a GenICam feature description will enumerate, stream and accept standard commands in any compliant application — PC software, a line viewer, even a robot controller — whatever the brand. That guarantee reaches discovery, image transfer, exposure, gain and triggering, all under standardized feature names. It stops at the vendor's custom nodes, strobe pulse duration being the classic one. Below: where the guarantee starts and stops, the bandwidth math attached to it, the network settings that decide success, and the short list of tasks that still belong in the camera maker's own tool.

What GigE Vision guarantees

GigE Vision is an interface standard for cameras on Gigabit Ethernet, and GenICam is the control layer above it that gives features the same names on every brand. Together they give you this: a compliant camera from any maker, on a compliant application from any maker, is discovered automatically, opened, streamed from and configured through the same commands. No vendor SDK, no driver disk per camera.

For buying, the consequence is simple. Choose the camera on sensor size, resolution, shutter and lens mount — the things that decide image quality — and treat the interface as solved. In the camera finder you can filter to Interface: GigE, and every model that passes speaks to your software the same way. What the software owes you in return — which GenTL producer, which driver package — is the other half of the question, covered in GigE Vision camera software compatibility checks.

Both of these are C-mount GigE cameras from different series:

The MV-CU020-90GC is a 2.5 MP model with a global shutter and a 1/1.7-inch sensor; the LS-CMR-0053 is a 12 MP model with a 1/1.7-inch sensor and a rolling shutter. To your application the difference is feature values, not integration work.

How the application finds the camera

Discovery runs over UDP broadcast: the application asks the local subnet which cameras are present, each camera answers, and control then runs over the GigE Vision control protocol on UDP port 3956. Addressing needs no effort on an isolated link — a camera with no static address falls back to a link-local 169.254.x.x address — and most tools can force a new address into a camera that arrived on the wrong subnet.

Two habits keep this boring, which is the goal. Give the camera its own adapter in the PC, on its own subnet, so discovery never competes with office traffic. And keep the link point-to-point or behind an industrial switch: managed switches with aggressive broadcast filtering eat the discovery packet, and that one setting generates more missing-camera reports than any camera defect.

What GenICam standardizes, and what stays with the vendor

The camera serves an XML file describing every controllable feature, and the standard feature naming convention fixes the common names: Width, Height, PixelFormat, ExposureTime, Gain, AcquisitionStart, TriggerSource, LineSource. Your application reads that file and builds its camera panel from it, which is why setting exposure time through a GenICam API works identically on any compliant camera.

The same XML carries the maker's custom nodes, and there the guarantee thins. Strobe pulse duration is the standard example: timing a strobe line against exposure involves vendor-specific registers, so the duration often appears as a custom node your software will not present as a friendly field. The reliable path is to open the camera maker's configuration tool once, set the strobe duration and the line behavior, and save the result to a user set so it survives power cycles. The strobe wiring itself is standard territory: GenICam names the line source — GenICam line settings when a trigger source is not detected covers the naming — and whether you need a GPIO cable for acquisition is a hardware question, not a brand question.

The bandwidth ceiling that comes with the guarantee

GigE Vision rides a 1000 Mbit/s link, so the guarantee ships with a hard throughput ceiling. Plan with usable throughput at 85 percent of the wire rate:

Worked example for the common 5 MP mono format at 8 bits per pixel, the same byte count as raw Bayer color: a 2448 × 2048 sensor produces 2448 × 2048 × 1 = 5,038,848 bytes, about 5.0 MB per frame. The link carries 125 MB/s raw, so usable throughput is 0.85 × 125 ≈ 106 MB/s. The ceiling is 106 ÷ 5.0 ≈ 21 fps for one camera on one adapter. Add a second identical camera and each falls to about 10 fps: the link, not the camera, is the limit. RGB pixel formats triple the bytes, and the division follows the same way.

High resolution turns the ceiling into the whole story. A 20 MP frame at 8-bit mono is about 21 MB, so one 1000 Mbit/s link tops out near 5 fps, and continuous inspection at that resolution belongs on 10GigE cameras — GigE Vision camera selection by bandwidth works through that arithmetic per interface. The MV-CS200-10GC is a 20 MP GigE camera with a 1-inch sensor and a C-mount.

Network settings that decide success

Packet size. The Ethernet default of 1500 bytes per packet works through every switch and adapter. Above roughly 50 MB/s of sustained streaming, enable jumbo packets of about 9000 bytes on the camera and on the adapter: per-packet overhead and host CPU load drop sharply. Every switch between the two ends must pass the size you chose.

The adapter. One network adapter per camera keeps the bandwidth arithmetic honest and discovery quiet. Turn interrupt moderation and adapter power saving off on an acquisition port, and check PCIe slot bandwidth when you fill a PC with adapters. When the library logs buffer overflow errors, the adapter configuration is the first suspect, and GigE camera buffer overflow troubleshooting walks the usual causes in order.

The cable. Gigabit Ethernet is specified to 100 m on Cat5e, longer than almost any vision station needs. In vibration areas use a locking connector and strain relief; in drag chains use high-flex construction. The LS-CBL-0199 is a 3 m high-flex GigE camera cable with screw locks; the LS-CBL-0117 is a 15 m RJ45 camera data cable with a locking stud. The cables category covers both styles by length and type.

The same guarantee on other transports, and its limit on smart cameras

GenICam is transport-agnostic: USB3 Vision and CoaXPress cameras carry the same feature names, so an application that loads the right GenTL producer drives them the same way, and GenTL producer support for GigE Vision is the check on the software side. Smart cameras are the boundary of the guarantee: they run inspection onboard, their Ethernet port carries configuration and inspection data, and only models that state they expose a raw GigE Vision stream behave like cameras to your software. Read that line in the datasheet before planning a hybrid cell; smart camera software compatibility lists what else changes.

Robot controllers that accept a camera follow the same discovery path as PC software, so configuring a GigE Vision camera on a robot controller is the same subnet and IP work described above.

Checks before you order

• The datasheet names GigE Vision and GenICam compliance, not just a GigE port. A camera with a proprietary Ethernet interface needs its own SDK for everything, including acquisition.
• The library supports the feature generation the camera uses. ExposureTime and Gain are safe everywhere; newer nodes may be missing on older software, and diagnosing GenICam feature access errors separates a camera gap from a software gap.
• Frame size times frame rate fits the port: width × height × bytes per pixel × fps stays under the usable throughput of each link, about 106 MB/s on 1000 Mbit/s.
• The camera maker ships a configuration tool for your operating system, because at least one custom node will need it.
• Cable type suits the run: high-flex in drag chains, locking connectors in vibration, and length with margin for the route.

When the guarantee does not hold

Four cases account for nearly every claimed incompatibility. A datasheet that promises GigE without the Vision standard behind it. Software with no GigE Vision transport loaded, which some applications expect you to point at a producer file. A camera waiting in firmware-recovery mode, which only the maker's tool can leave. A managed switch filtering the discovery broadcast. All four are installation problems with a fix on the checklist, not reasons to narrow the camera shortlist.

Start from area scan cameras filtered to GigE, or begin configuring a system at the camera step; when the software side is the open question, send the application details and we will match cameras to both ends.