GigE Vision camera on an RT controller: driver support check

Real-time controllers keep gaining GigE ports, and the assumption follows the hardware: port present, so any network camera will work. It will not. A GigE Vision camera enumerates only on a target that runs a GigE Vision acquisition driver, and a device list that says "IP camera" describes a different protocol entirely. This explainer gives you the decision, the bandwidth and CPU arithmetic behind it, a worked link-budget example, and the architectures that work when the driver is missing, so you can commit to a design before hardware ships. It is written for engineers pairing industrial cameras with RT controllers, gateways and PLC-side targets.

A GigE port is wiring, not support

The question arrives in a familiar shape: an RT gateway with a GigE port, a driver list that already covers IP cameras, and a machine-vision camera on the bench. The camera will not run there. Ethernet hardware moves bytes; it does not speak protocols. A GigE Vision camera waits for a client that can discover it, load its feature description and receive raw frames close to line rate. An IP-camera driver does none of that, so the camera never appears in the device list.

The decision rule: a GigE Vision camera runs on an RT controller only when four things hold at once. A free port. A GigE Vision driver in the target's supported-device list. Packet-size (jumbo-frame) control over that port. CPU headroom to receive a near-full link. One of the four missing and the camera stays dark, however many connectors the front panel offers.

The same trap catches PLC-side projects, because a socket and a protocol stack are different things; the checks for putting a GenICam camera on a PLC controller start at the same line of the specification.

What the driver does that the port cannot

GigE Vision is a protocol family, not a cable speed. At enumeration the camera answers a discovery broadcast on its subnet. Control then runs over the GigE Vision Control Protocol (GVCP): read and write exposure, gain, trigger mode, every feature the camera's GenICam description exposes. Images arrive as raw, uncompressed frames over the GigE Vision Stream Protocol (GVSP), with the driver requesting resends of lost packets and pacing the stream when several cameras share a controller. Every one of those verbs needs code on the receiving processor.

An IP camera solves a different problem. It encodes video internally and streams H.264, H.265 or MJPEG over RTSP or HTTP, so any generic media client, including viewers built into gateways, can display it. That convenience is exactly why the two are not interchangeable:

On a PC you rarely notice this layer because the camera maker or the software vendor installed it. On an RT target the stack must be built for that operating system and silicon, usually surfacing as a GenTL producer with GigE Vision support. If the RT environment cannot load one, nothing downstream rescues the project.

The link budget: bandwidth, packets and CPU

The gap between line rate and ceiling is deliberate: packet headers, inter-frame gaps and headroom for resends. Budget with the ceiling, not the line rate.

Packet size decides how much CPU that budget costs. A standard Ethernet payload carries 1500 bytes; the usual jumbo setting carries 9000, six times the bytes per packet (9000 ÷ 1500 = 6). Six times fewer packets means six times fewer interrupts and stack crossings for the same image, which is why jumbo support on the RT side belongs in the decision rule. Set the packet size before streaming: set the GigE camera packet size before starting acquisition, or the first frames arrive at the camera default and stall.

Interrupt load is the third number. Near line rate, packet arrival dominates the receive path. GigE camera interrupt moderation trades a little latency for a large cut in CPU, and on a core that also closes a 1 kHz control loop you want that cut. On embedded Linux targets, size the receive buffers as well: GigE camera buffer timeouts are the classic first symptom of undersized ones.

With more than one camera, give each its own port and assign cameras to ports reliably so addresses stay put, then bring them up in sequence, because camera discovery startup contention can black-screen a multi-camera boot.

Worked example: a 12 MP camera at 9 fps on one RT port

Inputs, with their sources: the camera is the LS-CMR-0053, a 12 MP GigE model that streams at 9 fps. The transport assumption is mono Bayer at one byte per pixel, the usual payload when the software does the colour processing; the link is one dedicated port at 1 Gb/s.

The rule in words: multiply pixels by bytes per pixel to get frame size, multiply by frame rate to get payload, and compare with the ceiling.

