You have an industrial controller — a PLC-style device with an Ethernet port and a camera driver app — and a GenICam camera, and you need images landing in the controller's data layer on command. Any GigE Vision, GenICam-compliant camera works, because the driver speaks the protocol, not a brand. The whole job is three things done in order: a static IP plan, jumbo frames on every link in the path, and one request/ready handshake you reuse for connect, capture and save. This guide runs it from bench to production loop, with the subnet, MTU and frame-size arithmetic worked out. For the wider question of whether a camera on a controller fits your cell at all, start with GenICam camera on a PLC controller: what to check.
What do you need to connect a GenICam camera to a controller?
You need an Ethernet GenICam camera, a controller with a camera driver app and its license, a jumbo-frame switch, an engineering PC, and two shielded Cat5e or better cables — and one 1 Gb/s port per camera you connect.
On the camera side, anything from the GigE area scan cameras range works. Match the camera to the inspection first — sensor size, resolution, shutter — because the wiring below is identical for all of them; choosing an industrial 2D Ethernet camera walks that decision. A 12 MP GigE camera such as the LS-CMR-0053 is a workhorse size for this role.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- 12 MP
Cable: shielded, with locking connectors, and high-flex construction wherever the run moves. Two cables cover most set-ups: a 15 m shielded data cable such as the LS-CBL-0117 for fixed cabinet runs, and the 3 m high-flex LS-CBL-0199 for a drag chain:
- Type
- Camera data cables
- Length
- 15 m
On the controller side, browse vision controllers for a fanless unit with spare LAN ports. A model with 5+ LAN ports such as the MV-VC3301H-128G66 lets each camera home-run to its own port, with no switch in the path until the machine grows.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
Between them sits a jumbo-frame-capable DIN-rail switch — industrial Ethernet switches for camera networks explains the port and mounting choices. A single camera can cable straight to the controller; add the switch the moment a second device shares the network.
How do you set the camera's IP address before connecting it?
Give the camera a static IP inside the controller's subnet with DHCP and Auto-IP (link-local) switched off — for example camera 192.168.1.21 with mask 255.255.255.0 against the controller at 192.168.1.1 — using the camera maker's configuration tool.
Do this on the bench, camera cabled to the engineering PC, before the camera ever meets the switch.
- Cable the camera to the engineering PC and open the maker's configuration tool; it finds the camera by broadcast.
- Write the static address: camera 192.168.1.21, mask 255.255.255.0. Disable DHCP. Disable Auto-IP / link-local. Enable persistent IP if the tool offers it.
- Give the PC an address in the same subnet, 192.168.1.100, and confirm the tool still finds the camera at its new address.
- Set the controller's Ethernet interface to 192.168.1.1, mask 255.255.255.0 — its MTU comes in the next section.
- Move the camera to the switch, ping 192.168.1.21 from the controller, and power-cycle the camera once to prove the address survives.
The arithmetic is just the subnet: mask 255.255.255.0 puts all three devices in 192.168.1.0/24, where host addresses .1 through .254 are valid. Keep the controller at .1, park the engineering PC near .100, and number cameras from .21 up. A camera that answers on 169.254.x.x still has Auto-IP on — fix that before it reaches the line.
What MTU and packet size should you set?
Set 8,000 bytes of MTU on the controller port, the switch and the engineering PC — every link in the path — then set the camera's packet size 64 bytes below the MTU, which is 7,936 bytes; go to 9,000 only when every device in the path supports it.
The reason is packet count. A 6-megapixel Mono8 frame is 3,072 × 2,048 × 1 byte = 6,291,456 bytes. At a 7,936-byte packet size that is 6,291,456 ÷ 7,936 ≈ 793 packets per frame. Leave jumbo frames off — MTU 1,500, packet size 1,436 — and the same frame becomes 6,291,456 ÷ 1,436 ≈ 4,383 packets, roughly five and a half times the interrupt and resend bookkeeping on the controller.
The 64-byte margin covers the 14-byte Ethernet header, 4-byte frame check, 20-byte IP header, 8-byte UDP header, and change for a VLAN tag. Set the camera's packet size before the first acquisition, not after — Set GigE camera packet size before starting acquisition shows the node to write. If frames then stall or arrive torn, GigE Vision stream timeout: check packets, buffers and MTU walks the fault tree.
Prove the path with one ping before you blame the camera: a don't-fragment ping with a 7,972-byte payload must cross every link, because 7,972 + 20 (IP) + 8 (ICMP) = 8,000 bytes. If any switch in the path tops out at 1,500, set everything to 1,500 and packet size 1,436, and plan the machine around the higher packet rate.
How do you configure the camera driver on the controller?
The driver keeps one application file that lists one configuration file per camera, and each camera file carries an id, the camera serial number, the exposure time in microseconds, and the pixel format Mono8 or RGB8; save, then restart the driver.
Two files, that is all. The application file names the cameras:
{
"configurations": ["camera_1.json"],
"system": { "debug": true, "logLevel": "INFO" }
}
And each camera file holds its settings:
{
"id": "camera1",
"serial": "SN123456",
"exposureTimeUS": 4321,
"pixelFormat": "Mono8"
}
Three rules keep it working: every file listed must exist; no serial number may appear twice — one camera, one entry; and the exposure unit is microseconds, so 4321 means 4.3 ms of light. If you would rather tune exposure from code during commissioning, Setting camera exposure time through a GenICam API in Python shows the feature names and units.
How do you confirm the controller sees the camera?
Read the driver's discovery nodes — lists of found camera IP addresses, MAC addresses, module names and serial numbers — and check the serial you typed into the camera file appears there exactly; only then run the connect handshake.
- Ping 192.168.1.21 from the controller; on a local switch the reply comes back in under 1 ms.
- Open the data layer browser to the driver's system node and refresh the lists.
- Match the found serial, character for character, against the camera file.
If the ping answers but the lists stay empty, the controller's firewall is eating the discovery broadcasts: control traffic is UDP 3956, image packets ride negotiated high UDP ports. GigE Vision camera firewall: ping works, discovery fails lists exactly what to open.
How does the request/ready handshake work?
Every command — connect, capture, save — runs the same five steps on its own control node: wait for ready = true, set request = true, wait for ready = false, reset request to false, wait for ready = true again; then read the status code, where 0 means success.
- Wait until
readyreads true — the driver is idle and will accept a command. - Set
requestto true. That edge starts the action. - Wait until
readyreads false — the driver has taken the command and is busy. - Reset
requestto false. Skipping this leaves the driver armed for nothing. - Wait until
readyreturns to true, then read the status code; anything other than 0 is a failure, with the reason in the status message node.
wait read(node + "ready") == true
write(node + "request", true)
wait read(node + "ready") == false
write(node + "request", false)
wait read(node + "ready") == true
assert read(node + "status/code") == 0
Give each wait a deadline and fail loudly when it passes: 5 s for connect (opening the control channel, reading the camera's feature XML, applying settings), exposure time plus 1 s for capture, 10 s for save on internal storage. A ready that never returns is a stuck request — Camera trigger ready timeout: diagnose software triggering covers the recovery.
How do you trigger a capture and read the image?
Run the handshake on the capture node, confirm the status code reads 0, then read the image node at once and copy the bytes into your own buffer — the next capture overwrites that node, so read before you trigger again.
Size the loop before you size anything else. A 6-megapixel sensor at 3,072 × 2,048 in Mono8 produces 3,072 × 2,048 × 1 = 6,291,456 bytes, about 6.3 MB per frame. A GigE link sustains roughly 100 MB/s of image payload (1 Gb/s is 125 MB/s on paper; protocol overhead and resend headroom take the rest), so one frame crosses the wire in 6.3 ÷ 100 ≈ 63 ms — a ceiling near 15 frames per second. Switch the camera file to RGB8 and the frame triples to 18.9 MB, 189 ms, about 5 fps. With exposure set to 4,321 µs (4.3 ms), the link sets the cycle time, not the light.
When one trigger must collect several exposures — bright field and dark field, say — Multi-image capture per trigger: get an image set from one shot keeps them inside one cycle.
Where should captured images be stored?
The driver writes images to the controller's internal storage, a USB stick or SD card, or a Samba network share; pick the destination in a storage block inside the camera file, restart the driver, then run the handshake on the save node.
"storage": {
"type": "Internal",
"parameters": { "remotePath": "images" }
}
Internal storage is the default for good reason: it is fast, and it keeps collecting when the plant network blinks. A Samba share sends images straight to a review station; USB and SD media are for bring-up and logs, not full-rate streams. Whichever you pick, run the disk sum first: one 6.3 MB Mono8 frame per part at a 2 s cycle is 3.15 MB/s — about 11 GB an hour, roughly 270 GB a day. Keep every image for a shift only, or keep failures only; Machine vision image retention within a storage limit covers rotation and culling.
What goes wrong most often, and in what order do you check?
Check in this order: DHCP or Auto-IP still enabled on the camera, an MTU mismatch somewhere in the path, a mistyped or duplicated serial in the camera file, exposure entered as milliseconds, and reading the image node after the next capture has overwritten it.
| Symptom | First check | Fix |
|---|---|---|
| Discovery lists empty, ping answers | Controller firewall | Open UDP 3956 and the high UDP stream ports |
| Connect handshake fails, status nonzero | Serial and subnet | Copy the serial from the discovery list; put the camera in 192.168.1.0/24 |
| Frames torn, blank or stalled mid-frame | Path MTU | Don't-fragment ping 7,972 bytes; set 8,000 everywhere, packet size 7,936 |
| Second camera never connects | Serial duplication | One entry per serial in the application file |
| Image node reads empty | Read timing | Copy the image in the same cycle as the capture, before the next request |
Torn frames that survive the MTU fix are packet loss on a saturated link — GigE Vision stream packet loss: diagnose blank frames takes it from there.
Before you call the cell done:
- Static IPs survive a camera power cycle.
- The 7,972-byte don't-fragment ping crosses every link.
- Packet size 7,936 is set before the first acquisition.
- The serial in the camera file matches the discovery list exactly.
- Every command checks the status code; nonzero codes are logged with a timestamp.
- Each cycle copies the image out of the driver node.
- Storage is sized — 11 GB an hour at one 6.3 MB frame per 2 s.
With the loop running, the next step is handing results to the PLC: Vision controller Modbus communication: a PLC integration guide covers the register mapping. To build the rest of the station around the camera you just proved in, start at the system configurator, or line up spares in the camera finder and the accessories finder. For a camera-controller pair you want checked before you order, write us through the contact page.
Questions
How many cameras can one controller Ethernet port carry?
One in practice, if they stream continuously. A 1 Gb/s link moves about 100 MB/s of image data, and a 6 MP Mono8 frame is 6.3 MB, so one camera already peaks near 15 fps. Two cameras on one port halve that and invite packet loss under load. Give each camera its own port — a controller with 5+ LAN ports removes the switch from the path — or accept a lower frame rate per camera.
Why does discovery list the camera but connect returns a nonzero status?
Nine times out of ten the serial number in the camera file does not match the camera exactly — copy it from the driver's found-camera-serials node instead of typing it. Next most common: the camera sits outside the controller's subnet, or another application on the controller still holds the control connection. A camera reporting a 169.254.x.x address never left Auto-IP mode.
Should you use Mono8 or RGB8 for the inspection?
Mono8, unless the decision you automate is a color decision. Mono8 carries 1 byte per pixel, so a 6 MP frame is 6.3 MB and crosses a GigE link in about 63 ms; RGB8 triples both — 18.9 MB and about 189 ms — for color your algorithm may ignore. Code reading, presence checks and most measurement run fine in Mono8, and they run three times faster.
How far can the camera be from the switch?
100 m on Cat5e or better for a 1 Gb/s link — the Ethernet limit — and that budget includes the patch cords at both ends. Longer runs need a switch in between or a fiber media converter. In a cabinet keep camera runs short and shielded; on a moving gantry use high-flex cable rated for drag chains and lock the connectors.
Do you still need a hardware trigger line with this handshake?
No for on-demand capture; yes when the exposure must line up with a moving part. Handshake timing follows the controller's cycle and network latency, while a wire into the camera's trigger input fires within microseconds of a sensor edge. If parts pass faster than one field of view per second, wire the hardware line.
What does a status code other than 0 mean?
Any nonzero code is a failure, with the reason in the driver's status message node — read both, log them with a timestamp, and never retry in a tight loop. The two you meet first are a connect timeout, which points at the IP or serial, and a capture timeout, which means no image arrived inside the exposure-plus-transfer window — almost always an MTU or bandwidth problem.