A dual-camera system can receive every command and still miss inspections. The electrical pulse may never reach an input, acquisition may not be armed, or a workflow may block after a valid exposure. Receiving a branch-selection character proves none of those later stages succeeded.
For controls and vision integrators, the fastest approach is to trace each inspection through distinct checkpoints. Start with each camera independently, then test simultaneous acquisition, processing and result delivery. This separates wiring faults from application scheduling problems without changing several variables or weakening network security.
1. Identify which stage actually fails
Record the earliest missing event rather than describing every symptom as a trigger failure. Use the following order as a diagnostic sequence, not a claim about which fault is most common.
| Observation | Likely fault area | First discriminating test |
|---|---|---|
| No input transition is detected | Wiring, polarity or input configuration | Measure the pulse at the camera connector |
| Input changes, but no exposure occurs | Trigger selection, readiness or acquisition state | Check the active trigger configuration and available exposure status |
| Exposure occurs, but no complete image arrives | Transport, buffers or stream configuration | Inspect incomplete-frame and transport counters |
| Image arrives, but processing never starts | Workflow scheduling or a blocked queue | Log frame arrival and processing entry separately |
| Processing completes, but no result reaches its destination | Message routing, connection state or acknowledgment handling | Trace result creation, transmission and acknowledgment |
| Results reach the wrong destination | Shared state or incorrect frame association | Follow camera identity and inspection identity through every stage |
Available counters vary by camera and software. An absent diagnostic counter is not evidence that an event did not occur. Use an exposure-active output, supported event notification or controlled image test where appropriate.
For faults dominated by electrical reference differences, start with camera trigger common-reference checks. If images arrive but execution later stops, use the separate acquisition-stall diagnostic sequence.
2. Prove the electrical input safely
A wiring arrangement that works with one application is useful evidence, but it does not establish that the production application selects the same input or edge.
Before rewiring, obtain the camera's documented input circuit and the trigger source's output specification. Check:
- Input type, including whether it is isolated.
- Allowed voltage and current, including absolute limits.
- Connector pin assignment and signal return.
- Required pulse width and selected edge.
- Trigger-source output type and polarity.
- Any documented input filtering or debounce setting.
Do not infer pin functions from wire colors. Do not copy a resistor value from a different installation: input circuits and output stages differ.
Measure at the camera connector, not only at the controller terminal. Check both cameras connected together because loading can change the waveform. A shared trigger source must satisfy the combined input requirements.
If input activity is missing, correct the electrical fault before changing workflow logic. The camera GPIO wiring guide provides a broader damage-prevention sequence. Replacement cables must match the documented connector and pinout, not merely fit mechanically.
3. Reconcile application settings and acquisition readiness
Successful triggering in a setup utility does not prove that another application loads identical settings. Close the utility before opening the production application unless the documented architecture explicitly supports shared access.
Compare the effective configuration after acquisition starts, not just the values displayed before startup:
- Confirm camera identity using a stable identifier supported by the software.
- Confirm the intended acquisition mode.
- Select the documented trigger selector, such as frame start where supported.
- Confirm trigger mode is enabled for that selector.
- Select the physical input carrying the pulse.
- Confirm activation polarity and any input filter.
- Start acquisition and verify that the camera is waiting for a trigger.
- Read back accessible settings after initialization finishes.
A software-trigger command and a physical input are different sources. Similarly, settings for starting an acquisition sequence may differ from settings for exposing each frame.
Initialization code, stored user settings and acquisition modules can overwrite earlier changes. Keep a startup log containing requested values, returned values and write failures. The trigger-overlap startup checks explain why configuration order matters.
Begin testing at a deliberately slow rate, such as one pulse every 2 seconds, provided the camera documentation permits that timing. This removes throughput pressure while you establish basic operation. Increase the rate only after every pulse produces the expected evidence.
4. Test independent and simultaneous operation separately
Use a small test matrix. Keep image saving, processing and outbound communication disabled until acquisition alone passes.
| Test | Active acquisition paths | What a failure suggests |
|---|---|---|
| Camera A alone | A only | A-specific wiring, configuration or transport |
| Camera B alone | B only | B-specific wiring, configuration or transport |
| Both armed, trigger A only | A and B | Shared-resource interference or incorrect routing |
| Both armed, trigger B only | A and B | Shared-resource interference or incorrect routing |
| Both triggered together | A and B | Readiness, transport bursts or scheduling contention |
| Both triggered at an offset | A and B | Whether simultaneous demand is the distinguishing condition |
For each test, count issued pulses, detected input events where available, completed frames and incomplete frames. Repeat after restarting the application.
If simultaneous operation fails but offset operation works, the delay is diagnostic evidence, not a finished repair. It may hide a shared stream bottleneck, a non-reentrant processing tool or a communication lock.
Two cameras usually require distinct device ownership and stream resources. Review multi-camera acquisition session architecture before assuming that a second workflow creates an independent acquisition path.
5. Separate acquisition capacity from processing capacity
A camera must be ready for the next accepted trigger. However, whether exposure, readout and transfer overlap depends on the device and operating mode. Do not add every stage duration automatically.
For an illustrative non-overlapping acquisition path, use:
Suppose measured timings are 18 ms exposure, 7 ms readout and transfer, and a chosen 5 ms timing allowance:
- Readiness interval: 18 + 7 + 5 = 30 ms.
- Estimated acquisition ceiling: 1 / 0.030 ≈ 33 frames/s.
- Requested trigger rate: 20 pulses/s, giving a 50 ms interval.
Acquisition appears capable of accepting that request under these assumptions. Now suppose processing takes 80 ms per frame on a single worker:
- Processing capacity: 1 / 0.080 = 12.5 frames/s.
- Queue growth: 20 − 12.5 = 7.5 frames/s.
- An initially empty queue with 30 available slots fills in 30 / 7.5 = 4 seconds.
These are example system timings, not specifications for the products below. Real overlap behavior must come from documentation and measurement.
A larger buffer postpones this failure but does not remove it. Reduce demand, improve processing capacity or use documented backpressure. For acquisition-side timing, compare your measurements with the external-pulse frame-rate checks.
6. Make workflow concurrency explicit
A character branch often selects a path within one execution context. It does not necessarily launch independent work. If one branch waits for an image or a network acknowledgment, another branch may never enter its acquisition step.
Trace these timestamps for each camera:
- Request received.
- Workflow dispatched.
- Acquisition armed.
- Input event or exposure observed.
- Complete frame received.
- Processing started and completed.
- Result transmitted and acknowledged.
Use a monotonic host clock for elapsed durations. Do not compare timestamps from separate devices as if they share a clock unless synchronization has been established.
For independent operation, each path needs clearly defined ownership of acquisition, processing state and result routing. For simultaneous requests, use software features documented to support concurrent execution. Confirm that processing tools and communication components are safe for that execution model.
Keep acquisition callbacks short. Where the SDK permits it, hand off images through a bounded queue with documented buffer ownership. Do not return a buffer for reuse while another worker still reads it.
The callback and buffer-queue troubleshooting guide addresses this boundary. Merely adding a thread can introduce another failure if both workers modify shared state.
7. Associate every frame with the correct result
Even perfect triggering is insufficient if an old frame is processed or a result is sent to the wrong destination.
Maintain a record containing camera identity, inspection identity, available frame identifier, acquisition status, processing status and destination. Carry that record through the workflow instead of looking up a shared variable named “latest image.”
Define the relationship between commands and physical pulses. A received command may authorize an inspection, while a later pulse causes exposure. If either can arrive independently, specify how they are matched and when unmatched events expire.
For paired inspections, state whether both images are mandatory. If camera A succeeds and camera B times out, do not silently combine A's new image with B's previous image. Report an incomplete pair and follow the machine's documented recovery behavior.
Record acknowledgments against the same inspection identity. A reply confirming receipt is not necessarily confirmation that motion or another downstream action completed. Preserve those distinctions in the interface contract.
8. Check network permissions without disabling protection
If exposure occurs but complete images do not arrive, inspect the transport path before changing trigger wiring again.
Check the selected network adapter, camera addressing, stream destination, application binding, transport counters and host security logs. Simultaneous image transfers can create bursts even when average traffic appears acceptable.
Use the network-congestion diagnostic guide to distinguish transport loss from application blocking. If the fault follows security policy, use GigE Vision firewall troubleshooting.
Do not disable the firewall or remove endpoint protection as a production fix. Ask the responsible administrator to review blocked traffic and create narrowly scoped permissions for the documented application and transport requirements. Restrict permissions to the required adapters, devices, protocols and network profile where supported.
If policy blocks an executable or driver, use the approved deployment process and manufacturer-distributed software. Do not obtain replacement drivers from unofficial download sites.
A controlled test should preserve protection, change one approved rule at a time and record the result. Restore unnecessary test permissions afterward. If complete frames already arrive reliably, network-policy changes are unlikely to explain a workflow that never starts processing.
9. Check replacement parts only after locating the fault
Changing cameras is not the first response to an application-specific failure. Keep the known-working hardware until evidence identifies a limitation or defect.
When replacement is justified, compare area scan cameras through the camera finder. Confirm trigger input specifications, acquisition modes, readiness signaling, SDK support and simultaneous-stream requirements separately. The catalog details supplied here do not establish those trigger capabilities.
The LS-CMR-0053 is a GigE area scan camera.
- Sensor format
- 1/1.7"
- Interface
- GigE
- Resolution
- 12 MP
- Shutter
- Rolling
The LS-CMR-0166 is a USB3 area scan camera.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Resolution
- 12 MP
- Shutter
- Rolling
These are interface alternatives for evaluation, not a proposed synchronized pair. A different interface changes the transport checks; it does not repair blocked workflow execution.
For a GigE data connection, review the LS-CBL-0199.
For a USB3 data connection, review the LS-CBL-0218.
Neither data-cable selection establishes compatibility with a separate trigger connector. Use the accessories finder to identify the required cable type, then verify connector details and routing requirements.
If the application needs dedicated acquisition hardware, evaluate vision controllers against measured concurrent workloads. Port count alone does not establish independent bandwidth, supported camera access or processing capacity.
10. Verify the repair and prevent recurrence
Use an acceptance checklist that tests the complete inspection, not just image display:
- Independent operation: each camera responds while the other remains armed but idle.
- Simultaneous operation: both paths meet the required trigger pattern without unexplained count differences.
- Frame integrity: incomplete or missing images produce explicit faults rather than stale results.
- Queue stability: occupancy remains bounded instead of increasing throughout the run.
- Result routing: each destination receives only its assigned inspection results.
- Restart behavior: documented startup sequencing restores the intended settings and device ownership.
- Communication recovery: a delayed acknowledgment does not block unrelated acquisition indefinitely.
- Security configuration: approved permissions remain narrow and documented.
As an example acceptance run, 30 minutes at 10 pulses/s produces 30 × 60 × 10 = 18,000 requested exposures per camera. Choose a rate the actual system supports. Reconcile counts and explain every rejected request; a long run with unexplained losses is not a pass.
Keep settings readback, timing logs, counter snapshots and software versions with the machine documentation. For part selection, start the camera configurator. For an unresolved fault, send the test matrix and measured failure boundary through technical support.
Questions
Why does hardware triggering work in a camera utility but not in the application?
A setup utility and a production application may select different inputs, trigger selectors or acquisition modes. The application may also overwrite stored settings during startup. Close competing camera clients, read back the effective configuration after initialization, and verify that acquisition is armed before applying the physical pulse.
Can one hardware trigger output drive both cameras?
Possibly, but only if the output can drive both documented input circuits while maintaining valid electrical levels and pulse timing. Check loading, polarity, isolation and reference connections. A common pulse also does not guarantee equal exposure timing; camera latency and shutter behavior still require verification.
Why can both commands arrive while only one camera workflow runs?
Receiving a command confirms only that the communication stage accepted data. Dispatch, acquisition readiness, exposure, image transfer and processing are separate events. Log entry and completion at each boundary. If a workflow waits synchronously for an image or acknowledgment, another selected branch may remain blocked.
Should a delay between camera triggers be the permanent fix?
No fixed delay is a general repair. An offset can reveal contention by reducing simultaneous demand, but it may conceal insufficient bandwidth, shared application state or a blocking component. Measure the failing boundary first, then establish a documented scheduling or capacity solution that meets the required inspection timing.
How should firewall-related image failures be tested safely?
Use security logs and transport diagnostics to identify blocked traffic, then request narrowly scoped permissions through the approved administration process. Keep the firewall and endpoint protection enabled. If complete images already arrive, investigate processing and communication scheduling rather than changing network security rules.