Make line scan line rate follow machine speed at runtime

You have a speed value — a slider on the operator screen, a number from the PLC, a drive setpoint — and a line scan camera whose line rate must track it. The failure is always the same: you write the rate to the camera, the vision software runs its acquisition step, and the camera is back at the step's saved rate. This guide gives the two fixes. Bind the line-rate attribute to a runtime value inside the acquisition step, or switch to encoder-triggered acquisition and let the web pace the camera. The arithmetic that links belt speed to Hz, mm per line, exposure and lens choice is here too.

Why does the acquisition step overwrite my camera settings?

Because the step stores every camera attribute as a constant and re-applies the whole set each time it opens the camera, the rate you wrote from a helper program or a script is overwritten at the next start. Step-based inspection software treats the camera's attribute set as part of the recipe: open camera, write all saved attributes, stream, inspect, close. Anything written outside that sequence — a second program, a custom UI script, a different inspection file — does not survive the next cycle.

Two consequences follow. First, settings that must change have to change inside the owning step, not beside it. Second, if you switch between two inspections that both grab from the same camera, the first must release the device cleanly or the second cannot open it; that "camera still in use" error is a session left open, not a camera fault.

Whether a feature accepts a write at a given moment is a property the camera itself reports per node — camera feature node readability: check before reading covers how to read that flag before you blame the software.

How do I bind the line rate to a runtime value instead of a constant?

Open the line-rate attribute in the acquisition step's camera attribute tree and set its value source to a step result or a UI numeric control instead of a typed constant; the step then writes your runtime number every time it runs. The attribute still lives in the acquisition step — which is the point: the write happens where the camera is owned.

1. Fix the geometry first. mm per line = web width ÷ pixels across. For 200 mm across 2048 pixels: 200 ÷ 2048 = 0.098 mm per line. This value holds as long as the lens and camera stay.
2. Bring speed in. Add a numeric control to the operator UI in mm/s, or read the drive setpoint from the PLC into a step variable each cycle.
3. Compute the rate where the software can reach it. A calculation step returns rate = speed ÷ 0.0977, in Hz.
4. In the acquisition step, expand the attribute tree to the line-rate feature, click its value field and switch the source from constant to your calculation result.
5. Read it back. After one acquisition, confirm the camera's line-rate node reports what the control commands; if it does, the binding took.

What line rate does my machine speed need?

Line rate in Hz equals web speed in mm/s divided by mm per line: at 2048 pixels across a 200 mm web that is 0.098 mm per line, so every 1 m/s of belt speed needs 10.2 kHz.

Worked example, a 200 mm web moving at 0.6 m/s:

• mm per line: 200 ÷ 2048 = 0.0977 mm.
• Line rate: 600 mm/s ÷ 0.0977 mm = 6,144 Hz ≈ 6.1 kHz.
• Line period: 1,000,000 ÷ 6,144 = 163 µs. Exposure at or under 163 µs keeps blur at or under one pixel; at 100 µs the blur is 600 mm/s × 100 µs = 0.06 mm, 0.6 of a pixel.
• Ceiling: at 58 kHz the same geometry supports 58,000 × 0.0977 mm/s ≈ 5.7 m/s of web.

For a camera in this class:

The LS-LCM-0016 is a 2K GigE line scan camera with 7 μm pixels, a 58 kHz maximum line rate, TDI and an M42 mount. At 0.098 mm per line its ceiling is about 5.7 m/s of web — far above what most belts ask for.

If the line runs at one speed all day, no tracking is needed and a fixed rate is simpler: how to set the line rate of a line scan camera covers that case. When speed varies, keep going.

Which camera settings can change during acquisition and which cannot?

Line rate, exposure time and gain accept new values while the stream runs; width, height, lines per frame, pixel format and binning are refused mid-stream and must be written with the acquisition stopped, then the stream restarted. The camera enforces this, not the software: a feature that cannot be written while acquiring is simply not offered as a bindable value.

For a recipe change — new product, new width, new lines per frame — the sequence is always stop, write, start. Put it in a recipe-load step that runs at product change, never in the per-cycle path. If you script the writes yourself, the same rule applies; setting camera exposure time through a GenICam API in Python shows the pattern for the features that do move at runtime.

Why is encoder triggering better than tracking the speed?

Because one line per fixed unit of travel makes mm per line constant at any speed — 0.098 mm per line at 0.1 m/s and at 2 m/s — ramps, jog and crawl stop distorting the image, and nothing needs tracking. The encoder paces the camera; the line rate becomes a result, not a setting. A bound rate is always one control update behind: during a ramp the image stretches or compresses until the next update. Encoder triggering has no such window.

The set-up is three decisions:

