GenICam camera on a PLC controller: what to check

You have a GigE Vision camera and an industrial controller — a PLC-class edge device rather than a desktop PC — and you want images inside the control program without writing an acquisition stack. It works when three things are true: the camera has an Ethernet interface, it is GenICam and GigE Vision compliant, and the driver app on the controller negotiates its settings rather than assuming them. This explainer covers what runs where, the arithmetic that tells you how many cameras fit on your ports, how the settings handshake behaves, and the licensing line to budget before you order.

What runs where: camera, app, data layer

The camera never talks to the control program directly. A driver app on the controller — the fanless vision controllers that run inspection cells — enumerates the camera over Ethernet, acquires the frames, and publishes images and inspection values as data-layer variables: tags the PLC program reads and writes like ordinary I/O. Configuration happens on a web page the controller serves, so the cell needs no monitor, and an uploaded settings file clones one camera's set-up onto the next.

Robot controllers do the same job natively; every check below applies unchanged when configuring a GigE Vision camera on a robot controller. If your software speaks GenTL instead of a built-in app, read GenTL producer GigE Vision support: check compatibility first — it answers the same transport question. For the tag side of the link, vision controller Modbus communication: a PLC integration guide maps the camera outputs into the PLC.

The three checks that decide compatibility

1. The camera has an Ethernet interface. GigE covers almost everything; 10GigE serves sensors whose stream tops a gigabit. A USB3-only camera never appears in an Ethernet-first driver app, so choose the GigE variant of that sensor family. The area scan cameras finder filters by interface and settles this in a minute.

2. The camera is GenICam and GigE Vision compliant. Every compliant camera exposes the same standard feature names — ExposureTime, PixelFormat, Gain, AcquisitionStart — whatever the label says. Brand matters only where the app vendor publishes a tested list; an app with generic GenICam support drives anything compliant.

3. The app negotiates instead of pushing. At connection the app must read the camera's published minimum, maximum and step for each parameter, then apply values inside those limits. That handshake is what lets one app drive many camera brands, and it is the behaviour to demand from any driver you evaluate.

The handshake: setting exposure and pixel format

At startup the camera publishes the legal range of every writable feature. When the app writes ExposureTime, values inside the range are accepted, borderline ones are clamped to the nearest step, and the rest are rejected; PixelFormat accepts only the enumerations the sensor actually outputs. The same writes made from code are shown in setting camera exposure time through a GenICam API in Python — a quick way to see the ranges your camera publishes.

Motion, not the camera, sets the exposure you should ask for:

Take a 100 mm field of view on a sensor 4,000 pixels wide: 100 ÷ 4,000 = 0.025 mm per pixel. A part moving 50 mm/s, tolerating half a pixel of blur, allows 0.5 × 0.025 ÷ 50 = 0.00025 s — 250 µs. Ask the handshake for that figure, not the 10 ms a static set-up would use, and confirm the camera's minimum exposure sits below it.

Bandwidth arithmetic: how many cameras per port

Image data, not control traffic, decides the port count:

The LS-CMR-0053 is a 12 MP GigE camera that streams 9 fps. In Mono8 that is 12,000,000 pixels × 1 byte × 9 fps × 8 = 864 Mbit/s — beyond what a port moves at 1,500-byte packets, so enable 9,000-byte jumbo frames on camera, card and switch and it fits. If the sensor offers a 12-bit raw format (1.5 bytes per pixel), the demand becomes 12,000,000 × 1.5 × 9 × 8 = 1,296 Mbit/s: cap the rate at 6 fps, which is 12,000,000 × 1.5 × 6 × 8 = 864 Mbit/s with jumbo frames, or move to a 10GigE path. As a second point, a 6 MP mono camera at 20 fps wants 6,000,000 × 1 × 20 × 8 = 960 Mbit/s — one dedicated port and nothing else on it. Three 1 MP cameras at 30 fps, at 240 Mbit/s each, share one switched port at 720 Mbit/s.

What moves the number: bytes per pixel (Mono8 and raw Bayer 1, packed RGB 3, 12-bit raw 1.5) and frame rate scale linearly, and four times the pixels means four times the stream. The software side of several cameras on one controller is covered in multi-camera acquisition session architecture explained.

Two cameras that bracket the range: a 6 MP mono model on a 1/1.8" sensor for shared ports, and a 12 MP camera at 9 fps that wants a port of its own.

Power and ports: PoE or a network card

An 802.3af port delivers 15.4 W and machine-vision cameras draw roughly 4 to 13 W, so one camera per PoE port is comfortable. Check both ends of the power path with camera power over Ethernet: check support and alternatives.

The MV-VC5525-256G70-NN offers PoE camera ports alongside 32 GB of memory and 5+ LAN ports.

The MV-VC3301H-128G66 takes the other path: 8 GB of memory, 5+ LAN ports and four light channels, with no PoE — its cameras take a 24 V supply instead. When ports run out, the frame grabbers aisle answers: the MV-GE1104 adds four GigE ports to a controller with a spare card slot. Browse the full network card selection for port counts and PoE variants.

Picking the camera end

Static or strobed parts tolerate a rolling shutter; anything moving under continuous light needs a global-shutter sensor or the image smears. Resolution follows the port budget above: a 12 MP stream fills a GigE port, a 6 MP one leaves headroom. For detail on a single port, the MV-CS200-10GC is a 20 MP GigE camera with a 1" sensor, a C-mount and a color filter — its shutter is rolling, so hold the part or strobe the light.

Filter by interface and shutter in the camera finder before shortlisting anything.

When the usual answer is wrong

• "Any camera works." Only Ethernet cameras do. A USB3 camera on an Ethernet-first driver app is a non-starter; swap the camera model, not the app.
• "Any GenICam camera works." True for generic-GenICam apps, false where the vendor publishes a tested list; an unlisted brand may deviate from the standard features. Ask the app vendor before ordering.
• "One license runs the cell." These apps license per camera: two cameras, two licenses, one controller.

• "It connects but drops frames." Check the MTU first — a 9,000-byte camera feeding a 1,500-byte port stalls — then the subnet, then any firewall on the controller port. Robot cells show the same failures; GigE camera connection troubleshooting on a robot controller walks the sequence.

Checks before you order

• Camera: GigE Vision and GenICam compliance stated; global shutter if the parts move.
• Ports: one GigE port per camera streaming above roughly 400 Mbit/s; a switch may share lighter loads.
• Power: PoE wattage per port if the controller powers the cameras; 24 V wiring where it does not.
• Network: 9,000-byte MTU from camera to controller; both ends on one subnet.
• App: your camera brand on the tested list, or generic GenICam support confirmed in writing.
• Licensing: one driver license per camera, on the same order as the cameras.
• Exposure: the camera's minimum exposure below the motion limit from the formula above.

With the list clear, build the cell in the configurator starting at the camera step, or send us the camera count and frame rates and we will size the controller and ports.