Two exposure times one camera: alternate per trigger without serial

Your machine fires two trigger pulses per part: first a white-light shot for the position check, then a red-light shot for the datamatrix grade. The vision program holds a single exposure time, so one of the two images is always wrong — in practice an underexposed grade image that reads as a false reject. Wiring in a serial or Ethernet link just to send exposure commands between shots is invasive on a running line, and usually unnecessary. The sections below arm a different exposure for each trigger inside the camera program, keep the sequence from desyncing when a part is rejected, and check the cycle-time budget before you build.

Can one camera really hold two exposure times without a serial link?

Yes — keep both exposure values stored in the vision program, flip which one is armed before each trigger, and the PLC keeps firing the same two discrete lines it fires today: 2 ms for the white-light shot, 6 ms for the red-light shot.

The exposure that matters is the one latched in the sensor when the trigger edge arrives. Writing that value between frames costs no cycle time and needs no comms channel: the program flips a stored variable from the white value to the red value, and nothing else on the line changes. The camera never receives a 'which light' message — the sequence position tells it.

Check one thing before you build the flip. If the camera has a spare discrete input, wire the two PLC lines to separate trigger inputs and map each input to its own exposure; the alternation problem then disappears entirely. The scheme below is for the common retrofit case, where the I/O block merges the machine's two commands onto one trigger line and the camera sees only edges.

Do the two exposures actually fit inside the machine cycle?

Add the budget before you write any logic: a 250 ms cycle carrying 2 ms and 6 ms exposures, two 5 MP frames at 8-bit over GigE and 20 ms of processing per image loads 132 ms, which leaves a 118 ms margin.

The example pair, with the arithmetic shown:

• White-light exposure 2 ms, red-light exposure 6 ms — the pair used throughout; your own values come from one histogram pass on real parts.
• Frame size: 5 MP mono at 8-bit = 5,000,000 pixels × 1 byte = 5 MB.
• Transfer: 5 MB ÷ 118 MB/s = 0.042 s, about 42 ms per frame, where 118 MB/s is the usable payload a tuned GigE link delivers.
• Processing: 20 ms per image, taken as the example's routine load.
• Total: 2 + 6 + (2 × 42) + (2 × 20) = 132 ms.
• Margin: 250 − 132 = 118 ms, roughly 47% of the cycle free.

The tighter constraint is the gap inside the pair. With white at t = 0 and red at t = 100 ms, the white frame finishes transferring at 42 ms and grading at 62 ms, so the result reaches the reject gate in time. The exposures themselves rarely dominate; transfer does, which is why exposure length matters to frame rate on this kind of link — the frame-rate article works that trade.

What do you need before you start?

Four things: a camera whose program can hold a variable and write exposure between triggers, two lights on separate channels of a strobe-capable controller, two spare PLC outputs, and a written rule for which exposure the next trigger uses.

• The camera. Inspection-on-device models run the whole sequence on board, and the GPIO and serial trigger article shows how discrete inputs start routines; otherwise a PC-based area scan camera works through the SDK. Either way prefer a global shutter for strobed shots — the FAQ below explains why. Shortlist with the camera finder or browse smart cameras.
• The two lights. White for the position check, red for the grade in the example, each on its own channel so it fires only on its own shot; the light controllers category and the light controller finder filter by channel count and strobe.
• The wiring. PLC line A pairs the camera trigger with the white channel's enable; line B pairs the camera trigger with the red channel's enable. No serial link, no protocol, just edges.
• The rule, written down. Which exposure is armed at power-up, what a white pass arms, what a white fail arms, and the resync timeout. That paragraph is the whole control scheme.

Three parts fit this build directly. On the camera side, an all-on-device vision sensor carries the inspection program, the alternation logic and the I/O handshake in one place; if you would rather inspect on a PC and choose your own optics, a global-shutter GigE camera in C-mount connects to the same trigger wiring through the SDK. On the lighting side, a strobe-capable digital controller fires each light on its own channel and takes the PLC enables directly.

How do you alternate the exposure on each trigger?

The cleanest single-input scheme is result-gated: every part starts on the white-light exposure, and the program arms the red-light exposure for the second trigger only when the white-light check passed — a handful of program lines, laid out below.

1. Declare the values and the armed one. Two stored exposure values, 2 ms and 6 ms in the example, plus one armed variable that starts on white.
2. Write the exposure before the trigger edge, not after. Set the sensor exposure from the armed variable, then enable the capture; a write that lands after the edge fires the shot at the previous value.
3. Track pair position, not image content. The program knows what a trigger is because it armed for it: the first shot of a pair is white by definition.
4. Arm red only on a pass. White result passes: write 6 ms and expect the second trigger. White result fails: keep 2 ms armed, reject the part, and treat the cancelled second trigger as noise.
5. Return to white after every red shot. The next part then always starts from the known state, which is what makes the scheme self-healing.
6. Add a timeout. If the armed state expects red and no trigger arrives within 150 ms — between the example's 100 ms pair spacing and its 250 ms part pitch — drop back to white.

