Offload 3D inspection processing to a vision controller

A 3D laser profiler or stereo camera does not hand you a finished result. It hands you a stream of profiles or depth frames, and something has to turn that stream into an accepted or rejected part, every cycle, on time. When that something is the same PC that runs your operator interface, shift reports and plant links, cycles stretch at the worst moments. What follows is where the 3D processing load actually goes, how to size a dedicated vision controller for it, and when the existing PC is still the right home for the work.

What offloading 3D inspection processing means

Offloading means drawing a hard line between two groups of jobs. The controller takes acquisition, profile-to-point-cloud assembly, alignment, feature measurement, pass or fail logic and the PLC handshake. The PC keeps everything a human touches: the operator interface, image and cloud archives, shift reports and the route into plant networks.

It is not the same thing as on-sensor processing. Modern sensors preprocess heavily before anything leaves the camera, and what a sensor itself can offload is worth checking first. Move to a controller what the sensor cannot finish inside its own scan budget: multi-sensor fusion, reference alignment, full-geometry comparison, custom measurement routines.

Where the 3D processing load actually goes

Take a mid-range profiler as the example and state the assumptions: 1,920 points per profile, 6 bytes per point (a 4-byte float height plus a 2-byte intensity), 1,000 profiles per second.

• Per profile: 1,920 × 6 = 11,520 bytes
• Stream: 11,520 × 1,000 = 11.52 MB/s, about 11.5 MB/s
• On the wire: 11.52 × 8 = 92.2 Mbit/s
• Per 8-hour shift: 11.52 × 3,600 × 8 ÷ 1,000 = 331.8 GB, call it 332 GB

A Gigabit Ethernet link moves roughly 110 MB/s of payload in practice, so this sensor fills under a tenth of its link. The network is almost never the bottleneck in a 3D cell; the CPU time and RAM that assembly, alignment and measurement consume are, and they scale with points per second, not with link speed. A second camera doubles every line of the arithmetic.

At the far end of the range, the MV-HLVS-16K100-L60 line-scan 2.5D system pairs 16K resolution with a 120 kHz sampling rate across a 600 mm emitting area. Streams at that scale are exactly why the class does its heavy work at the sensing head and hands on processed data rather than raw points.

If the part travels on a belt, the profile rate is not a free choice: belt speed divided by the resolution you need along the travel direction sets it. The line-rate calculator below does that sum, and its result feeds the stream formula.

Memory grows just as quietly. One full part scan from the example sensor, 2,000 profiles at 1,920 points, is 3.84 million points; at 6 bytes per point that is 23 MB per scan. A rolling buffer of the last 100 scans for rework disputes costs 2,304 MB, about 2.3 GB, before the application has allocated anything else. If coarse shape or occupancy is all you need, a voxel grid store cuts the per-scan cost well below that raw figure.

Why the shared PC stalls

The stream arrives whether the PC is ready or not. A general-purpose desktop gives every process a fair share of the cores, so cloud assembly competes with the window system, the disk writer and whatever the office opened over the network. Buffers fill while cores are busy elsewhere. The visible symptoms are jittery cycle times, clouds that lag the trigger, and frames that drop exactly when someone opens the viewer. The failure has a dedicated diagnosis path, and the gap between grab rate and processing rate is its own frame-rate problem with known fixes.

The stretch is predictable arithmetic. Take 20% of the core time away from a 1.5 s assembly stage and it runs 1.5 ÷ 0.8 = 1.875 s, about 1.9 s. Nothing errors. The cycle quietly loses margin until the day it loses a part.

What a vision controller changes

A vision controller is a fanless industrial computer built for this split: no desktop, no browsing, a runtime that starts with power and does one job. It mounts near the sensors on short cable runs, and its port layout exists to keep traffic apart, so camera links, PLC link and office uplink never share a switch.

On some models the split is printed in the port names. The MV-SVC2506-16G60-128G gives 4 camera GigE ports, 1 configuration GigE port and 1 communication GigE port, with 16 GB of memory.