1. Frame size: 12,000,000 pixels × 1 byte = 12 MB per frame.
2. Payload: 12 MB × 9 fps = 108 MB/s.
3. Share of the link: 108 ÷ 125 = 86% of line rate, 7 MB/s under the ceiling.
4. Packets at 1500 bytes: 12,000,000 ÷ 1500 = 8,000 per frame; 8,000 × 9 = 72,000 packets per second.
5. Packets at 9000 bytes: 12,000,000 ÷ 9000 ≈ 1,330 per frame; × 9 ≈ 12,000 per second, one sixth of the interrupt and stack work.

Decision: the stream fits, but only as the sole camera on a dedicated port with jumbo frames enabled. At 86% of line rate there is no room for a second camera or for PLC traffic on the same segment. RGB output at three bytes per pixel would triple the payload to 324 MB/s and move this camera to a 10GigE interface. And the arithmetic is void without the driver: no payload fits a stack that was never installed.

How to prove support before any hardware ships

1. Read the supported-device list. Search it for the exact words "GigE Vision". "GigE", "Ethernet camera" and "IP camera" do not count; they describe wiring and media streaming, not this protocol.
2. Name the acquisition software. The vendor must name the vision package or GenTL producer the RT OS loads at boot, and the OS version it is qualified against. No name, no support.
3. Confirm packet-size control. The RT environment must set the port's frame size and the camera's packet size. Jumbo support that needs a desktop tool beside the controller will not survive commissioning.
4. Run the numbers. Payload per camera from the formula, every link under the ceiling, one camera per port.
5. Soak test. One camera at full frame rate for ten minutes, watching for resent packets and blank frames; GigE Vision stream packet loss is the diagnosis path if they appear.
6. Measure the control loop. Log RT task jitter with the stream running and with it stopped. The two logs should match.

When the driver is missing: three architectures that work

Robot controllers with camera ports obey the same rule: the walkthrough for connecting a GigE Vision camera to a robot controller begins with that controller's camera-support checklist, not with its connector.

Put a vision controller in front. The cameras plug into a vision controller whose whole job is running the stack, and only results, such as pass/fail flags and pick coordinates, cross to the RT target over Modbus TCP, EtherNet/IP or a socket. The RT side keeps hard timing; the vision side owns the packets. The MV-VC3301H-128G66 does this job: 5+ LAN ports, 8 GB of memory, an Intel Core i3 processor and a vision software license in the box.

Acquire on a host with a proper NIC. A Windows or Linux industrial host runs the vision software and gives each camera its own port; the RT target receives results only. The MV-GE2002P is a dual-port PoE GigE NIC: two camera ports, with power delivered over the same cables.

Change the interface. USB3 Vision or Camera Link work only where the RT target lists them, and each carries its own driver requirement; USB camera external trigger support lists the further checks before you commit. When cameras outgrow 1 Gb/s, 10GigE and CoaXPress arrive through frame grabbers and the accessories finder. Porting a stack to a bare RTOS is a project, not an install; the write-up of a GigE Vision camera RTOS port shows the scale of that job.

When the usual answer is wrong

• "It has a GigE port." Wiring, not software. The port answers ping; only the stack answers the camera.
• "PoE means camera support." PoE is power. A port can feed a camera all day and still refuse its first packet.
• "The NIC driver covers it." NIC drivers move frames. The vision stack sits above them and must exist for the RT OS specifically.
• "I will fit a frame grabber." A CoaXPress or Camera Link card helps only when the RT OS loads its driver; frame grabber driver mismatch after a vision software upgrade shows how easily that breaks even on PCs.
• "The bandwidth fits." A link that fits on paper still stalls with default packet sizes on a shared subnet and no soak test. The failure arrives at commissioning, on the shift you are not on.

Checklist before you order

• The words "GigE Vision" appear in the RT target's supported-device list, with the package name beside them.
• One dedicated 1 Gb/s port per camera, jumbo frames configurable from the RT environment.
• Payload per camera under the planning ceiling, from your own numbers.
• A ten-minute soak at full frame rate with no resend alarms and no blank frames.
• RT loop jitter logged with the stream on and off, and identical.
• The result path from vision to control defined: register map, socket or fieldbus tag.
• Cameras on a private subnet; PLC and motion traffic elsewhere.

If the target passes, pick the camera in the camera finder or among area scan cameras, then start at the camera step of the system configurator. If the supported-device list is ambiguous, send it through the contact page and we will shortlist cameras and NICs that match.