Machine vision PLC integration on the production line

Coming from custom or defense imaging into factory automation, the hard part is rarely the imaging: it is the line. Plants do not adopt a newcomer's architecture; they expose a fixed set of interfaces and expect every station to speak them. The open architecture worth building toward is a set of four standards rather than a product: a GigE Vision camera with GenICam, a vision controller with segregated networks, results exchanged with the PLC over EtherNet/IP, PROFINET or Modbus TCP, and a digital I/O handshake for trigger and strobe. Build your software against those four and it plugs into lines regardless of who built them. This guide gives the architecture, the protocol decision, the handshake design and a worked station example with the arithmetic shown.

The decision: speak the line's four standards

You will not find a line vendor whose controller your suite simply joins, and you do not need one. Every PLC-controlled line, whatever its maker, exposes the same four attachment points, and each one is standardized:

• Camera interface: GigE Vision with GenICam. Any compliant software drives any compliant camera over standard Ethernet, on cable runs up to 100 m of Cat5e/6. Your acquisition layer survives a customer's camera choice.
• Results protocol: EtherNet/IP, PROFINET or Modbus TCP. The PLC picks; you implement. These three cover the line controllers you will meet.
• Digital I/O handshake. A 24 V trigger line in, busy and results-ready lines out. Any PLC can drive them.
• Strobe timing from your controller. Your light channels fire in lockstep with the camera exposure, so image quality stays your responsibility and your differentiator.

The order of decisions is fixed: ask the controls engineer which PLC the line runs, which protocol it speaks and where the register map lives. Everything above that line is your design space. For the same story from the controls side, read getting started with machine vision for PLC programmers.

The reference architecture

Picture one station with three segregated networks:

• A camera network: one GigE Vision camera, or several, on a dedicated network card in the vision controller, through its own switch. Enable jumbo frames of about 9 kB on that card and that switch only.
• A PLC network: a second card on the line's industrial Ethernet subnet, carrying results, recipe writes and diagnostics.
• A plant network: an optional third card for MES or remote access, firewalled by IT.

The vision controllers built for this are fanless, DIN-rail industrial computers with several network cards, and the digital I/O lands on the same box. Nothing in this layer knows or cares whose software runs on it — that is the openness you sell.

If the cell includes a robot, keep the PLC as the orchestrator: vision writes offsets to the PLC or straight to the robot controller, and the split of responsibilities is laid out in robot vision cell control architecture for palletizing. Cells that fuse PLCs, robots and vision follow this same pattern, as a walkthrough of automating EV production with PLC, robot and vision integration shows end to end.

The camera layer: GigE Vision and GenICam

GigE Vision won the factory floor for reasons that matter to an integrator: 100 m cable runs, multi-camera fan-out through a switch, and a GenICam feature layer that names every control the same way on every camera — Width, ExposureTime, TriggerSource. Your software talks to the standard, not to a vendor SDK. What that interoperability actually guarantees is covered in what GigE Vision guarantees for software compatibility, and the cable and bandwidth trade-offs in GigE Vision camera selection: bandwidth, cables and software.

Where product moves past the lens, choose a global shutter. The MV-CU020-90GC is a 2.5 MP global-shutter GigE camera in a C-mount that fills this role.

Browse the area scan cameras range or filter by interface in the camera finder when the customer dictates resolution, mount or frame rate.

The compute layer: a vision controller, not an office PC

Your software needs an industrial home: fanless, DIN-rail mounted, multiple network cards for the segregated subnets, and ideally PoE camera ports and built-in light channels so one box owns acquisition, illumination and results. Bringing the camera onto that box is covered in connecting a GenICam camera to an industrial controller over Ethernet; when several cameras share it, follow assigning cameras to ports reliably in a multi-camera system.

The entry point is the MV-VC3301H-128G66: an Intel Core i3, 8 GB of RAM, a 128 GB SSD, four built-in light channels, PCIe expansion and no PoE.

For larger cells, step up to the MV-VC5525-256G70-NN: 32 GB of RAM, eight built-in light channels and PoE camera ports, so a single cable per camera carries power and video.

The VC3000 and VC5000 series bracket the choice:

All 3 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The MV-VC2140-128G40-1T in the middle of that table carries an N97 processor, 8 GB of RAM, a 128 GB SSD and a 1 TB drive — useful when the customer wants image archives kept on the station.

Talking to the PLC: match the protocol the line already speaks

The controls engineer decides the protocol, and the decision tree is one question deep:

Decide like this: a named protocol at the survey means you implement that protocol. An unknown or mixed plant means you ship Modbus TCP first, because nearly every PLC reads holding registers over port 502, then add the other two as the pipeline demands. A full register-map walkthrough is in vision controller Modbus communication: a PLC integration guide.

