Ask why one 3D laser profiler tops out near 2 kHz while another sustains the fastest class near a hundred times that, and the answer is rarely the laser. It is the data path. A triangulation profiler produces one height profile per sensor frame, so profile rate and pixel rate are the same problem: a 3072-column imager read in full frames at the top rates would move about 664 Gpixel/s. The fast sensors find the laser line on the imager itself, transfer only the band of rows around it, and ship one height per column. Below is the arithmetic at each stage — readout, extraction, Ethernet — and the speed class it says you should buy for a given line speed and point pitch.
What a profile rate measures
A laser profilometer takes one profile per frame. The projector paints a line across the part, the objective images it onto a 2D CMOS array, and the height at each column shows up as a shift in the row where the line lands. Columns measure position along the line; rows encode height through the triangulation angle. The honest way to compare profilers is therefore points per second: columns × profile rate. A 2k-point sensor at 5 kHz gives 10 Mpoints/s; a 3k-point sensor at the top rate gives 614 Mpoints/s. That 60× spread sets the smallest defect you can catch at line speed in work like surface defect detection with a 3D laser line profiler.
The data wall: full frames stop near a few kilohertz
Read the whole sensor and the arithmetic turns hostile. A 3072 × 1080 imager at the fastest extraction-based rate of 200 kHz is 3072 × 1080 × 200,000 ≈ 664 Gpixel/s. A modern CMOS camera reading its full sensor runs at up to about 500 fps — roughly 1.7 Gpixel/s at this frame size — which buys about 500 profiles/s if you build a profiler around it. Purpose-built profiler sensors read out faster and publish full-frame scan rates in the roughly 2-6 kHz class. From there to the top extraction class is a factor of 30 to 100 that no readout clock closes. Reading fewer rows per profile is the only route, and that is a data-reduction decision, not a sensor-speed one.
Onboard extraction: move the band, then the line
High-rate profilers cut the data twice, close to the silicon:
- On or beside the imager, each column block finds the rows the laser line lands on and passes on only a band around it — tens of rows, not the full height. A 64-row band on a 1080-row sensor is a 1080 ÷ 64 ≈ 17× cut.
- Firmware computes a sub-pixel center of the line for every column. The quality of that center sets your height noise, which laser line extraction noise: get a clean height line covers in detail.
- What leaves the sensor is one number per column — a 16-bit height, plus intensity — instead of 3072 × 1080 pixels. That is the full 1080× cut, three orders of magnitude.
Running step 2 in host software on full frames is possible, but you inherit the 500 Hz to 6 kHz wall above and spend CPU on gigapixels the profiler throws away on silicon. If acquisition then outruns your processing, the extra rate buys nothing — the pattern to watch is acquisition faster than processing: fix the frame rate gap.
Worked example: sizing the data path for 3072 columns at the top rate
Inputs:
- Sensor: 3072 columns × 1080 rows, a representative fast-profiler imager — swap in your own width and height.
- Target rate: 200,000 profiles/s (200 kHz), the class of the fastest extraction-based profilers.
- Band: 64 rows around the line.
- Output: 16-bit height per column, with intensity left out of the budget.
- Usable link payload: about 115 MB/s on 1 GigE, about 1.1 GB/s on 10 GigE.
The rule in words: at every stage, multiply what one profile moves by the profile rate, then compare the result with what that stage can carry.
- Full frame: 3072 × 1080 = 3,317,760 pixels; × the target rate = 663,552,000,000 ≈ 664 Gpixel/s. Camera-class readout near 1.7 Gpixel/s delivers about 500 profiles/s. That is the wall.
- Band: 3072 × 64 = 196,608 pixels; × the target rate ≈ 39.3 Gpixel/s from imager to processing — the 17× cut the sensor's parallel readout is built around.
- Heights out: 3072 × 2 B = 6,144 B ≈ 6 kB per profile; × the target rate = 1.23 GB/s ≈ 9.8 Gbit/s.
- 1 GigE: 115,000,000 ÷ 6,144 ≈ 18,700, so about 18 kHz of full-width profiles.
- 10 GigE: 1,100,000,000 ÷ 6,144 ≈ 179,000, so about 180 kHz.
Decision: above roughly 18 kHz at full 3k width, 1 GigE is short by an order of magnitude — specify a 10 GigE-class link. At the target rate even 10 GigE runs about 10% short with 16-bit heights, so ship 8-bit heights (3072 B × the target rate = 614 MB/s ≈ 4.9 Gbit/s, comfortable) or average adjacent profiles in the sensor (half the rate × 6,144 B = 614 MB/s, same budget, and averaging also lowers height noise).
The receiving end needs the same bandwidth
A 10GigE or XoFLink profiler deserves a port that keeps up, and several profilers can share one card: the frame grabbers range covers both. The MV-GS1104F-DF is an XoF frame grabber with 4 ports, an SFP+ slot and 40G total bandwidth supported. For a single camera, a dual 10GigE NIC is the usual choice. The same payload arithmetic, applied to standard GigE Vision cameras, is worked through in how much frame rate fits on GigE Vision.
- Interface
- XoFLink
- Ports
- 4 ports
Scan speed: profile rate becomes point spacing
Along-scan spacing is line speed ÷ profile rate. At 0.5 m/s that is 250 µm at 2 kHz, 28 µm at 18 kHz and 2.5 µm at the top rate. Match it to the cross-line pitch, field of view ÷ columns: 100 mm over 3072 columns is 32.6 µm. A square point cloud at 0.5 m/s then needs 0.5 ÷ 32.6 µm ≈ 15 kHz — faster oversamples, slower stretches the cloud, the failure mode laser triangulation scan spacing: prevent stretched clouds diagnoses. At that pitch the top rate supports up to 32.6 µm × 200 kHz ≈ 6.5 m/s of web. Trigger from an encoder so spacing holds through speed changes, set the scale as encoder ticks per pixel for line scan shows, and follow the rate logic in how to set the line rate of a line scan camera.
Light and laser safety at high rates
Exposure per profile is the line period, 1 ÷ rate: 500 µs at 2 kHz, 5 µs at the fastest rate. Collected light scales with exposure, so the same optics gather about 100× less light per profile at the top rate than at 2 kHz, and fast heads make that up with higher-power lasers. On the intensity side the classic answer is TDI, integrating over several sensor rows while still reading at line rate: the LS-LCM-0016 is a 2K GigE line scan camera with 7 μm pixels that runs 58 kHz with TDI. Binning trades the same corner, as pixel binning on a line scan camera: more light, same speed lays out.
Choosing a speed class
| Class | What moves per profile | Rate you get | Buy it when |
|---|---|---|---|
| Full-frame output | every row of the sensor | 2-6 kHz | slow or indexed parts, coarse pitch, host software does the math |
| Onboard extraction | a row band, then one height per column | 20-200 kHz | conveyors and webs above about 0.2 m/s, or pitch below about 50 µm |
| Line-scan 2.5D | onboard-processed height line | up to the 120 kHz class | continuous wide webs needing height and intensity together |
Committed per case: static or indexed parts under about 0.2 m/s — the 2-6 kHz class is enough, and your money is better spent on Z resolution and calibration. Lines from 0.2 to 1 m/s with pitch at or above 50 µm — a 20-25 kHz extraction profiler over 1 GigE. Above 1 m/s, or pitch below 30 µm — the 100-200 kHz class with a 10 GigE-class link shipping 8-bit or averaged heights. In the 3D sensors category, laser profile sensors such as the MIS-DP3850-01P and MV-DP4180-03P carry that extraction path from imager to Ethernet:
- Type
- Laser profiler
- Type
- Laser profiler
For continuous webs, 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.
- Type
- 2.5D inspection
When a faster profiler is the wrong buy
Rate is the wrong axis when the part stands still: a structured-light or stereo 3D camera measures a stationary target in one exposure, and the top rate buys it nothing. It is also the wrong axis for mirror finishes — a specular surface throws the line off the sensor or saturates it, and no rate fixes geometry; change the illumination instead, the way lighting for fabric defect detection does for flat webs. Deep steps shadow the line at steep triangulation angles, which is an angle choice, not a rate choice. And paying for 10 GigE and a Class 3B source to sample 2.5 µm along a 33 µm pitch wastes most of both. For flat, fast webs the honest comparison is a laser profiler versus a 2D vision system for hole detection.
Checks before you order
- Working distance and field of view against your tallest part — the 3D camera working distance and positioning guide sets these first.
- Height range inside the active band, with margin for part tilt.
- Triangulation angle against your deepest step: shadows are permanent.
- Laser class against your enclosure and interlock hardware.
- Link budget at your real width and bit depth — the worked example's arithmetic, not the headline rate.
- A port that keeps up: a 10GigE NIC or an XoF card from the frame grabber range.
- An encoder input on the sensor, so spacing survives speed changes.
- A calibration plan, because a tilted cloud costs accuracy that no profile rate buys back — why a laser triangulation point cloud is tilted is the check sequence.
Work through width, bit depth and rate in the system configurator, or compare line scan cameras when a 2D intensity channel matters as much as height. For a spec review of your line, use the contact page and bring the line speed and the pitch you need.
Questions
Why does a laser profiler reach the top profile rates when my area camera stops near 500 fps?
Because the profiler never moves whole frames. It finds the laser line on the imager and transfers only a band of rows around it, then ships one height per column — about a 1000:1 data cut on a 3072 × 1080 sensor. Your area camera must read every pixel of every frame, so a readout near 1.7 Gpixel/s at that frame size caps it around 500 fps; the fastest profilers' full-frame equivalent would demand about 664 Gpixel/s.
How many 3k profiles per second fit down one GigE link?
About 18,000. A 3072-point profile at 16-bit height is 6,144 bytes, and a 1 GigE link carries roughly 115 MB/s of payload: 115,000,000 ÷ 6,144 ≈ 18,700 profiles/s. Add intensity bytes and protocol overhead and the real figure sits below that, so treat 18 kHz as the ceiling. A 10 GigE-class link carries the same full-width profiles to about 180 kHz.
What profile rate does a 0.3 m/s line need for 20 µm spacing?
15 kHz: rate = speed ÷ spacing = 0.3 m/s ÷ 20 µm = 0.3 ÷ 0.00002 = 15,000 profiles/s, which fits a 1 GigE link at full 3k width. First check the cross-line pitch, field of view ÷ columns, because spacing finer than the pitch buys no geometry: at a 100 mm field over 3072 columns the pitch is 32.6 µm, so 20 µm would only oversample.
Does a higher profile rate need a more powerful laser?
Yes, in direct proportion. Exposure per profile is the line period, 1 ÷ rate: 500 µs at 2 kHz but 5 µs at the fastest rates, a 100× drop in collected light through the same optics. Fast heads make that up with higher-class lasers, up to Class 3B, which is why the beam path belongs inside an interlocked enclosure and why shiny parts need beam containment.
Can I extract the laser line in my own software instead of paying for onboard extraction?
You can, but you inherit the full-frame wall: the sensor still reads every row, so you land in the 500 Hz to 6 kHz class, and your CPU then does peak finding on gigapixels per second that an extraction profiler discards on silicon. Host-side extraction is fine for slow, indexed parts; onboard extraction is what converts readout bandwidth into profile rate.



