Image processing on a PLC: what a controller can realistically handle

A PLC platform that can host user code raises a tempting question: should the controller do the vision too? The honest answer separates two jobs. Coordinating a camera — trigger, handshake, result, archiving — is exactly what a controller does well. Reading pixels is not, and the arithmetic shows why: one 2 MP mono frame already takes about 20 ms to cross a GigE link at a practical 100 MB/s, before a single algorithm runs. This guide gives you the transfer-time formula, a per-resolution table, a worked cycle budget and the decision rule for where each job belongs on a PLC-based line.

The decision: pixels on the vision device, coordination in the PLC

A controller is built for millisecond discipline: fixed logic, deterministic I/O, predictable scan behavior. A loop that touches millions of pixels has none of those properties. So the split follows that boundary. Every step that reads pixel values — decoding, filtering, thresholding, matching, measuring — runs on a vision device. The PLC owns the discrete world: part-present interlocks, triggers, reject actuation, recipes, and what happens after the result arrives.

Bandwidth says the same thing. A 2 MP mono frame is about 2 MB on the wire; a typical inspection result is 16-64 bytes. Per inspection that is a gap of roughly 60,000×, and the small payload is the one a control network is designed to move.

There is also a software boundary. Vision libraries decode Bayer data and run filters and template searches down to SIMD instructions; generic controller code has none of that stack. Rebuilding a blob analysis from scratch on a controller CPU turns tens of milliseconds into hundreds.

The decision rule in one line: pixels on the vision device, coordination in the PLC, results across a handshake. The vision controllers class exists for exactly this split, and standalone smart cameras cover the cases where the second device disappears entirely.

What image processing on a PLC can cover

Handled well in the controller:

• Trigger and handshake timing, in the five-signal pattern below
• Reject actuation, divert and line-stop logic on the result
• Recipe and part-number switching before the trigger fires
• Result buffering, counting, statistics and reporting upward
• Image archiving: moving, renaming and deleting files on a retention schedule
• Operator display through the device's own image path

A five-signal handshake keeps the camera exchange deterministic, and the same five names appear in most integration guides:

Send the values in a fixed-format telegram and the PLC program stays simple; sending vision results to a PLC over a fixed-position telegram shows the message layout. Where no network handshake exists, two discrete outputs — pass and fail — still carry the decision at modest line rates. For what the operator sees on screen while this runs, what a smart camera image actually displays in a PLC HMI separates the live view from the per-cycle frame.

The transfer-time arithmetic that sets the limit

Two lines of arithmetic size any camera-to-device link:

Bytes per pixel follows the wire format: 1 for 8-bit mono or raw Bayer, 1.5 for 12-bit packed, 3 for decoded RGB.

A Gigabit link moves 1,000 Mbit/s, which is 125 MB/s before overhead. GigE Vision packet headers, protocol handling and driver copies cut into that; jumbo frames claw some back. Plan on 100 MB/s per stream, with about 118 MB/s as a well-tuned best case.

Worked example, 2 MP mono: 2,000,000 pixels × 1 byte = 2,000,000 bytes. At 100 MB/s that is 2,000,000 ÷ 100,000,000 = 0.02 s = 20 ms of transfer. Add a 5 ms exposure and the camera holds the link for about 25 ms before the first algorithm runs.

Where the arithmetic leaves the PLC behind

Consider what happens if the controller pulls the frame and processes it anyway. A controller-class CPU moves main memory at a few GB/s, so one full pass over a 5 MB frame costs roughly 1-5 ms. Matching and measurement algorithms make dozens of passes over the frame, so tens to hundreds of milliseconds per inspection is the realistic range — inside a program that also owes you deterministic scan behavior. Processing time scales with frame size and with the number of passes an algorithm makes over it; this walkthrough of machine-vision processing time versus image size works through the same arithmetic from the controls side.

A network (IP) camera stream changes nothing: a stream is capture, not processing. Something still has to decode and analyze every frame, and that something needs the image stack.

Multi-camera systems raise the same math per port. The same 100 MB/s per-stream budget decides feasibility before processing is even discussed; the bandwidth budget for two GigE cameras on one host shows the per-port math.

The three architectures that work

Three patterns cover nearly every PLC-based line.

Pattern 1: the camera decides, the PLC acts

A vision sensor or smart camera carries sensor, lens, light and processor in one housing, makes the accept-or-reject decision on board, and hands the PLC a result. The PLC fires the trigger, actuates the rejector and keeps the counts. No image data ever enters the control network, which is what keeps the cycle deterministic. Three devices cover the common cases.

The MV-SCB007EC-12S-WBN is the mono entry: 1.6 MP, a built-in 12 mm lens with manual focus, global shutter, Fast Ethernet and an M12 mount. The MV-SC3050XC-16M-ATN-H adds color: 5 MP on a 1/1.45" sensor with global shutter, Fast Ethernet and an M12 mount. The MV-SC5060XM-08M-WBN steps up to GigE: 6 MP mono with an 8 mm lens and an M12 mount.

