Changes in Light Actuator behavior: Lighting turns ON before nozzle movement

33 views
Skip to first unread message

ORIS ORIS

unread,
Aug 7, 2026, 2:02:01 PM (2 days ago) Aug 7
to OpenPnP
Hi everyone,

I would like to ask about a recent change in the behavior of the camera lighting actuator in newer OpenPNP versions.

The Question:
From which version did the bottom camera light actuator start triggering BEFORE the nozzle moves to the camera, and what was the architectural reason for this change?

The Context:
In older versions of OpenPNP, the camera light turned ON strictly right before the part recognition started and turned OFF immediately after the recognition was complete. This was the ideal setup for my machine.

Then, in later versions, the light stopped turning OFF between multi-nozzle movements and during nozzle calibration steps. I assumed this was implemented to eliminate physical lighting delays (actuator overhead). However, in the latest releases, the light turns ON *before* the nozzle even initiates its travel movement toward the bottom camera.

The Problem:
I am running a high-end industrial camera at 1500 FPS paired with an ultra-powerful synchronized flash lighting system (15,000 Lumens). Because OpenPNP now keeps the lighting actuator active throughout the entire travel phase, it creates an intensely blinding strobe effect that makes it visually impossible and unsafe to watch the machine operate. Furthermore, due to the extreme power density and a very tight thermal envelope, this prolonged operation leads to severe overheating of the light-emitting diodes (LEDs).

Why standard workarounds fail:
1. Using JavaScript/Python scripts in `Camera.BeforeCapture` and `Camera.AfterCapture` introduces measurable execution overhead. More importantly, it still doesn't prevent OpenPNP's core scheduler from overriding or turning the light ON during unwanted phases.
2. My industrial camera has a dedicated hardware strobe output pin, but it is useless in this scenario because OpenPNP runs the camera in a streaming/continuous frame mode. The hardware strobe simply fires constantly at the camera's high frame rate.

What is needed:
We need a dedicated mechanism or a configuration flag to force the light actuator to trigger strictly before a single capture frame and deactivate immediately after, without keeping it active during the travel/positioning phase.

Could anyone point me to the version where this behavior was modified, and is there any plan to make this pre-travel lighting behavior optional via settings?

Thanks in advance!
Reply all
Reply to author
Forward
0 new messages