// illustrative pseudocode; the names are ours, not a vendor API
int  armed_exposure_ms = 2;      // starts on the white-light value
bool awaiting_red      = false;  // no part in progress at power-up

on trigger:
    set_exposure_ms(armed_exposure_ms)   // lands before the sensor arms
    img = capture()
    if not awaiting_red:                 // white-light shot
        if position_check(img) == PASS:
            armed_exposure_ms = 6        // red-light value
            awaiting_red = true
        else:
            reject_part()                // no red shot will come
    else:                                // red-light shot
        grade_datamatrix(img)
        armed_exposure_ms = 2            // next part restarts on white
        awaiting_red = false

every 10 ms:
    if awaiting_red and time_since_trigger_ms > 150:
        armed_exposure_ms = 2            // lost red trigger: resync
        awaiting_red = false

What happens if the camera loses trigger sync with the machine?

With blind alternation it stays wrong on every part until someone power-cycles it: one missed or extra trigger flips the pattern, the red-light image then lands on the white-light exposure, grades fail across the board, and no fault is raised.

Desync sources are ordinary — an operator clears a jam mid-pair, the upstream gate skips a part, a watchdog restarts the program between shots — and a blind alternator, the kind built from a counter that resets at two, has no way to notice any of them.

The result-gated scheme heals because every path ends on white. A passed white shot arms red and the red shot re-arms white; a failed white shot never arms red at all; the 150 ms timeout drops a dangling red expectation back to white. The worst case is one mis-exposed image on the part where the sequence broke, not an endless run, and the log in the next section makes it visible the same hour it happens.

When is a command link or sequencer still the better answer?

If the camera and controller already talk over serial or Ethernet, a per-shot exposure command removes the alternation state entirely, and a camera sequencer does the same hardware-side — both are worth wiring up when you are touching the comms anyway.

Event-style changes ride on a communications channel: the controller sends its 'next image uses exposure B' message and the camera applies it at the trigger. That answers the comms question directly — an event trigger needs that link to carry the event, so over pure discrete I/O there is no path for it, which is exactly why the program-side flip above exists.

For a greenfield build, prefer the link or the sequencer feature on PC-connected GigE and USB3 cameras, which steps through preloaded exposure sets on each hardware trigger with no host round trip; the sequencer article sets up paired exposure and gain changes step by step. If the machine can merge both shots behind a single trigger instead, one trigger can return a whole image set — see capturing an image set from one trigger. The gated alternation earns its keep on retrofits, where the two discrete lines already work and adding comms means rewiring a running machine.

How do you prove the right exposure fired on every shot?

Log the armed exposure value with every image and check the mean gray level: at a fixed light, mean brightness scales with exposure time, so a 6 ms frame should read about three times the mean of a 2 ms frame — around 180 versus 60 on an 8-bit scale.

1. Prove the test can fail. Force the armed value to 2 ms for every shot and run ten cycles; red-light frames should sit near a third of the white-light frames' mean, 6 ÷ 2 = 3, confirming the metric catches a wrong exposure.
2. Enable the gated logic and run 50 cycles, including parts that reject every third pass. The log should read 2, 6, 2 within each pair, with no drift into a 2, 2, 6 pattern.
3. Break it on purpose. Disconnect the red trigger line mid-run; the timeout should drop the armed value back to 2 ms within 150 ms, and the next complete part should inspect normally.
4. Pair results to parts at the reject gate. A grade result that lands one part late rejects the wrong part, so check that the part identity travels with the result.

The 3× mean check holds in the sensor's linear range, well below saturation; if red-light means crowd the top of the scale, shorten the 6 ms rather than trusting the ratio.

Which mistakes trip this scheme up most often?

Three cause most field failures: auto-exposure left on so it overwrites the armed value, arming the exposure after the trigger edge instead of before it, and letting the light stay on longer than the exposure so ambient light leaks into the frame.

• Auto modes left on. Auto-exposure or auto-gain re-aims the image every shot and erases your armed values; the brightness drift article shows the symptom and the fix.
• Arming after the edge. If the first shot of every pair looks right and the second is wrong, look at the write order before anything else.
• Strobe window longer than the exposure. The sensor integrates everything that lands on it while it is awake, ambient included; match the light-on window to the exposure, and see strobe overdrive, duty cycle and timing for the drive side.
• Blur on a moving part. Exposure caps at the blur budget: at 150 mm/s part speed, a 2 ms exposure draws a 0.3 mm streak (150 × 0.002 = 0.3 mm); the exposure time versus shutter speed article works that budget properly.

The logic is program work only — the remaining decisions are hardware. Size the camera from your field of view and cycle time in the camera configurator, match the two lights' drive in the light controller configurator, or send the trigger sketch through the contact page if your line sits between the two cases. More trigger and timing pieces sit on the systems topic page.