Smart camera misses first images after load: fix the ready gate

You load a new vision application to a smart camera, wait for the status LED to go solid, start sending acquisition commands — and the first images never arrive. The trace shows each early command cleared by its 10 s timeout instead of by a new image, and every later trigger works. Nothing is broken. After an application load the camera runs startup work — most often a focus move — and it accepts a trigger only while its status reports ready. A trigger that lands in the busy window is discarded, not queued, and the ready value your program tested was already one cycle old. This guide reads the fault from the trace, shows the timing arithmetic, and replaces the timeout reset with a counter handshake that catches the first trigger every time.

The symptom: triggers lost right after an application load

The case that frames this guide: three vision devices on one PLC running identical acquisition code. Two smart sensors take every image. The smart camera drops the first triggers after each application load. In the recorded trace the first three commands were each released by a 10 s on-delay timer (TON), not by the image detection that normally resets the command. A fuller trace later showed six acquisition requests producing five images, with the accepted counter flat on the first request. On those early requests the camera LED flashed blue for a moment: the command reached the camera, and the camera declined it.

The inspection tool's log also carried empty error entries. They are noise — the counters, not the log, say where the image went. The pattern is a readiness fault, not a capture fault. PC-based cameras show the same signature as a camera trigger ready timeout, and a software trigger image timeout when one-shot capture is involved; on a commanded smart camera the root is almost always a trigger that arrived while the camera was busy.

The cause: the camera is busy and your ready sample is stale

A smart camera accepts an image trigger in exactly one state: acquisition ready — CameraStatus = 0, or ImageAcquisitionReady = TRUE. In any other state the trigger input is ignored; nothing is queued for later. In this trace the camera read ready in the cycle the command was issued, and 128 (0x80, focus module busy) one cycle later. The freshly loaded application had commanded a focus change, and that command crossed the acquisition command on the wire. The camera looked ready, accepted nothing, and went busy before the trigger landed.

Two habits then made the fault worse. The command was reset by detecting a new image — comparing the image timestamp and result — so a trigger that produced no image could never reset it; the 10 s timer did, three times. And the command line then held TRUE for those 10 s, and a held line cannot make the next edge, which is why the timer existed at all. The two smart sensors never missed an image because their fixed-focus lenses have no focus move to run: the difference between the devices is the focus motor, not the program. A hardware trigger that stops after one frame is a different fault — there the acquisition mode is wrong from the first frame on.

Worked example: one stale cycle, three lost triggers

Inputs, all from the machine: PLC task cycle 2 ms; network cycle on the camera link 1 ms; timeout timer 10 s; three consecutive commands cleared by the timer after each load, one flat accepted counter in the fuller trace.

Rule in words: the ready value your program tests is as old as one task cycle plus one network cycle, and a rejected request blocks the command for the full timeout.

Arithmetic: 2 ms + 1 ms = 3 ms. The focus move started inside those 3 ms, after the status was sampled and before the trigger landed. A slower cell widens the window without changing the outcome: a 5 ms task and a 2 ms bus give 7 ms. Lost time with the timer reset: 3 × 10 s = 30 s of dead triggering after every application load. With the counter handshake the rejected request is withdrawn and re-raised one cycle after ready returns, so the first accepted trigger follows the focus move by about 3 ms, and the 30 s is gone.

Decision: after an application load, a sampled ready value is never the only gate. The accepted counter is the ground truth; the sample is a hint.

The fix: gate the command on the acquisition counters

Replace the image-detection reset with a four-signal handshake. Your camera may spell the datapoints differently, but every smart camera that takes a commanded trigger publishes these four signals.

1. Arm on ready. Raise the acquisition command only while ImageAcquisitionReady is TRUE (status 0). After a load, wait for this signal, not the LED.
2. Reset on the accepted edge. Clear the command when AcceptedAcquisitionCnt increments. That edge means the camera has taken the trigger, and it arrives whether or not the image has reached the result buffer yet.
3. Confirm delivery with the completed counter. Let CompletedAcquisitionCnt drive the result handshake — the replacement for comparing image timestamp and result.
4. Retry on silence. If the accepted counter has not moved within one task cycle of raising the command, withdraw it, wait for ready, raise it again. A rejected trigger then costs milliseconds.
5. Fault, never reset, on timeout. Keep the old timer, cut it to 2 s and route it to an alarm. A command unaccepted for 2 s means a dead camera or a failed load — an event for an operator, not a reset path.

