Inspect two sequential images from one camera in one job

A single camera can inspect the front and back panels of one part and still drive a real-time air reject, provided both inspections live in one job and the first result survives the second capture. The pattern works on any smart camera or vision controller that offers more than one image buffer, a digital trigger input and a configurable output. It covers the sequencing — acquire, store the front-side pass/fail, rotate, acquire again, AND the two results before the part leaves the station — and it budgets the cycle with real arithmetic, so you can tell at design time whether one camera fits your takt or a second camera or mirror is the better buy.

Can one camera inspect both sides of a part in a single job?

Yes: keep both inspections in one job by acquiring the front image into its own buffer, storing its pass/fail in a variable, rotating the part, acquiring the back image into a second buffer, and gating the reject output on the AND of the two stored results.

No second job is involved, so there is no job load, no handshake for a job change, and no window in which a part passes uninspected. The pattern differs from running multiple inspection models on one image: there, several tools judge one simultaneous frame; here, the part physically changes between the two frames, so the job must carry a result across the rotation. Everything else — trigger handling, tool tuning, I/O mapping — stays exactly as on a single-image job.

How do I stop the second capture from overwriting the first image and result?

Most acquisition stacks already hold more than one frame: while image data lands in one buffer, another sits free for the next capture, so point the second acquire at a second buffer and store the front-side pass/fail in a variable before it runs.

The image is the easy half. The result is the half people lose: once the front tools output a verdict, copy that boolean into a stored variable immediately, because after the rotation the same tools will fail on the back panel and the front verdict exists nowhere else. A stage flag alone does not isolate the sides — the tools still run on whichever image is live — so use separate buffers for the images and stored booleans for the verdicts. The same buffer mechanics also underlie capturing an image set from one trigger.

// Illustrative names; map them to your platform's acquire, tool and I/O calls.
bool FrontPass = false   // verdict from image 1, stored before capture 2
bool BackPass  = false   // verdict from image 2
bool PartOK    = false   // FrontPass AND BackPass, drives the reject output

on PartPresent trigger:
    FrontPass = false
    BackPass  = false
    capture image 1 -> buffer 1        // front lighting, front exposure
    FrontPass = run front tools on buffer 1
    assert ROTATE output               // 180° rotary actuator starts
    wait until ROTATE_DONE input true  // watchdog timeout -> fail the part
    capture image 2 -> buffer 2        // back lighting, back exposure
    BackPass = run back tools on buffer 2
    PartOK = FrontPass AND BackPass
    drive REJECT output from PartOK for the kicker pulse width

Reset both stored flags at the start of every cycle. The classic bug is part N+1 inheriting part N's front result when a front capture errors out; the AND then passes a part whose front was never inspected. The forced-fail test in the final checklist catches it.

What sequence do the job steps follow?

The job runs eight steps per part in a fixed order: reset the stored results, acquire and inspect the front panel, save that result, signal the actuator, wait for the rotation-complete input, acquire and inspect the back panel, AND the two results, then drive the reject output.

1. On the part-present input, reset FrontPass, BackPass and PartOK (all booleans) to false.
2. Apply the front-side settings — exposure, gain, lighting channel — and capture image 1 into buffer 1.
3. Run the front tools on buffer 1; write the verdict to FrontPass.
4. Assert the rotate output to start the 180° actuator.
5. Wait for the rotation-complete input; on timeout, mark the part failed and skip to step 8.
6. Apply the back-side settings and capture image 2 into buffer 2.
7. Run the back tools on buffer 2 into BackPass; compute PartOK = FrontPass AND BackPass.
8. Drive the reject output for the kicker pulse width, release the part and return to step 1.

Gate both captures on hardware inputs — part-present for image 1, rotation-complete for image 2 — so the job never free-runs between cycles; the hardware trigger configuration applies per camera just as on a single-image job. Give each side its own exposure and lighting preset: front and back panels rarely want the same one, and alternating presets between captures is a settled technique (two exposure times on one camera).

How much cycle time do two sequential captures add?

Two captures cost one extra exposure, one extra transfer and one extra inspection run; in the worked budget below that is about 105 ms of serial time, and the whole two-sided decision lands in roughly 410 ms when the 300 ms rotation overlaps the front-side processing.

Example inputs for a 6 MP mono GigE camera on a stop-and-rotate station:

