Object detection on an industrial controller: sizing a CPU vision loop

You want detection to live where the PLC lives: one box that grabs the image, runs the model, and hands the verdict to the line controller over the network. The question that sizes the hardware is not whether a GPU is present but how many milliseconds the loop takes. This guide gives the planning numbers for a MobileNet-class detector on a vision controller's CPU: what one camera costs per frame, the latency budget on a 120 parts/min line, how many cameras one box carries, and the point where the job moves to an AI inference terminal. The code side - exporting the model, wiring the grab loop - already has its own walkthrough in object detection without a GPU; this page is the sizing that decides the order.

Can a vision controller run object detection on its CPU?

Yes, for the detector class most inspection tasks use: a MobileNet-class model at 300×300 input takes about 20 ms per inference on a Core i5-class CPU with ONNX Runtime, so a vision controller runs a triggered 2D detection loop without a GPU.

The reason is arithmetic, not acceleration hardware. A 300×300 MobileNet-class pass is roughly 1-3 GFLOP of fp32 work, and a modern Core-class CPU sustains 20-40 GFLOP/s with AVX2 vector units, which is what puts that pass near the 20 ms mark. Export the trained network once and the same ONNX file runs on the bench and in the cabinet; reported CPU benchmarks put a good runtime at around twice the training framework's own forward pass, so always time the exported file, never the training notebook. If OpenCV DNN and ONNX Runtime disagree on your hardware, the runtime comparison shows where the milliseconds hide, and ONNX detection on a camera stream in Python wires the session into a live grab loop.

What frame rate should I plan for per camera?

Plan 10-15 frames per second per camera once capture, preprocessing and the PLC handshake share the core with the inference: the 20 ms model call grows into a 65-100 ms full loop, and that loop time, not the model time, is what your inspection rate pays for.

The loop has six parts, and the small ones are not small together:

• Trigger and exposure: 2-20 ms, set by your strobe duration; a 5 ms LED pulse is a common choice.
• Transfer: image size divided by GigE throughput. GigE moves 1000 Mbit/s, about 125 MB/s on paper; 100 MB/s sustained is the honest planning figure, so a 2 MB mono 8-bit frame costs 20 ms.
• Preprocess: decode, crop and resize to the network input, 5-10 ms on one thread.
• Inference: about 20 ms for the MobileNet-class model.
• Postprocess: box decode and non-maximum suppression, 2-5 ms.
• PLC handshake: 5-10 ms for one register write.

The image_MB × 10 term converts megabytes to milliseconds at 100 MB/s. Summed, the parts land at 65-100 ms, hence the 10-15 fps figure. If frames pile up faster than the loop drains them, acquisition faster than processing lists the fixes, and the trigger has to be configured away from free run first - hardware trigger configuration per camera walks through that.

What latency does a 120 parts/min line allow me?

On a 120 parts/min line the takt is 500 ms, so give the vision station a 250 ms budget and expect the example loop to consume 68 ms of it, leaving 182 ms of margin for motion, jitter and a second camera.

The arithmetic, step by step:

• Takt: 60000 ms ÷ 120 parts/min = 500 ms per part.
• Vision budget: 500 ÷ 2 = 250 ms, leaving the second half of the takt to conveyor motion and the robot handoff.
• Loop: 5 ms exposure + 20 ms transfer (2 MB ÷ 100 MB/s) + 10 ms preprocess + 20 ms inference + 3 ms postprocess + 10 ms handshake = 68 ms.
• Margin: 250 - 68 = 182 ms, so the budget covers the loop 3.7 times over (250 ÷ 68 = 3.7).

How many cameras can one controller serve?

Budget one camera loop per physical core: at 68 ms per triggered part a core sustains about 14 fps, so a four-core i5-class controller serves three cameras at 120 parts/min and keeps the fourth core for the PLC traffic, the display and the logs.

Sequential is the honest model: three cameras triggered on the same part stack to 3 × 68 = 204 ms inside the 250 ms budget, which still fits on one core. Dedicated threads per camera are faster, but only if each keeps its own core - two loops sharing one core turn 68 ms into 90-130 ms and the takt quietly breaks. Port count matters as much as core count: one LAN port per camera keeps each camera's 100 MB/s to itself, and the PLC network belongs on a different port.

The workhorse class for this job is a Core i5 controller with PoE camera ports and eight built-in light channels.

How much resolution does the detector actually need?

Match the network input, not the sensor: a 5 MP camera viewing a 200 mm field gives 13 px/mm, but resizing the full frame to a 640 px network input shrinks a 2 mm defect to 6 px, so crop the part ROI before you resize.

The numbers behind that:

• Pixel density: 2592 px across a 200 mm field is 2592 ÷ 200 ≈ 13 px/mm.
• Full-frame resize to a 640 px input scales by 640 ÷ 2592 ≈ 0.25.
• A 2 mm defect spans 2 × 13 = 26 px at the sensor, then 26 × 0.25 ≈ 6 px inside the network - detectable, barely.
• Crop the part region first, say 600 × 600 px, and the same defect reaches the 640 × 640 input at roughly 1:1: 26 px stays 26 px.

