Switch camera exposure time per inspection recipe

Two inspection processes share one camera. The first needs a short exposure under a bright light, the second a long exposure in dim light, and after both are configured the second recipe's value overwrites the first, so every image exposes the same. The fix is a settings pattern, not new hardware: store each recipe's exposure as a variable, bind the camera's image source to that variable, and write the value when the recipe becomes active. This page shows where the setting lives in the vision software, the write-and-trigger order that makes the change land, the frame-rate arithmetic two recipes cost, and the checks that prove the switch worked.

The rule: the active recipe writes the exposure

A camera holds one exposure value at a time. When two processes in one project both carry an exposure setting for the same camera, both settings are written when the project loads, and the second write replaces the first. Every frame from either process then uses the last value written, which is exactly the symptom you see: the later recipe's exposure applies to everything.

The rule that fixes it: the recipe about to run writes the exposure, and nothing else does. Keep one value per recipe, point the camera's exposure parameter at it, and let recipe selection assign the number. Exposure then changes with the recipe, once, at the moment it matters. The same pattern carries gain, trigger delay and light channel per recipe, so the whole acquisition set travels with the recipe.

What you need

• A camera with a writable exposure. Every GigE Vision and USB3 Vision area scan camera carries one, and a new value takes effect at the start of the next frame.
• Vision software whose image source accepts a variable in its exposure field, which is the mechanism this software family provides and the direct answer to the last-write problem.
• A recipe-selection signal from the line: one command code per recipe, the pattern covered in RS232 vision recipe selection.
• A place to run it. A vision controller with built-in light channels can switch light and exposure in the same step.

A 6 MP GigE model like this covers a single-camera station, and the pattern is identical on USB3 and CoaXPress cameras. For the controller side, the MV-VC3301H-128G66 carries 4 built-in light channels and includes a VM6200Pro license, so one recipe change can switch the light and the exposure together:

Where the setting lives in the software

In this software family you add a camera as one of three source types: global camera, 3D camera or a frame grabber. A GigE area scan camera connects as the global camera source. That name is a source type, not a shutter mode. The shutter is a camera property, and the camera finder splits models by Global and Rolling.

The image source owns the acquisition parameters, exposure among them, and two facts about it drive the whole fix. There is one exposure parameter per camera, shared by every process that uses the camera, which is why two fixed settings cannot coexist. And its value field accepts a variable: create a numeric variable in the project, bind the exposure parameter to it, and the value follows the variable at run time.

Under the standards the feature is ExposureTime in the AcquisitionControl group, counted in microseconds. Software attribute trees wrap it under their own names, so follow the image source's exposure field rather than one memorized path. If your software hides the parameter, write it from your own code: runtime camera parameter control covers the live path, and setting exposure through sensor registers is the fallback when no call exists.

Set it up step by step

1. Tune each recipe alone first. Run process A, adjust exposure until its images pass, and record the number with its unit; repeat for process B. Those two numbers are the entire per-recipe payload.
2. Create a numeric exposure variable in the project with one stored value per recipe. Keep the unit straight: ExposureTime counts microseconds, so 5 ms is 5000 µs (5 × 1000).
3. Open the camera's image source and bind its exposure parameter to the variable. The binding is a property of the source and is done once.
4. Make recipe selection write the variable. When the line picks a recipe, the program assigns that recipe's value before arming the first trigger of the batch.
5. Trigger after the write lands. A frame that starts after the write carries the new exposure; a frame already exposing keeps the old value. Let that frame pass as the last frame of the previous recipe.
6. Save the values with the recipe file, so a controller restart restores both exposures without retuning.

Verify the switch

Read the parameter back after the write if the software offers a readback, then judge from the image. On a static scene, mean gray value scales with exposure while the sensor stays below saturation: a recipe at four times the exposure of the other should read about four times the gray value, and a ratio near 1 means the write never landed.