1. Trigger source: set the camera to trigger on its line input instead of a free-running rate.
2. Wiring: quadrature from a roller or measuring-wheel encoder into the camera's input — encoder-triggered line scan capture: wiring quadrature inputs has the connection detail.
3. Counts per line: pick the encoder and divider so counts per line is an integer at your target resolution — one count per line when the numbers allow.

Exposure still matters most at top speed, where the line period is shortest — 98 µs at 10.2 kHz in the example above — so fix exposure against the top speed, not the nominal one. If the speed reference itself comes from the drive, setting up a drive to follow a line-speed reference covers the drive side of that chain.

How do I verify the line rate is following the machine?

Image an object of known length and compare: its length in pixels times mm per line must match the true length within about 2 percent, at both your slowest and fastest production speed. That one test catches a stale binding, a wrong divider and a slipping encoder at the same time.

• Tape two marks exactly 500 mm apart on the belt and count the image lines between them at low speed, then at full speed. At 0.098 mm per line that is 500 ÷ 0.0977 ≈ 5,120 lines; the two counts must agree within about 2 percent.
• Read the camera's line-rate node back after every control change; the node reports what the camera is actually doing, not what you asked for.
• Image a square gauge flat on the web. Stretched along travel means the rate is too low for the speed; compressed means too high.

For exact geometry — pixel scale, lens distortion, aspect — line scan camera calibration with a moving checkerboard target turns the estimate into a measured map.

What does a faster line rate cost in light and bandwidth?

Double the line rate and you halve the exposure ceiling, so light per line halves unless you add power — plan roughly double the light for double the speed — and the interface must carry the extra bytes. Light first: at 6.1 kHz the ceiling is 163 µs; at 12.3 kHz it is 1,000,000 ÷ 12,288 = 81 µs. Holding the same pixel response in half the time needs about twice the irradiance on the line. Line scan light: how much power a fast line really needs works that budget, and binning or TDI buys some of it back — see pixel binning on a line scan camera: more light, same speed.

Bandwidth next: bytes per line times line rate, plus protocol overhead. A 2048-pixel mono line at 8 bits is 2 kB; at 6.1 kHz that is 12.6 MB/s — a small slice of GigE. An 8192-pixel line at 50 kHz is 8.2 kB × 50,000 = 410 MB/s, which belongs on 10 GigE. GigE Vision camera selection: bandwidth, cables and software covers cable and NIC sizing.

The controller matters as much as the light, because the strobe pulses at line rate. A strobe-capable box from the light controllers category keeps pulse energy flat as the rate climbs:

The LS-CTL-0070 is a 4-channel digital control box rated 200 W with RS232 control, constant-voltage 24 V outputs and a strobe feature. Lighting controllers for line scan cameras: what they fix explains why timed strobing holds pulse energy when the rate changes.

What should I check before ordering camera, lens and controller?

Size for the fastest speed the line will ever run: at least 30 percent line-rate headroom over your worst case, cable bandwidth under 80 percent of the wire rate, and a lens that resolves your pixel size across the full sensor length.

• Camera rate: max speed ÷ mm per line, plus 30 percent. A camera rated 58 kHz running 6.1 kHz nominal has the headroom; the same camera at 45 kHz nominal does not.
• Cross-web resolution: give the smallest defect 3 to 4 pixels across, minimum. 2048 pixels over 200 mm is 0.098 mm per pixel, so a 0.3 mm defect is 3 pixels — the floor, not the target.
• Lens magnification: sensor line length = pixels × pixel size, so 2048 × 7 μm = 14.3 mm. Magnification = 14.3 ÷ 200 = 0.072x. With a 40 mm focal length, working distance = f × (1 + m) ÷ m = 40 × 1.072 ÷ 0.072 ≈ 595 mm. Line scan camera field of view: how to calculate it and line scan lens selection for 4K, 8K and 16K cameras carry the full method.
• f-number: the Airy disc diameter is 2.44 × λ × N; at 550 nm, f/5.6 gives 7.5 µm — one 7 μm pixel. Stay at f/5.6 or faster on a 7 μm sensor, or diffraction, not the lens, sets your resolution.
• Encoder: pick counts per revolution so one count, or an integer divisor, equals mm per line.
• Strobe: the controller's maximum pulse rate must exceed your top line rate.

For this geometry:

The LS-LSL-0150 is a 40 mm line scan lens with M58 and M72 mounts and a 60 mm image circle. Two steps up when the web widens or the speed climbs:

The MV-CL042-91GC-V2 is a 4K color GigE line scan camera with 7 μm pixels, an M42 mount and a 29 mm image circle. The LS-LCM-0067 is an 8K 10GigE line scan camera with an M72 mount and a global shutter. A 4096 × 7 μm line is 28.7 mm long, so check the lens image circle before reusing a 2K lens on a 4K body.

Start from the line scan cameras category or the line scan lenses category, or size the whole chain in the camera configurator. If your line changes speed per recipe, give us the speed range and web width on the contact page and we will size the chain against your numbers.