Timeline: exposure 1 runs 0–5 ms; rotation starts at 5 ms and ends at 305 ms; the front transfer (done at 60 ms) and front inspection (done at 100 ms) finish well inside it; back exposure runs 305–310 ms, transfer to 365 ms, inspection to 405 ms; the reject output is valid at 410 ms. Here the rotation dominates, since 300 ms beats the front side's 95 ms of transfer plus inspection; with a faster actuator the max() term flips to the front side and the arithmetic follows it.

The decision: at 410 ms plus a 30 ms kicker, the station fits any takt of 450 ms or more — a 500 ms takt leaves 60 ms of margin. At a 300 ms takt the same budget misses the window by 140 ms, and the fix is hardware, not software.

How do I keep the reject on time and on the right part?

Gate the reject on a per-part result handshake: the camera asserts the combined pass/fail on a dedicated output within its decision window, the PLC latches it against the part carrier that entered the trigger, and the air kicker fires only for carriers whose latched result is fail.

In a stop-and-inspect station the part sits in its fixture when the result goes valid, so hold PartOK on the output as a level until the next trigger resets it; a PLC catches a level on any scan, while a short pulse must beat the scan time to be seen at all. The PLC pairs the result with the carrier or pitch counter it used to trigger the station, which keeps reject N aimed at part N downstream. The routing side — result to robot, result to pusher, per-carrier bookkeeping — follows the same pattern as routing a single camera's result to a robot and reject pusher.

What hardware runs a two-capture job well?

Any smart camera with two image buffers, two digital inputs, one configurable output and a deterministic interface runs this pattern; a vision controller earns its place when the two inspection runs push the total past your takt — in the worked budget, past roughly 440 ms with the kicker.

Mono gives the most contrast on date codes and small print; color pays for itself when the check judges label hue. The trigger, rotation-complete and reject lines land on the camera's own I/O connector, so a two-capture job needs no extra interface hardware beyond what a single-image job uses.

The MV-SC5060XM-08M-WBN pairs a 6 MP mono sensor with a GigE interface and an 8 mm M12-mount lens, a good match for small print and codes.

The MV-SC6050C-08M-XBN covers color-based checks with a 5 MP sensor, GigE interface and a built-in multi-color light source.

When the two inspection runs do not fit the takt on-camera, offload them: the MV-VC2140-128G40-1T brings 3-4 LAN ports, 2 USB 3 ports, 4 built-in light channels and 8 GB of memory for hosting heavier tools.

Browse the smart cameras category or the camera finder; controllers sit on the vision controllers page.

When is one camera the wrong choice?

Switch to two cameras when the takt leaves no room: below about 300 ms the 410 ms two-capture budget misses the window, and a second camera shooting both sides on one trigger decides in roughly 105 ms.

A second camera also deletes the actuator, its settle time and its timeout failure mode; syncing two cameras from one trigger input is a standard wiring job (trigger two cameras from one frame grabber input). A 45° first-surface mirror folds the back panel into the same exposure — one camera, one capture, no rotation — at the cost of a flipped view, so every tool and reference image trains mirrored, and an ordinary second-surface mirror adds a faint double reflection, which is why the mirror must be first-surface. The decision: takt of 450 ms or more → single camera with rotation; takt between 300 and 450 ms, or no room for a rotary → mirror or second camera; takt below 300 ms → two cameras on one trigger.

How do I prove the job before production?

Prove the job with five tests before it sees production parts: a two-trigger dry run, a forced fail on each side, a stale-result check, a timeout fault and a thousand-cycle timing log.

• Two-capture dry run. Fire part-present, then rotation-complete, from the I/O panel; confirm buffer 1 holds the front image and buffer 2 the back.
• Forced fail, each side. Mask the front label — the reject must pulse. Restore it and mask the back — it must still pulse.
• Stale-result check. Withhold the second trigger after a good front capture; the next part must not inherit the stored FrontPass.
• Timeout fault. Disconnect the rotation-complete input; the job must time out and reject, not wait forever.
• Timing log. Record trigger-to-output across 1,000 cycles; the maximum must stay under takt minus the kicker pulse — 440 ms against a 500 ms takt in the example.

If the numbers above match your station, one camera does both sides without touching the reject timing. Size the rest — lighting, lens, controller — in the build a system configurator, or contact us with the part and the takt; more walkthroughs sit on the applications topic page. Every camera and controller here carries a 3-year warranty minimum.