The interface choice matters as much as the sensor. Fast Ethernet tops out at 100 Mbit/s, about 12.5 MB/s, so a 6 MB frame takes close to half a second on it; GigE cuts that to about 60 ms. The camera finder filters smart cameras and vision sensors by interface, resolution and lens mount.

Pattern 2: a vision controller in the panel, results to the PLC

A fanless vision controller mounts in the panel, takes the cameras on its LAN ports, drives strobed lights from built-in channels and runs the vision software; the PLC keeps machine control and consumes results. Nothing in the PLC program changes when the inspection gets heavier — only the controller does. The catalog ladder runs from entry to PoE.

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 is the entry point, with 4 built-in light channels and a 1 TB HDD that serves image archiving. The MV-VC3301H-128G66 steps up to an Intel Core i3, 5+ LAN ports, PCIe expansion and the VM6200Pro vision software license included. The MV-VC5525-256G70-NN brings PoE camera ports, 8 built-in light channels, 32 GB of memory and PCIe expansion.

Built-in light channels also remove a separate light controller from the panel; the RGB, UV and IR test bench guide works the channel power and timing arithmetic.

Pattern 3: file-based inspection and archiving

The third pattern moves images as files. The camera or vision device saves a full image on each trigger to a network share, named by serial number or timestamp; the controller moves, renames and deletes files on a retention schedule. Analysis runs offline or in a scheduled batch: end-of-shift defect mapping, audit trails, collecting training sets for AI models. It scales to any resolution because nothing in the cycle waits on it. What it cannot do is reject the part in front of the camera — that decision still needs a vision device in real time.

A worked cycle budget

Case 1: a line at 60 parts per minute has 1,000 ms per part. Camera: 2 MP mono, exposure 5 ms, transfer 20 ms (2 MB ÷ 100 MB/s). Processing: as a planning figure budget 20-50 ms for template matching plus blob analysis on a 2 MP frame; take 30 ms here and replace it with a measured number after the first day on the machine. Result exchange: one handshake cycle, typically 1-10 ms. Total: 5 + 20 + 30 + 10 = 65 ms, about 7% of the cycle. The design margin — keep the whole vision task under half the available time — clears with room for a second inspection point.

Case 2: a faster line at 3 parts per second has 333 ms per part, and the camera is 12 MP color decoded to RGB on the wire. Frame size: 12,000,000 pixels × 3 bytes = 36,000,000 bytes = 36 MB. Transfer: 36 ÷ 100 × 1,000 = 360 ms, which is larger than the entire cycle before processing even starts. Fix it in this order: switch the wire format to raw Bayer, which drops the frame to 12 MB and the transfer to 120 ms; then re-check the resolution against the smallest defect, because the pixel rule often shows the 12 MP sensor was never needed.

A 0.25 mm defect inspected at 2 pixels per defect needs 0.125 mm per pixel. A 1,920-pixel-wide sensor — the usual 2 MP format — at that scale covers 1,920 × 0.125 = 240 mm of field. So a 2 MP camera does that job, at 20 ms of transfer instead of 360 ms. Sizing camera resolution by the pixel rule runs the general case.

When acquisition is inherently faster than processing, the backlog grows until frames drop; when acquisition outruns processing shows how to find and close that gap.

Checks before you commit

• Compute frame size as resolution × bytes per pixel and divide by the link's practical bandwidth: 100 MB/s per GigE stream.
• Confirm the camera's wire pixel format — raw versus decoded — before sizing anything.
• Add exposure, transfer and a measured processing figure from the vision device; planning figures get replaced after day one.
• Add 1-10 ms for the industrial protocol update cycle.
• Keep the whole vision task under half the cycle time.
• Count LAN ports against cameras, check PoE, and check built-in light channels against the strobed lights.
• Decide the archive path up front: which device saves images, where they land, how they are named, how long they stay.

When the usual answer is wrong

Heavy AI inspection is the first exception: convolutional networks need accelerator-class hardware, and a controller CPU will not run inference inside a production cycle. A single-card AI inference terminal such as the MV-VAC3504X-128G01 takes the cameras with 5+ LAN ports, adds 3-4 USB 3 ports and 4 built-in light channels, and keeps the same PLC handshake.

Ultra-low-rate checks are the second: one inspection every few seconds on a small region needs no handshake network at all, and a smart camera with two discrete outputs does the whole job. Multi-camera 3D is the third; offloading 3D inspection processing to a vision controller covers the point-cloud case.

The whole sequence: size the frames with the transfer formula, put the pixels on a vision device, keep triggers and results in the PLC, and leave safety on its own hardware. Start from the controllers topic page for the surrounding guides, or contact the applications team with your camera count and cycle time.