Reduce exposure time mid-acquisition without an overtrigger error

You cut the exposure on a running line scan camera or area scan camera — to freeze faster motion, to match a new line speed, or after brightening the light — and the camera answers with an overtrigger error and a lost image. Lines or frames keep disappearing while the grab loop runs on. The cause sits in the sensor's timing, not in your code: a sensor cannot read out two images at once, and a sudden exposure cut makes the next exposure finish inside the previous readout. Below is the rule the camera enforces, the readback that exposes your readout floor, a step-size formula with worked numbers for one line scan and one area scan case, and the checks that prove each step held.

Why does reducing exposure time during grabbing cause an overtrigger error?

The camera rejects the next trigger because the shortened exposure would finish before the previous image's readout has ended, and a sensor cannot read out two images at once, so the trigger is discarded and the image is lost.

In triggered operation each trigger starts one exposure; when that exposure ends, the readout shifts the image off the sensor. To keep the rate up, the camera accepts the next trigger while the previous readout is still running — the sensor integrates the new exposure while the old image empties. That overlap of exposure with readout is normal and wanted. The one thing the sensor will not do is start a second readout before the first finishes.

Cut the exposure in a single write and you break the arrangement. The next exposure now ends early, inside the previous readout, so the readout that follows it would have to start before the first readout is done. The camera refuses the trigger — that refusal is the overtrigger error — and the image it should have produced is gone: a lost line tears a web image, a lost frame gaps an area-scan sequence.

What timing rule does the camera actually enforce?

Every new exposure must end at or after the end of the previous image's readout; written as a period condition, the trigger period P must satisfy P ≥ E_old + R − E_new, where R is the readout floor and E the exposure in force for each image.

A trigger is acceptable only when the exposure it starts will end at or after the moment the previous readout finishes. In symbols:

E_old is the exposure of the image still being read out, E_new the value you just wrote, R the readout floor — readout plus the camera's fixed overheads — and P the period at which triggers arrive, set by your encoder or frame timer.

Two consequences fall out of the inequality. With exposure unchanged (E_old = E_new) the exposure terms cancel and the only requirement is P ≥ R: a long exposure may overlap readout as much as it likes, which is why the long setting ran without complaint. The requirement appears only on a decrease, and it grows by exactly the size of that decrease.

The exposure-during-readout behaviour is itself a camera setting, the trigger overlap mode, and camera trigger overlap configuration covers making it stick across restarts. With overlap disabled the camera accepts a trigger only after the previous image is fully done — decreasing exposure then cannot overtrigger, at the cost of a lower maximum rate.

How do I measure the readout time R?

Set the exposure to its minimum, then read the resulting line period on a line scan camera or the resulting frame period on an area scan camera; the value the camera returns at minimum exposure is the readout floor you use as R.

The procedure takes a minute:

1. Put the camera in the production configuration: same region of interest, same pixel data rate, same binning.
2. Write the minimum exposure the camera allows.
3. Read the resulting period — ResultingLinePeriodAbs on a line scan camera, the matching resulting-frame-period feature on an area scan model. That value is the fastest the camera cycles with no exposure contribution, which is R.
4. Restore the working exposure.

The feature name follows the GenICam standard features naming convention, so any GenICam-compliant SDK exposes it:

# illustrative; only ResultingLinePeriodAbs is a standard feature name
R = read_float("ResultingLinePeriodAbs")   # at minimum exposure

Read the feature's unit from its definition once — vendors split between microseconds and seconds — and reuse it. A camera's rated maximum rate states the same floor as a frequency: the LS-LCM-0016 line scan camera is listed at 58 kHz. One divided by 58 kHz is 17.2 μs, so that camera's floor is R = 17.2 μs, and the readback at minimum exposure should land on the same figure. Measure again whenever the region of interest or data rate changes, because both move R; a floor measured at full frame is the wrong R for a windowed set-up.

How large can each exposure step down safely be?

Each decrement must be no larger than the slack between your trigger period and the readout floor, ΔE ≤ P − R; with a 25 μs trigger period and a 17.2 μs floor that is 7.8 μs per step, and margin below it is prudent.

The working numbers:

The ramp routine, in order:

1. Measure R at the production settings, as above.
2. Record P from its source: encoder period or frame timer interval.
3. Compute the slack P − R and pick ΔE with the margins above.
4. Compute N and write the ladder of exposure values into the recipe, largest first.
5. Execute one write per trigger period, each gated on the readback.

What does a safe ramp look like with real numbers?

Going from 20 μs to 5 μs of exposure at a 25 μs encoder period with a 17.2 μs readout floor takes three steps of 5 μs each, and every step keeps the new exposure ending 2.8 μs after the previous readout has finished.

Line scan first. The floor is the 17.2 μs derived above from the 58 kHz rating. The web runs encoder-paced at 40,000 lines per second, so P = 1 / 40,000 s = 25 μs. If the pacing is not fixed yet, how to set the line rate of a line scan camera derives it from web speed and spatial resolution, and the calculator does the arithmetic:

Exposure sits at 20 μs and the new recipe needs 5 μs. In one write the failure is immediate: the previous image's readout ends at 20 + 17.2 = 37.2 μs after its trigger, while the new exposure runs 25 → 30 μs and ends 7.2 μs too early — overtrigger, one line lost.

