Develop 3D inspection without hardware: the record-once workflow

Most 3D inspection projects lose their schedule at the bench: the sensor is installed on a machine you can only reach during changeover, parts arrive in batches, and every tuning loop costs a walk to the line. There is a faster path. Record the sensor's height and intensity stream once, replay it into the same inspection software you will run live, and do the tuning, measurement set-up and regression testing against that fixed data. This guide gives you the workflow, the storage and speed arithmetic that sizes the recording, and the checks that tell you when an offline-built inspection will hold on the line. It is written for automation and quality engineers building inspections around laser profilers and structured-light 3D cameras.

Why build the inspection on recorded scans before touching live hardware?

Because a replayed stream is bit-identical on every run, you can tune tools, thresholds and tolerances against a fixed reference and re-run the whole test in seconds, while a live part never presents itself twice the same way.

The live loop is slow because every iteration needs the machine, the fixture, the parts and someone next to a live laser. The replay loop runs on your desk, on the same vision controllers you deploy at the line, and unattended in a test harness once you automate it. Tuning that ate a week of changeover windows shrinks to an afternoon plus one recording trip.

Some sensor vendors ship a virtual-sensor or emulator mode that runs their standard inspection interface over pre-recorded scans; if yours does, start there, because the same record-once discipline applies either way. For the wider toolset, see the options for machine vision development without a camera, and for fixture-level testing of capture code see record-and-replay fixtures for 3D camera code — that article targets acquisition code, this one targets the inspection job itself.

The decision is one line: if the sensor's output can be streamed to disk, develop offline and spend line time only on acceptance.

What do you record on the line to make replay faithful?

Record four things: the height and intensity stream, the trigger and encoder position of every profile, the exact sensor settings that produced it, and a calibration snapshot taken the same day — without the settings, the replay is a different measurement than the line made.

Height alone is not the whole measurement. Many tools read the 2D intensity channel for edges and surface features, and every threshold you tune is a function of the exposure, gain and laser settings in force at capture time. Store the settings export beside the stream and treat the pair as one artifact.

Gate the recording on the part-present trigger and log the encoder value with every profile, so replay reproduces the cadence of the production cell and not just the data. If your sensor records to a container that carries settings and metadata inside, use it — the H5 recording workflow for 3D cameras is one such pattern for offline processing. A plain header file works too, provided it names rate, layout, settings and calibration; the FAQ below lists what it must contain.

How much storage does a recorded profiler stream need?

A line profiler running 5,000 profiles per second with 1,920 points per profile and 4 bytes per point — 2-byte height plus 2-byte intensity — writes 38.4 MB/s, so a 10-minute capture is 23 GB.

The profile rate you need follows from conveyor speed and the resolution you want along the scan, so derive it before sizing anything — the line-scan line-rate calculator does the conversion:

High-rate systems change the strategy, not the formula. At 120 kHz with the same 1,920-point profile, the stream is 120,000 × 1,920 × 4 / 1,000,000 = 921.6 MB/s, or 3.3 TB per hour — continuous recording is off the table. Record bursts gated by the part trigger instead: a 0.5 s burst costs 921.6 × 0.5 / 1,000 = 0.46 GB per part, so a 200-part day adds about 92 GB. Onboard data reduction is what makes rates like this usable at all; see how onboard data reduction raises the usable profile rate.

The MV-HLVS-16K100-L60 is one such high-rate system: a line-scan 2.5D inspection system with 16K resolution, a 120 kHz sampling rate and a 600 mm emitting area, part of the 3D sensors range. Plug its rate into the formula above and burst recording stops being optional.

How fast must the replay machine be?

Your replay host must keep up with the recorded profile clock, and the arithmetic is unforgiving: at 5 kHz each profile allows 0.2 ms of processing, so a job that measures 0.8 ms per profile sustains only 1,250 profiles per second.

Replay makes this measurable with no hardware on the desk. Run the job over the reel at the recorded rate and count profiles processed against profiles due; the first backlog is your over-budget signal. Keep the measured per-profile cost at or below 70 percent of the budget — 140 µs of the 200 µs at 5 kHz — so operating-system scheduling and trigger jitter have room to land.

When the budget busts, the fixes scale the way the storage formula does. Cropping the ROI cuts points per profile roughly linearly. Lowering the profile rate to what the conveyor geometry needs cuts everything linearly. Moving first-stage tools to the sensor's onboard processing removes whole stages from the host job. If the controller is the bottleneck, a tier with more cores or a faster memory path is the remaining lever — buy it against the measured number, not a guess.