Test the causes in order

1. Not ready at the command. Put the command, CameraStatus and both counters in one trace. A flat accepted counter at the moment of the command confirms it.
2. Focus move after load. A status of 128 (0x80) names the focus module. Open the loaded application and move its focus command ahead of trigger enabling, or let the load settle before the first part arrives.
3. Load not finished. A solid LED with CameraStatus nonzero means the application is still starting. Wait for ready; if it never comes, the load failed — check smart camera software compatibility before blaming the wiring.
4. Held command line. A command latched TRUE through a timeout cannot produce the next edge. The accepted-edge reset removes the latch by design.
5. Accepted but not completed. The trigger was taken and the image was lost in transport or buffering — work it as a camera stream restart timeout, not as a readiness fault.

To watch each frame land while you test, displaying smart camera images in real time on an HMI beats pulling files off the camera between runs.

When a light strobe runs off the same command

If the PLC command edge also fires an external light, a rejected trigger still flashes the light: wasted pulses, heated LEDs and a trace that looks as though an image should exist. Drive the strobe from the camera's light output instead, so the pulse fires only on accepted triggers, or gate the light channel on the accepted counter exactly like the command. Size the pulse for the exposure you actually run — the method in sizing the strobe pulse for high-speed barcode verification applies to any strobed station — and keep the duty budget in mind per LED strobe duty cycle matching.

For the wiring, light controllers with strobe channels take the gated pulse and shape it. The LS-CTL-0070 is a 4-channel digital control box rated 200 W with strobe triggering over RS232.

Hardware that shortens the not-ready window

The handshake catches every drop; the hardware decides how long the window stays open. Three choices move it.

Lens focus comes first. A manual-focus lens has no motor, so no focus move runs after a load and the 0x80 state never appears. Both examples come from the smart cameras range:

The MV-SCB007EC-12S-WBN is a 1.6 MP vision sensor with a 12 mm manual-focus lens on an M12 mount. The LS-SMC-0063 is a 1.6 MP smart camera at 60 fps with a 16 mm lens and a built-in white light, which also removes the external strobe question.

Link speed is second. Status and counters ride the same link as the images; both Fast Ethernet and GigE carry the handshake in cycles, not in bandwidth. Filter the smart camera finder by interface when the link is the constraint.

Third, where the logic runs. When the PLC handshake itself is the bottleneck, vision controllers run acquisition, results and lighting from one box beside the line:

The MV-VC3301H-128G66 carries 5+ LAN ports, 8 GB of memory and 4 built-in light channels, enough to host the camera, the strobe and the handshake logic on one unit.

When the usual answer is wrong

• Accepted rises, completed does not. The trigger was taken; the loss is downstream in buffers or transfer. Readiness gating will not help — chase the stream timeout.
• Status never returns to 0 after a load. The load itself failed or is stuck. Reload the application; do not lengthen timeouts to paper over it.
• The first image arrives but is dark. That is light timing at the first exposure, not a dropped trigger; follow the diagnosis in first camera frame dark: exposure settling or light timing.
• Drops at power-up but not after loads point to startup initialization rather than a focus move. The same handshake covers both, and the status code tells you which module is holding the camera.

Checklist for the next application load

• Command, ready, accepted and completed signals in one trace — the four edges localize any future drop in minutes.
• First command armed on the ready signal, never on the LED — the LED reports boot, not readiness.
• Reset wired to the accepted-counter edge — the image path cannot reset a trigger that produced no image.
• Completed counter drives the result handshake — it replaces timestamp and result comparison.
• Timeout cut to 2 s and routed to an alarm — a fault for an operator, never the reset path.
• Uninspected-part reject on a missing completed count — a dropped trigger must not ship a part.
• External strobe driven from the camera's light output or gated on the accepted counter — no flash without an accepted trigger.

Lay the station out once in the system configurator — camera, lens, light and controller in one pass. If a drop survives the handshake, capture the four-signal trace and send it to our applications team through the contact page; that trace answers the question in one reply.