The slack is 25 − 17.2 = 7.8 μs, so steps of 5 μs (about two-thirds of the slack) leave 2.8 μs of clearance at every boundary:

times in μs after each trigger; triggers every 25 μs; R = 17.2 μs

one write, 20 → 5 μs
  t=0    exposure [0 … 20]    readout [20 … 37.2]
  t=25   exposure [25 … 30]   ends 7.2 μs before 37.2   → overtrigger

ladder of 5 μs steps
  t=0    exposure [0 … 20]    readout [20 … 37.2]
  t=25   exposure [25 … 40]   ends 2.8 μs after 37.2     → accepted
  t=50   exposure [50 … 60]   previous readout ended 57.2 → accepted
  t=75   exposure [75 … 80]   → accepted; margin now 7.8 μs

Check the second step the same way: the image exposed at t = 25 runs to 40 μs and its readout ends at 57.2 μs; the next exposure [50, 60] ends at 60 μs, which is 2.8 μs past it. Every later boundary repeats that clearance, and once the ladder bottoms out at 5 μs the margin opens to the full 7.8 μs.

The line scan camera in this example:

Area scan works the same arithmetic in milliseconds. An LS-CMR-0166 is rated at 30 fps. One over 30 fps is 33.3 ms, so R = 33.3 ms. Triggered from a frame timer at 25 fps, P = 40 ms and the slack is 40 − 33.3 = 6.7 ms; 5 ms steps take a 35 ms exposure down to 10 ms in five writes, each new exposure ending 1.7 ms after the previous readout.

The area scan camera in this example:

When a lighting controller for line scan cameras strobes the light for each exposure, shorten the strobe on-time with every step as well — setting strobe on time against the exposure control keeps the two locked together.

Is increasing exposure during grabbing also risky?

No: lengthening the exposure moves its end later in the timeline, which relaxes the rule rather than breaking it, so you can raise exposure in one jump on a triggered camera without an overtrigger.

Raising the exposure grows the −E_new term and loosens the acceptance inequality, so one write up to the new value is safe. The envelope still has two walls: exposures must not overlap each other, so keep E ≤ P, and the pacing must cover the floor, P ≥ R. Push exposure past P and the next trigger lands mid-integration; the camera refuses it for that opposite reason.

How do I confirm a step took effect before the next one?

Read the resulting period readback after every step and compare it with the period you expect, then watch the camera's error and image-loss counters over the next second of grabbing before you shorten the exposure again.

Gate every write on the readback: after writing a step, wait at least one trigger period, read the exposure back, and send the next decrement only when the camera reports the value you wrote. Two trigger periods is the conservative spacing when a register write applies on the following frame. Runtime camera parameter control shows the same read-back loop applied to exposure and white balance together.

# illustrative ramp; only ResultingLinePeriodAbs is a standard feature name
step   = 5.0                      # μs, from ΔE ≤ P − R with margin
target = 5.0                      # μs
e = read_exposure()               # e.g. 20.0
while e > target:
    e = max(target, e - step)
    write_exposure(e)
    wait(trigger_period * 2)
    assert read_exposure() == e
    log(e, read_float("ResultingLinePeriodAbs"), lost_image_count())

The resulting-period readback is the acceptance test: at exposure E it should report the larger of E and the floor, and a value stuck at the floor while E is larger means the write never landed. In line scan, also compare captured lines against encoder increments — encoder ticks per pixel for line scan gives the expected count, and a shortfall during the ramp is a refused trigger you did not see.

When is stepping down the wrong fix?

When the exposure is set by the width of the trigger pulse itself, or owned by a sequencer, or the value keeps snapping back on its own, stepping treats a symptom — change the pulse width, the sequence, or find the persistence fault instead.

• Exposure set by trigger pulse width. In the mode where the trigger pulse's width is the exposure, writing the exposure feature does nothing; shorten the pulse at its source — a timer output on your PLC or on one of the frame grabbers driving the line. Why trigger pulse width sets your camera exposure time identifies that mode.
• Sequencer-owned exposure. When alternating exposures come from the camera's sequencer, a live write fights the sequence. Fix the sequence steps instead — sequenced exposure trigger timing: fix overtrigger errors works through that case.
• The value keeps snapping back. A ramp that re-climbs on its own is a persistence fault, not timing: exposure resets during acquisition traces it.
• Internal, self-paced triggering. With no external trigger source the camera paces itself, the resulting period follows the larger of E and R, and there is no trigger to refuse — this error needs a hardware or software trigger.

What belongs in the ramp checklist before production?

A measured readout floor, a recorded trigger period, a step size with margin, readback-gated writes, a logged resulting period, and counters watched across full ramps — six lines that keep the error away for the life of the line.

• R measured at the production region of interest and data rate, from the resulting-period readback at minimum exposure.
• P recorded with its source — encoder or frame timer — and its jitter noted.
• Step ΔE chosen from the slack: half for encoder pacing, 80 percent from a timer; the ladder written into the recipe.
• One exposure write per trigger period, each gated on the exposure readback.
• Resulting period logged after every step and compared with the larger of E and R.
• Error and image-loss counters watched across three full down-and-up ramps.
• The ladder restored from the camera's saved user set at power-up, confirmed by the startup readback — camera startup frame rate covers that check.

From here, size the floor and pacing on the camera finder, build the full set-up in the configurator, or send the ramp numbers through the contact page — expert support is free with every order.