The rule: if the smallest feature the model must see lands under about 10 px after the full-frame resize, crop the ROI first. Detection tolerates 6-10 px per feature; measurement wants ten times that, which is why the pixels-per-defect sizing for crack detection lands an order of magnitude larger.

How does the result reach my PLC?

Write one result register per camera to the PLC over Modbus TCP on the controller's second LAN port and budget 10 ms for the handshake; latching the verdict on the same trigger that fired the exposure keeps the result matched to the part.

One register per camera, written once per part, keeps the PLC side trivial: a single poll loop reads every camera, exactly the pattern in multiple vision cameras on Modbus TCP. Keep the camera subnet on its own LAN port so image traffic never shares the PLC's cable, and carry the frame number with the verdict so a rejected part is always the part that was photographed. The strobe belongs in the same box: firing the lights from a controller light channel shares the trigger timestamp with the exposure, so the image and the rejection refer to the same instant.

The MV-VC3301H-128G66 fits that layout as drawn: five or more LAN ports split the camera subnet from the PLC network, four built-in light channels fire the strobes, 8 GB of memory runs the model, and the VM6200Pro license is included.

Which controller fits one, three or six cameras?

Size by camera count and headroom: one camera at inspection rate takes an entry N-series box, two to four cameras at production rate take a Core i5 with PoE, and a model that exceeds 50 ms per inference on the CPU belongs on an AI inference terminal.

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

One camera doing presence and code-style checks is the VC2000-class entry: the N-series processor holds the loop at inspection rate, and the 1 TB HDD in that model exists for per-part image logs. Two to four cameras at production rate is the Core i5 class - the VC3000 and VC5000 series - where PoE and the fifth LAN port stop being luxuries. Six cameras is a different sum: 6 × 68 ms = 408 ms of compute against a 500 ms takt, so split the line across two controllers or step up to the Ultra 7 VC4000-class, which lists 16 GB×2 of memory and a 2 TB HDD.

For a single fixed view where the inspection can be taught or ruled on the device, check the smart cameras route before ordering a controller at all - AI vs rule-based smart camera inspection is the decision guide there.

When is a CPU vision loop the wrong choice?

A CPU loop is the wrong choice past roughly 250 parts/min per camera or once the model leaves the MobileNet class: 250 parts/min halves the per-part budget to 120 ms, and a 640-input network multiplies the compute by 6-15.

Three escalations, in the order they usually arrive. Rate: at 250 parts/min the takt is 60000 ÷ 250 = 240 ms and the half-budget 120 ms, so the 68 ms single-camera loop still clears with 52 ms to spare, but the two-camera stack at 136 ms does not. Model size: a YOLO-small-class network at 640×640 carries roughly 6-15 times the arithmetic of the MobileNet-class pass, turning the 20 ms call into 120-300 ms on the same silicon. Resolution: a 12 MP frame is about 12 MB, so transfer alone eats 120 ms of the budget before inference starts.

Past those lines the choices are the integrated accelerator or a general-purpose box. Outside the controller catalog the usual next step is a fanless industrial PC built around a discrete GPU - industrial mini PCs is that class of hardware. Inside the catalog, the decision is already made.

The MV-VAC3504X-128G01 is the integrated answer: a single-card AI inference terminal with five or more LAN ports, three to four USB 3 ports and four built-in light channels, so cameras, lights and PLC still land on one box.

What should I check before ordering?

Before you order, run the model export on the desk, not on paper: 100 warm inferences on the target CPU class tells you the real per-call time, and 68 ms measured against a 250 ms budget means the controller is safe to specify.

The order-day list:

• Time the exported model. Ten warm-up calls, then 100 timed inferences on the target CPU class; divide the wall time by 100. If they take 2.1 s, you have 21 ms per call.
• Count LAN ports as cameras + 2. One per camera, one for the PLC network, one for the service laptop.
• Decide PoE now. The PoE classes in the table remove a camera power supply each; non-PoE builds need injectors on the DIN rail.
• Match light channels to strobed lights. The classes carry four, six or eight built-in channels; one channel per strobed light is the count.
• Budget the log disk. Per-part image archives grow fast; the 8 GB + 128 GB SSD + 1 TB HDD layout on the entry VC2000 model exists for exactly that.
• Read the license line. The VC3000-class model includes the VM6200Pro license; the Ultra 7 VC4000-class ships without a VM license key - pick the line that matches how you deploy.

Size the class from the table, confirm the exact model on its category page, and if the camera is still open the camera finder filters by the resolution the section above set. When the benchmark lands inside the budget, build the system around that controller; when it does not, contact us with the model file and the takt - those two numbers decide it.