Point cloud with normals timeout: capture time and compute time

You request a point cloud with normals, the grab call blocks, then throws a timeout error — yet the same camera hands over XYZ in a fraction of that time once the normals and intensity components are disabled. The camera is almost never at fault. A normals-enabled grab is two operations back to back: the capture the sensor performs, then a host-side pass that estimates a normal vector for every point on your CPU. This guide splits the two timings, sizes the grab timeout from a measured worst case, and works through the three fixes: a bigger timeout, a smaller cloud, or normals computed in your own pipeline.

What the symptom rules out

A successful XYZ grab clears the camera, the trigger, the cable and the SDK installation. The failure appears only when the normals component is enabled, so the added host work is the first suspect, not the link.

Run the isolation test before anything else. Grab XYZ plus intensity with normals off. If that succeeds and the timeout returns when normals come back on, the compute pass is the cause and every fix below applies directly.

One-shot captures behave the same way: the call waits for the whole operation to finish. The capture-side version of that arithmetic is covered in software trigger image timeout: why one-shot capture misses frames.

The grab is two operations: capture, then normal estimation

With normals enabled, one grab call runs three stages in sequence: capture and encode the cloud at the sensor, transfer it across the link, then estimate a normal vector for every point before the call returns. Capture time follows camera parameters such as exposure time and encoding mode. Normal estimation time follows your computer, because each vector comes from a nearest-neighbor search around the point plus a local plane fit over that neighborhood — work that grows with the number of points.

A useful reference figure: with a default parameter set on a typical desktop PC, a full capture-plus-normals grab took about 2.6 s end to end. That total, not the capture alone, is what the timeout has to cover.

The payload grows too. XYZ alone is three 4-byte floats per point, or 12 bytes. With normals and intensity the same cloud carries about 28 bytes per point — more transfer time and more allocation on the host.

Laser profilers and structured-light 3D sensors produce the XYZ cloud at the sensor; the normal pass runs entirely on the host PC that receives it.

The 3D sensors category groups these by type — laser profiler, structured light, ToF — and the camera finder narrows the list by series and availability.

Likely causes, in order of probability

Work down the table in order; each test takes a minute or two.

Worked example: sizing grab_timeout for a 2.6 s normals grab

Inputs:

• Worst measured normals-enabled grab t_grab_worst = 2.6 s, taken as the largest of ten timed runs with default parameters on a typical desktop PC.
• Margin rule: set the timeout to at least twice the worst measured grab. The doubling assumes the production PC runs another task alongside the grab, starts cold after power-up, or simply has slower cores than the measurement machine — any of which stretches the compute pass.

Arithmetic: 2.6 s × 2 = 5.2 s, so set grab_timeout to 5,200 ms; where the API steps in whole seconds, 6 s.

Decision: below 2.6 s of budget, every normals-enabled grab fails. Between 2.6 s and 5.2 s, grabs pass on a quiet PC and start failing the moment anything else loads the CPU. At 5.2 s or above, the grab survives a busy host. Re-run the ten timed grabs after any change to resolution, exposure, encoding mode or host PC, because the budget moves with them.

Fix 1: set grab_timeout past capture plus compute

The direct fix is the timeout itself. The setting lives in the grab call of your vision library — grab_timeout in the obtain_point_cloud_with_normals example program, set before you call grab_data. Enter the value in the unit the parameter documents; most libraries take milliseconds.

A timeout decides only how long the call waits, never how fast the compute runs. If the cycle tolerates a 5.2 s call, this fix is complete. If the inspection rate cannot spare the time, the compute itself has to shrink — that is the next two fixes.

Fix 2: cut the point count before normals run

Normal estimation cost tracks the point count, so cloud size is the lever with the most reach. Halve the resolution and the pass typically takes about half the time; crop to the region the inspection actually grades and estimate normals only inside it.

Changing resolution at capture time is a documented operation on most 3D sensors: see changing depth resolution and field of view at capture time and the X, Y and Z resolution settings that keep the cloud undistorted.

Fix 3: grab XYZ only and compute normals in your own pipeline

Request XYZ — plus intensity where you need it — in the grab, and run normal estimation as a separate step in your own code. The grab call then returns at capture speed, grab_timeout never has to cover the compute, and the normal pass runs where you schedule it: a worker thread, a batch after the run, or another machine altogether.

The trade is that you own the normal code path: you choose the neighborhood radius or neighbor count, and edge behavior changes with that choice. For inline inspection where every cycle needs normals, keep the pass on the station PC and parallelize it; for offline measurement, batch it and let the cores work through the queue.

Prevention: budget the host, not just the camera

Re-time the grab after every parameter change and keep the worst case in the station log. A change that looks optical — longer exposure, finer resolution, multi-exposure capture — moves the compute budget too, because it hands the normal pass more points to fit.

A filter or a second camera stream on the same PC competes for the same cores; the guide on point cloud filters that slow the depth camera measures that competition.

Treat the host as part of the machine design when normals run every cycle. The vision controllers in the catalog are built around multi-camera capture plus algorithm load, not office duty.

As a concrete anchor, the MV-VC5525-256G70-NN pairs a 12th-gen Intel Core i5 with 32 GB of memory and PoE camera ports — the class of host a normals-per-cycle station needs.

Sizing a new station? The configurator's controller step walks ports, memory and light channels in one pass.

When a bigger timeout still fails

If a 30 s timeout still expires, compute time is no longer the explanation. The list changes:

• Firmware and SDK mismatch: a normals component the firmware cannot fill stalls the grab instead of failing early. Re-align versions per the firmware and SDK alignment check.
• Stalls under load: the grab hangs mid-transfer rather than waiting on compute; the acquisition stalls under load guide walks the recovery split.
• Link saturation: extra components raise bytes per point, and a marginal cable or switch drops below the needed rate. Start with diagnosing stream failures on the transfer side.

Only trim the timeout once ten timed grabs sit comfortably inside it — and never below twice the worst measured grab.

Next step: set a 30 s timeout, time ten normals-enabled grabs, and put the worst case into the formula above. The 3D vision topic page collects the other point-cloud guides; if a station log still refuses to fit the cycle, bring it to the contact page and we will read it with you.