For a two- or three-camera cell the MV-VC5525-256G70-NN is the stronger fit: PoE camera ports, 5+ LAN ports, a 12th-gen Core i5, 32 GB of memory, a 256 GB SSD and 8 built-in light channels, so the illumination wiring lands on the same box as the timing.

The controller also owns the line conversation. Results leave over industrial protocols with a handshake the PLC can trust, which is the territory of the vision controller Modbus integration guide, and grab, output and latch order is what event sequencing for deterministic inspection pins down.

The sensor side of the pairing does not change: a 3D laser profile sensor feeds profiles, and the controller turns them into results.

Sizing the controller: the cycle budget

Work the budget before looking at hardware. Example line: 15 parts per minute, a 4.0 s cycle. Stage times on the controller: acquisition and sensor handoff 0.8 s, cloud assembly 1.5 s, twelve-feature measurement 0.7 s, result to PLC 0.2 s. Total 0.8 + 1.5 + 0.7 + 0.2 = 3.2 s, which leaves 0.8 s of margin, 20% of the cycle.

Run the same stages on a shared PC carrying the 20% background load from the last section: 0.8 + 1.9 + 0.9 + 0.2 = 3.8 s. Margin falls to 0.2 s, and a single backup job ends the run. That is the decision in one line of arithmetic, and it is why the stage times, not the spec sheet, drive the purchase.

Hold a dedicated processing box to a 25-30% margin floor, more if more cameras or models are expected to land on it later. For memory, add working set and buffer: three copies of the 23 MB cloud (raw, aligned, meshed) cost about 70 MB, the 2.3 GB rolling buffer brings the base under 3 GB, then add roughly 2.5 GB per extra camera stream and the footprint of any neural model. Controllers ship with 8, 16 or 32 GB of memory, and that arithmetic, not habit, picks the size.

An entry single-camera cell needs none of that headroom. The MV-VC3301H-128G66 runs an Intel Core i3 with 8 GB of memory and a 128 GB SSD, offers 5+ LAN ports and PCIe expansion support, includes the VM6200Pro license and has no PoE.

When a trained defect model joins the loop, put it on inference hardware beside the controller. The MV-VAC3504X-128G01 is an AI inference terminal in single-card format with 5+ LAN ports for the camera and line networks.

Multi-stream cells deserve their own pass: the multi-camera 3D throughput planner walks that arithmetic, and swapping a neural network model on edge vision hardware covers getting a trained model onto the line with a rollback path.

When offloading does not pay

Three cases keep everything where it is. First, sensors that finish the job themselves: if the profiler emits measurements rather than points, there is nothing to offload. Second, low duty: a ToF sensing camera such as the MV-DT01WMU produces one depth frame per part, and a host barely notices. Third, slack: one camera, small clouds, and a measured margin above 30% on the existing PC with nothing more planned for that box.

Checks before you move the processing

• Measure the stage times on the bench with real parts and the real model; the worked numbers above plan the cell, and the stopwatch buys the hardware.
• Recompute stream, wire load, shift volume and memory from your own points per profile and profile rate; each formula above is one line.
• Count ports on paper first: cameras, PoE or separate supplies, trigger in, light channels, PLC link, office uplink.
• Fix the network plan: camera links on their own ports, PLC and office separated, addresses static.
• Write the recovery before the first run: heartbeat bit to the PLC, automatic restart of the runtime, boot straight back into inspection after a power cut.
• Split the archive on purpose: the rolling buffer the controller keeps for rework, the long-term images and reports the PC keeps.

The decision

Keep the processing where it is when the sensor emits finished measurements, when a single low-rate depth camera covers the cell, or when the measured margin on the existing PC stays above 30% with nothing further planned for that box.

Offload to a dedicated vision controller when profiles stream continuously, when two or more 3D cameras share the cell, when a trained model runs in the loop, or when the budget lands under a 25% margin, as the 4.0 s example does on a shared PC at 3.8 s.

At 16K-class line rates, split the work instead of moving it: heavy processing stays at the sensing head while a controller owns results, timing and the line network.

Start on the vision controllers page, filter the sensor side in the 3D camera and sensor finder alongside the 3D sensors category, or step into the system configurator. If the margin arithmetic lands close, bring the stage times to the contact page and we will check them against the hardware with you.