Expect one transition frame after each recipe change to carry the previous exposure. That frame latched its settings when it started; it is not a fault. The frame after it must show the step. If images two frames later still expose the old way, the write went to the wrong parameter or the wrong source, and two image sources pointing at one physical camera is the usual cause.

Worked example: 5 ms and 20 ms recipes on one 30 fps camera

Inputs:

• Recipe A, bright field with the ring light on: 5 ms exposure, from your own tuning of that process.
• Recipe B, low-light surface check with the ring off: 20 ms exposure, likewise from tuning.
• Camera: the LS-CMR-0166, a 12 MP USB3 model that outputs 4000 × 3000 pixels at 30 fps.
• Two frames per part, one per recipe; recipe selection by one command code per recipe.

Work the numbers:

• Frame period: 1000 / 30 = 33.3 ms.
• Duty: recipe A uses 5 / 33.3 = 0.15 of each frame (15%); recipe B uses 20 / 33.3 = 0.60 (60%). Both fit inside a frame, so the camera holds its own rate.
• Throughput: 30 frames per second over 2 frames per part gives 30 / 2 = 15 parts per second.
• Light: recipe B collects 20 / 5 = 4 times the light per frame, so it holds its gray level at one quarter of recipe A's illumination.

Decision: this camera runs the two-recipe station up to 15 parts per second. A faster line needs a camera good for twice the takt in frames per second, so 60 fps for a 30-parts-per-second line, or one frame per part. An exposure longer than the frame period caps the rate directly: ask for 40 ms on this camera and it slows to 1000 / 40 = 25 fps. Budget one spare frame at each recipe change for the transition image.

Three ways to hold a per-recipe exposure

The third row is a different tool: it swaps exposure between consecutive images of one part, which is the scheme in two exposure times on one camera, alternating per trigger. For whole-recipe changes, the variable route wins because the value travels with the recipe and shows in the saved project. The same write-per-change logic applies when a recipe needs a different resolution instead of a different exposure: switch a GigE camera's resolution without reconnecting.

When per-recipe switching is the wrong tool

The two exposures belong to one part, back to back. That is per-trigger alternation, not two recipes, so use the third row above rather than a recipe write per image.

The part moves. Blur equals speed times exposure, so at 100 mm/s a 20 ms exposure smears 100 × 0.020 = 2 mm of travel into the image. Keep blur under one pixel, with pixel size taken as field of view divided by pixel count, and get there with light rather than exposure. If the fix is a strobed, overdriven light:

The second pass is a 3D scan. Capture parameters there belong to the per-part settings, covered in switching 3D camera capture parameters per part.

A second camera beats a very long exposure. Two image sources, one variable each, is the pattern in independent exposure per camera, and it leaves both recipes at short exposures.

Checks before you run

• Both values saved with the project, in the unit the source expects, which is microseconds for ExposureTime.
• Binding proven across a reconnect: cycle power on camera or controller once and re-check.
• Order proven: recipe change, write, one transition frame, then the new exposure.
• Gray-level ratio on a static target close to the exposure ratio, 4 in the example above.
• Frame rate at least twice the line takt for two frames per part.
• If triggers stall at the change, check the GigE packet size before acquisition and the trigger-ready timeout.

Common mistakes

• Setting exposure in both processes and never writing again: the last writer owns every frame.
• Trusting the first frame after a write: it may have latched the old value when it started.
• Mixing units: 5 typed where 5000 µs belongs is a thousandfold error.
• Chasing a light problem with exposure: four times the exposure buys you one quarter of the light, and a brighter lamp is often the cheaper fix.

Fit it to your station

Pick the camera by frames per second and resolution per recipe. The camera finder filters by interface, resolution and shutter, and the configurator below walks camera, lens, light and controller in order. The systems topic page gathers the trigger, bandwidth and recipe pieces around this pattern. For a station with many recipes or several cameras, the contact page reaches the applications team with the recipe list.