Two facts make the Ethernet layer easy to get right. PROFINET and Modbus TCP can share one port on the controller — they are independent stacks — so one cable to the PLC switch can serve a PROFINET I/O connection and a Modbus diagnostic channel. Camera video must never share that subnet: GigE Vision traffic at near line rate will disturb PROFINET cycles measured in milliseconds. Ship the GSDML and EDS files with your station image; without them the controls engineer cannot add you to the project at all. Map your alarms into status words as shown in vision system diagnostics to PLC status and alarm mapping.

The handshake: trigger, strobe and results

Trigger and strobe belong on wires; results belong on the network. The four-step handshake:

1. The PLC writes the part ID and recipe number to your registers and raises the trigger line, or a protocol trigger bit.
2. Your controller asserts busy, fires the strobe channel, and the camera exposes on its hardware trigger input.
3. Processing done, the controller writes results — mirrored part ID, offsets, defect counts — and raises results-ready.
4. The PLC reads, drops the trigger, and the controller clears ready. The state machine returns to idle.

Wiring details that bite newcomers: camera trigger inputs are opto-isolated and accept 24 V PLC levels, so settle whether you need a camera GPIO cable before assuming a pinout; the camera input must be set as the trigger source, or you hit the GenICam line settings behind an undetected trigger; and if you fire from software instead, work through camera trigger ready timeouts before blaming the PLC. When several parts are in flight, match frames to triggers by timestamp as described for asynchronous vision result frame matching.

On the illumination side, a light controllers box gives you timed, overdrivable strobe pulses. A unit like the LS-CTL-0070 drives four channels of 24 V lights at up to 200 W with strobe support and an RS-232 port for setup.

Worked example: one station at sixty parts a minute

A part 150 mm × 110 mm rides a belt at 0.5 m/s, so the line presents a part every second. The smallest defect to catch is 0.5 mm, and 0.05 mm per pixel puts ten pixels across it — comfortable.

Sensor and scale. A 12 MP camera with a 4000 × 3000 sensor, a 1/1.7-inch format about 7.4 mm × 5.5 mm, so 1.85 µm pixels:

The part sits inside 200 mm × 150 mm with 40–50 mm of margin for position wander.

Lens and working distance. With a 25 mm C-mount lens:

Run your own sensor, lens and distance through the field-of-view calculator.

Exposure. Allow half a pixel of blur, 0.5 × 0.05 mm = 0.025 mm at the part:

Fifty microseconds is dark territory for continuous lighting and easy for a strobed LED, which is why the light controller exists: the strobe pulse equals the 50 µs exposure.

Aperture. At f/4 the Airy disc is 2.44 × 0.55 µm × 4 ≈ 5.4 µm, about three pixels — sharp. Depth of field with a two-pixel blur circle, c = 3.7 µm, is an estimate worth having:

The part height varies ±10 mm, so ±11 mm of that estimate covers it.

Result deadline. A 12 MB mono frame over GigE at the roughly 100 MB/s a real link delivers:

Exposure 50 µs, transfer 120 ms, processing 250 ms, PLC scan 20 ms: about 390 ms against a 1,000 ms part pitch. The station answers within half a pitch, with margin for retries. At 300 parts a minute the same camera cannot ship full frames — 100 MB/s divided by 12 MB tops out near eight frames a second — so cut to 6 MP, send an ROI, or return pass/fail only.

When the standard answer is wrong

• IT forbids a third-party device on the PLC subnet. Ship results as digital I/O plus Modbus RTU over RS-232 or RS-485: sixteen result bits, a four-bit command nibble and a heartbeat cover most sorting decisions. You lose data richness, not the sale.
• The line runs faster than ten parts a second. Full-frame GigE transfer sets the ceiling near 8 fps for 12 MP, so process in the controller and send decisions, not images, or move the backbone to 10GigE.
• The task is presence detection for guarding. That is a safety-rated sensor job, not vision; decline that scope regardless of architecture.

Checks before you quote the job

• PLC maker, model and firmware noted; protocol named; register map agreed in writing and versioned.
• Result deadline computed against part pitch for the worst-case frame size and camera count.
• Network card count at least three for camera, PLC and plant traffic; jumbo frames planned for the camera switch only.
• PoE budget checked when cameras take power from the controller.
• Trigger source and strobe channel count match the number of lights you will fire.
• Global shutter on every station where product moves during exposure.
• GSDML or EDS file, and a Modbus register list, in the deliverables.
• A spare camera and light on the shelf, and agreed response times for line-down events.

When the architecture is settled, start at the controller step of the configurator to match a box to your camera count and networks, or send the line details to the applications team and we will size the station with you.