One caution about desk measurements: capture time reported by a viewer can be much shorter than capture time inside your own API, and network delivery adds latency replay never exercises. The capture-time gap between API and viewer is a common enough trap to have its own write-up.

How do you build the inspection job and a regression set from the reel?

Split the reel into known-good and known-bad segments, tune until every seeded defect fails and every good part passes, and freeze that pass/fail table as the regression baseline — a starting library of 100 to 200 scans per part family, grown every time the line shows a defect the set missed.

1. Record the master reel under production triggers, with the settings export and calibration snapshot stored beside it.
2. Segment the reel: known-good scans, parts with known defects, and boundary parts whose disposition a person confirms.
3. Build the job in replay — alignment anchors first, then measurement tools, then tolerances.
4. Run the whole reel: every known defect must fail, every good part must pass, every boundary part must land where the person said.
5. Measure per-profile compute cost in a continuous run and apply the 70 percent margin rule from the timing section.
6. Freeze the pass/fail table together with the reel's hash as the regression baseline.
7. Re-run after every job edit — nightly and automatic wherever your toolchain allows.

Start every run from a known state, because leftover settings from a previous job make results drift between runs; the known-state reset for flaky 3D camera tests shows the pattern. When a live part later fools the job, fix it, scan it, and add it to the reel. The regression set only grows.

What can replay never show you?

Replay proves the logic, not the station: laser drift, ambient light, encoder jitter and vibration are all frozen in the recording, so plan one live acceptance shift per recipe before release.

• Photometry drift. Laser output and detector response age. Thresholds tuned on a month-one reel can sit in the wrong place by month six, so re-check against live scans on a fixed cadence and re-record after any optics or exposure change.
• Trigger and encoder realism. The replayed trigger is the trigger you recorded, with no missed parts, no speed variation and no double-triggers. Rehearse bad days by replaying segments out of order and at edited rates.
• Vibration. The reel carries the vibration of its recording day only; live motion adds new signatures. Vibration correction in 3D height scans covers what that does to height data.
• Unseen defects. A regression set proves behavior on defects you have already seen. Pilot runs and first articles stay live, always.

Close the loop with that one live shift: run the job at the station, compare its pass/fail table against the reel's table, and log every disagreement with its cause. After the shift, the reel is your regression suite and the line is only for changeover-time re-validation.

Which hardware records the reel?

You need three things: a sensor you can stream from, a controller whose disk sustains the write rate with margin, and the same trigger wiring the production cell uses — a reel recorded on temporary wiring is a reel of a different machine.

The recording rig is mostly a disk question, because current profilers stream over their network link. Size the drive on sustained writes with a factor-of-two margin, and keep reels on an SSD partition: mechanical drives lose write speed as they fill, exactly when your library is largest. The MV-VC4712-256G10-2TH pairs a 256 GB SSD with a 2 TB HDD and PoE camera ports, so one box can link the sensor and hold the archive. At the continuous 5 kHz hourly rate from the storage section, the 2 TB drive holds about 14 hours before archiving.

Two controller sizes cover the recorder roles:

The MV-VC2140-128G40-1T covers the compact end of the range, with a 1 TB HDD for the reel library.

A bench recorder can be as simple as a 3D laser profile sensor such as the MIS-DP3850-01P, streamed over its network link straight to the controller's disk.

Profile sensors are not the only source. A projected structured-light camera such as the MV-DPS200P-02 records one height map per trigger, so storage scales with part count rather than wall time, and the same record-once, replay-offline discipline carries over unchanged.

What do you check before you trust an offline-built inspection?

Run the reel twice and require 100 percent agreement between the two pass/fail tables — any difference means hidden state in the job, and hidden state on the line becomes flaky rejects you cannot reproduce.

• Settings identity. The settings export stored with the reel is the one the job assumes; a hash mismatch means every threshold was tuned against data it does not match.
• Zero dropped profiles. Scan the capture log for gaps before the reel becomes the baseline; a dropped profile inside it becomes a phantom defect signal on every future run.
• Two identical runs. The pass/fail tables agree exactly, down to the measurement values, not just the pass flags.
• Compute margin holds. The per-profile cost from a continuous fixed-rate replay sits within the 70 percent margin rule — scrubbed runs hide timing.
• Calibration current. The calibration snapshot's date falls inside the recipe's calibration interval.
• Live acceptance logged. The one-shift comparison is done, and every live-versus-reel disagreement has a written cause.

When the arithmetic says the rig is ready, filter profilers by rate and resolution in the 3D camera finder, or spec the recording rig end to end in the vision system configurator. If your storage or timing numbers sit outside the ranges in this guide, send them through the contact page and we will size the recording with you.