ELP-USBGS1200P02 Global Shutter Camera Triggering in Open PnP

Mike Menci

unread,

Sep 21, 2025, 4:41:06 PMSep 21

to OpenPnP

We continue here because the subject is above mentioned camera model and not ELP-USBxxxx P01.

I enclose herewith the manual in Pdf which is reflecting above mentioned ELP-USBGS1200P02 Global Shutter Camera.
Tha manual is not actualy the same as the delivered camera. Actual delivery is two PCB - the top as per manual and the bottom with two small flash lights and two switches - one for triggering Flash and second one for Triggering Mode. This two PCBs are connected with standoff bolts and as well with 2 connectors with cable. One is + 5VDC /GND and the second one is 5pin connector.
So when you want to use this all you have is USB cable to connect but no output from pcb for external triggering. See pictures I enclose.
I can get a good (still standing - not motion) picture to Open PnP but I did not figure out how to get moving pictures into Open PnP - this is now holding me beck to continue testing.
I made myself a temporary Jig with up-looking ELP camera trug Coax Box, I have a moving X axis with nozzle and servo driving head with a single nozzle for test... I have Yaskawa with CN1 and ELP camera connected trough Opto Sharp PC817.. & Yellow Blue cable on ELP camera.
Today I spend half a day trying to create a folder where images from triggering would end up for me to see them but up to now - nothing landed in this folder.
Eater triggering is not happening or capturing is not collecting images .... I do not have Oscilloscope to test - so visual is all I could do - see enclosed my vison collection folder ..
I hope I am on the right track - Jan - comment please.

IMG_7975.jpg

ELP-USBGS1200P02 Global Shutter Trigger operation Manual.pdf

2025-09-21 22_26_34-Bottom Vision Pipeline.png

IMG_7974 .jpg

ELP_Test Jig .jpg

Mike Menci

unread,

Sep 21, 2025, 4:52:55 PMSep 21

to OpenPnP

It would be great if " Community could add a “HardwarePositionTrigger” actuator ..... at some point in future..

Mike Menci

unread,

Sep 21, 2025, 5:15:37 PMSep 21

to OpenPnP

But it look like I had some success :

2025-09-21 23_13_25-C__Users_hp_.openpnp2_org.openpnp.vision.pipeline.stages.ImageWriteDebug - File .png

Mike Menci

unread,

Sep 22, 2025, 1:41:41 AMSep 22

to OpenPnP

Jan
I received attached reply from ELP - which means that bottom PCB is not mandatory if you use your own triggering - therefore the 5pin connector is free and can be used for external triggering ...

ELP trigger Email.png

Jan

unread,

Sep 23, 2025, 5:28:35 AMSep 23

to ope...@googlegroups.com

Hi Mike!
Many thanks for sharing this information!
Concerning your questions: I'd say that there is an added difficulty
with hardware triggering that is, that you have to generate a trigger
when OpenPnp wont to have a picture from the camera. At present there so
such thing like a a hardware position trigger. However, you could make
use of the scripting engine. According to the logs there is a
"Camera.BeforeCapture". However^2 I'm not sure if that script is also
executed if the camera is used for preview.
In an other post you mentioned, that you'd like to trigger the camera
using position sensors in your motor drivers. You may try that. I'm sure
it will work if you pick from the same feeder and go straight for bottom
vision. With the logging level set to debug you'd probably find out if
there is any other script that could be facilitate to arm this trigger.
Please keep us posted.

Jan

On 22.09.2025 07:41, Mike Menci wrote:
> Jan
> I received attached reply from ELP - which means that bottom PCB is not
> mandatory if you use your own triggering - therefore the 5pin connector
> is free and can be used for external triggering ...
>
> On Sunday, 21 September 2025 at 23:15:37 UTC+2 Mike Menci wrote:
>
> But it look like I had some success :
>
> On Sunday, 21 September 2025 at 22:52:55 UTC+2 Mike Menci wrote:
>
> It would be great if " Community could adda

> “HardwarePositionTrigger” actuator..... at some point in future..

> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> openpnp/4043b9fd-df48-4955-bcd8-eb1d7bea56dcn%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/4043b9fd-df48-4955-bcd8-
> eb1d7bea56dcn%40googlegroups.com?utm_medium=email&utm_source=footer>.

Mike Menci

unread,

Oct 14, 2025, 5:19:36 PMOct 14

to OpenPnP

Hi all,

Goal
I’d like OpenPnP to take one snapshot from the bottom camera each time the nozzle X-coordinate enters the 152–159 mm window (camera view) during normal jogging or job moves.

What already works

I have a Bean-shell script (snapOverCamera.bsh) that:
– checks nozzle.getLocation().getX()
– uses an edge-trigger so it fires only once per pass
– saves the PNG to snapshots/
Manually clicking the script works perfectly (picture appears, no error)
Post-command script line ${SCRIPT:scripts/snapOverCamera.bsh} in the driver is ignored (async driver, stable 2.4)
Nozzle-tip “Post-Move-Script” field is not visible in my 2.5-test build (panel ends at Max. Pick Tolerance; Scripts ▶ bar is missing)

What I need
A hook that runs after every nozzle move (jog or job) so the script can decide whether to snap.
I’m happy to use driver G-code, actuator, pipeline, signaller, or nozzle-tip – whichever is guaranteed to exist in stable 2.4 / test 2.5.

Could someone point me to the correct GUI path or XML tag that actually fires after every move in the async driver?

Thanks in advance!

Jan

unread,

Oct 16, 2025, 4:52:57 AMOct 16

to ope...@googlegroups.com

Hi Mike!
A nozzle is just a specific type of head mountable for OpenPnP, so
there is no script that can be liked to a specific nozzle.
There are script hooks - which I'm sure you already know - for
Camera.BeforeCapture and Camera.AfterCapture. This are likely to late
for your usecase.
What about creating a profile acuator that operates your camera
light and a new ScriptActuator. This actuator could then be used as the
camera Light Actuator and it would switch the light on and call a
script. This actuator shall - if machine coordinate is disabled - been
called when the head is on the way to the camera (to take a picture) and
when the head is living the camera (after taking a picture).

Jan

On 14.10.2025 23:19, Mike Menci wrote:
> Hi all,
> Goal
> I’d like OpenPnP to take one snapshot from the bottom camera each time
> the nozzle X-coordinate enters the 152–159 mm window (camera view)
> during normal jogging or job moves.
> What already works
>

> *

> I have a Bean-shell script (snapOverCamera.bsh) that:
> – checks nozzle.getLocation().getX()
> – uses an edge-trigger so it fires only once per pass
> – saves the PNG to snapshots/

> *

> Manually clicking the script works perfectly (picture appears, no error)

> *

> Post-command script line ${SCRIPT:scripts/snapOverCamera.bsh} in the
> driver is ignored (async driver, stable 2.4)

> *

> Nozzle-tip “Post-Move-Script” field is not visible in my 2.5-test

> build (panel ends at /Max. Pick Tolerance/; Scripts ▶ bar is missing)

> <https://groups.google.com/d/msgid/>
> > openpnp/4043b9fd-df48-4955-bcd8-eb1d7bea56dcn%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/openpnp/4043b9fd-df48-4955-
> bcd8- <https://groups.google.com/d/msgid/openpnp/4043b9fd-df48-4955-
> bcd8->
> > eb1d7bea56dcn%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/34ec82a8-18ec-4fb4-a4c5-7b57cc0b7cc3n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4-
> a4c5-7b57cc0b7cc3n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Mike Menci

unread,

Oct 16, 2025, 6:56:10 AMOct 16

to OpenPnP

Hi Jan – thanks, that exactly matches my use-case!

I already:

created a ReferenceActuator (CamSnapActuator, driver PNPBOARDV1.7, index 0, actuate value M400)
added ScriptActuator wrapper and pointed it to scripts/snapOverCamera.bsh
pasted the edge-trigger script (152–159 mm window, one PNG per pass) – works perfectly when clicked manually

What I still miss
How do I wire the ScriptActuator to the bottom-camera light circuit so OpenPnP calls it automatically on every approach / leave?

GUI path we see
Machine Setup → Cameras → Bottom Vision ELP → Actuator drop-down only lists “Bottom_Cam_Lights” (a plain M42 actuator), not our CamSnapActuator.

Question
Do I:

replace the existing Bottom_Cam_Lights actuator with our ScriptActuator, or
chain the two actuators (light + script) in series, or
use a different hook (e.g. Head → Actuator → Before/After Move) that always fires when the head crosses the camera?

A one-sentence GUI path (or tiny XML snippet) would close the loop – I am one click away of testing it with slow and speed motion!

Thanks again,

Jan

unread,

Oct 16, 2025, 7:26:56 AMOct 16

to ope...@googlegroups.com

Hi Mike!
ProfileActuators shall provide the chaining you like to have
(https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#actuator-with-profiles).
You may try the following:
- create a ReferenceActuator close to your cameras up-light actuator (on
machine level)
- Change its "Value Type" to "Profile" -> Apply
- Select the new "Profiles" tab
- Choose your script as "Actuator 1" and your camera light as "Actuator
2" -> Apply (I assume that Actuator 1 is called before Actuator 2 so the
machine coordination setting for the camera light shall not delay the
script execution)
- In the table below add two new profiles.
- According to the Wiki a profile where "Default ON" is ticked is
executed if a boolean operation is set ON/TRUE (thats what happens when
the camera light is switched on) and "Default OFF" if a boolean
operation is set OFF/FALSE. You shall select "Default ON" in one profile
and "Default OFF" in the other and select the light in the "Default ON"
one. (IIRC the selection state is the value the target actuator is
called with.)
Now go to your camera and choose the new profile actuator as your
camera light.
If everything works as intended, the camera will call the profile
actuator to switch the light on/off and the new profile actuator will
call your script and the old/physical camera light actuator.
If you select your script in the "Default ON" profile, your script
shall be called with TRUE if the head will be moved towords the camera
(light is going to be switched on) and FALSE if the head is leaving the
camera.

Jan

On 16.10.2025 12:56, Mike Menci wrote:
> Hi Jan – thanks, that exactly matches my use-case!
> I already:
>

> *

> created a ReferenceActuator (CamSnapActuator, driver PNPBOARDV1.7,
> index 0, actuate value M400)

> *

> added ScriptActuator wrapper and pointed it to scripts/
> snapOverCamera.bsh

> *

> pasted the edge-trigger script (152–159 mm window, one PNG per pass)
> – works perfectly when clicked manually
>
> What I still miss
> How do I wire the ScriptActuator to the bottom-camera light circuit so
> OpenPnP calls it automatically on every approach / leave?
> GUI path we see
> Machine Setup → Cameras → Bottom Vision ELP → Actuator drop-down only
> lists “Bottom_Cam_Lights” (a plain M42 actuator), not our CamSnapActuator.
> Question
> Do I:
>

> 1.

> replace the existing Bottom_Cam_Lights actuator with our
> ScriptActuator, or

> 2.

> chain the two actuators (light + script) in series, or

> 3.

> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>>
> > > openpnp/4043b9fd-df48-4955-bcd8-
> eb1d7bea56dcn%40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <https://groups.google.com/d/msgid/openpnp/4043b9fd-df48-4955-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd-df48-4955->
> > bcd8- <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> df48-4955- <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> df48-4955->
> > bcd8->
> > > eb1d7bea56dcn%40googlegroups.com <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?

> > utm_medium=email&utm_source=footer>>.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "OpenPnP" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to openpnp+u...@googlegroups.com
> > <mailto:openpnp+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > openpnp/34ec82a8-18ec-4fb4-a4c5-7b57cc0b7cc3n%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4-
> <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4->
> > a4c5-7b57cc0b7cc3n%40googlegroups.com?

> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/064f7f36-1441-4348-af9e-6049e2af74d3n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348-
> af9e-6049e2af74d3n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Mike Menci

unread,

Oct 17, 2025, 8:39:25 AMOct 17

to OpenPnP

Hi Jan,

Double-click in camera view → file appears in snapshots (camera / USB / host path OK).
Sending M42 P2 S0 G4 P50 M42 P2 S1 M400 manually from console → no file created (camera does not snap),
Oscilloscope shows the same 0→1→0 pulse on the same pin the host uses when double-clicking.
Therefore the Smoothieboard is driving the line, but the ELP module ignores it. Question: Is the ELP expecting the opposite edge (1→0) or a longer/shorter pulse than 50 ms? Could you confirm the exact logic the host sends when we double-click (level, width, edge)? Hardware: Smoothieboard 5X – pin P2 = GPIO port 2 / pin 2.4 on the board Thanks,

Jan

unread,

Oct 17, 2025, 9:10:14 AMOct 17

to ope...@googlegroups.com

Mi Mike!
I can only guess what you're trying to archive.
If you wont your camera to run on hardware trigger, you need to do two
things: a) create the trigger pulse and b) capture the image the camera
has taken.
If you double-click the camera view, OpenPnP will read an image from
the camera and store it into a file. I don't know it there is any option
to generate the trigger pulse before reading the image.
If you manually generate the trigger pulse, the camera will likely
capture an image, but there is no one to read it and no one to save it.
If you generate a 0-1-0 signal, you have both edges. So except for a
minor timing offsets you shall not see a difference whether the camera
expects a low to high or a high to low transition as trigger.
According to the figure in section 6 of the datasheet you posted
earlier, the rising edge is the reference point. Starting from the
rising edge of the trigger input, the camera will start exposure exactly
1.456ms later.
Btw: the M400 in the GCode you posted is likely not needed. It's
intended to wait/delay until moves have finished.

Jan

On 17.10.2025 14:39, Mike Menci wrote:
> Hi Jan,
>
> 1.

> Double-click in camera view → file appears in snapshots (camera /
> USB / host path OK).

> 2.
> SendingM42 P2 S0 G4 P50 M42 P2 S1 M400manually from console → no
> file created(camera does notsnap),
> 3.

> Oscilloscope shows the same 0→1→0 pulseon the same pinthe host uses
> when double-clicking.

> 4.
> Therefore the Smoothieboardisdriving the line, but the ELP module
> ignores it.Question: Is the ELP expecting the opposite edge(1→0) or
> a longer/shorter pulsethan 50 ms? Could you confirm the exact logic

> the host sends when we double-click (level, width, edge)? Hardware:

> Smoothieboard 5X– pin P2= GPIO port 2 / pin 2.4on the board Thanks,

>
>
> On Thursday, 16 October 2025 at 13:26:56 UTC+2 Jan wrote:
>
> Hi Mike!
> ProfileActuators shall provide the chaining you like to have
> (https://github.com/openpnp/openpnp/wiki/Setup-and-

> Calibration_Actuators#actuator-with-profiles <https://github.com/
> openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#actuator-with-
> profiles>).

> > msgid/ <https://groups.google.com/d/msgid/ <https://

> groups.google.com/d/msgid/>>
> > > <https://groups.google.com/d/msgid/ <https://groups.google.com/

> d/msgid/> <https://groups.google.com/d/ <https://groups.google.com/d/>

> > msgid/>>
> > > > openpnp/4043b9fd-df48-4955-bcd8-
> > eb1d7bea56dcn%40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>
> > > <http://40googlegroups.com <http://40googlegroups.com>

> <http://40googlegroups.com <http://40googlegroups.com>>>

> <http://40googlegroups.com <http://40googlegroups.com>>?

> > > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>

> > <http://40googlegroups.com <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer>>.
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "OpenPnP" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > send
> > > an email to openpnp+u...@googlegroups.com
> > > <mailto:openpnp+u...@googlegroups.com>.

> > > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>>

> > > openpnp/34ec82a8-18ec-4fb4-
> a4c5-7b57cc0b7cc3n%40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4-
> <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4->
> > <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4-
> <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4->>
> > > a4c5-7b57cc0b7cc3n%40googlegroups.com <http://40googlegroups.com>?

> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>>.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "OpenPnP" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to openpnp+u...@googlegroups.com
> > <mailto:openpnp+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/>

> > openpnp/064f7f36-1441-4348-af9e-6049e2af74d3n%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348-
> <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348->
> > af9e-6049e2af74d3n%40googlegroups.com?

> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/openpnp/

> ebdaedb9-e3a1-4716-944e-9ab8e6d7fb68n%40googlegroups.com <https://
> groups.google.com/d/msgid/openpnp/ebdaedb9-
> e3a1-4716-944e-9ab8e6d7fb68n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

bert shivaan

unread,

Oct 17, 2025, 9:16:46 AMOct 17

to ope...@googlegroups.com

How does openPNP know when to ask for the image from the camera?

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/a32ca87c-d253-4431-829a-3855c566ad64%40googlemail.com.

Jan

unread,

Oct 17, 2025, 9:43:22 AMOct 17

to ope...@googlegroups.com

OpenPnP requests an image when needed: either because preview is enabled
or bottom vision is requested. Actually its not "requesting" as on
normal cameras, images are taken all the time using a camera internal
trigger. The image is then transferred into the computer limited by the
speed of the computer reading the image and the camera providing one.
Internally the CV module gets every image the camera provides, but it
only hands over an image for preview or bottom vision if requested. So
the majority of images is captures and send to the computer but dropped
in the CV module.
With hardware triggered cameras as Mike is using you can request an
image from the camera at a specific time. However, all the other stuff
might not be perfectly prepared for cameras only generating images on
request...

Jan

> > (https://github.com/openpnp/openpnp/wiki/Setup-and- <https://
> github.com/openpnp/openpnp/wiki/Setup-and->
> > Calibration_Actuators#actuator-with-profiles <https://
> github.com/ <https://github.com/>
> > openpnp/openpnp/wiki/Setup-and-
> Calibration_Actuators#actuator-with-

> <mailto:openpnp%2Bu...@googlegroups.com>
> > > > > <mailto:openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bu...@googlegroups.com>>.

> > > > > To view this discussion visit https://
> groups.google.com/d/ <https://groups.google.com/d/>
> > <https://groups.google.com/d/ <https://groups.google.com/d/>>
> > > msgid/ <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://

> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>>>
> > > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://groups.google.com/ <https://
> groups.google.com/>
> > d/msgid/> <https://groups.google.com/d/ <https://
> groups.google.com/d/> <https://groups.google.com/d/ <https://

> <http://40googlegroups.com <http://40googlegroups.com>>>>

> > > > > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > df48-4955- <https://groups.google.com/d/msgid/

> openpnp/4043b9fd- <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > df48-4955->
> > > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> df48-4955- <https://groups.google.com/d/msgid/openpnp/4043b9fd-

> df48-4955->
> > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> df48-4955- <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> df48-4955->>>

> > > > bcd8- <https://groups.google.com/d/msgid/
> openpnp/4043b9fd- <https://groups.google.com/d/msgid/openpnp/4043b9fd->

> > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->>
> > > df48-4955- <https://groups.google.com/d/msgid/
> openpnp/4043b9fd- <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->>
> > > df48-4955->
> > > > bcd8->
> > > > > eb1d7bea56dcn%40googlegroups.com
> <http://40googlegroups.com> <http://40googlegroups.com
> <http://40googlegroups.com>>

> > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>?
> > > > utm_medium=email&utm_source=footer

> <http://40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <http://40googlegroups.com <http://40googlegroups.com>

> <http://40googlegroups.com <http://40googlegroups.com>>>?
> > > > utm_medium=email&utm_source=footer>>.
> > > >
> > > > --
> > > > You received this message because you are subscribed to
> the Google
> > > > Groups "OpenPnP" group.
> > > > To unsubscribe from this group and stop receiving emails
> from it,
> > > send
> > > > an email to openpnp+u...@googlegroups.com

> <mailto:openpnp%2Bu...@googlegroups.com>
> > > > <mailto:openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bu...@googlegroups.com>>.

> > > > To view this discussion visit https://groups.google.com/

> d/ <https://groups.google.com/d/>

> > msgid/ <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>>
> > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://groups.google.com/d/ <https://
> groups.google.com/d/>

> > msgid/>>
> > > > openpnp/34ec82a8-18ec-4fb4-
> > a4c5-7b57cc0b7cc3n%40googlegroups.com
> <http://40googlegroups.com> <http://40googlegroups.com
> <http://40googlegroups.com>>

> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>
> > > > <https://groups.google.com/d/msgid/

> openpnp/34ec82a8-18ec-4fb4- <https://groups.google.com/d/msgid/
> openpnp/34ec82a8-18ec-4fb4->
> > <https://groups.google.com/d/msgid/
> openpnp/34ec82a8-18ec-4fb4- <https://groups.google.com/d/msgid/
> openpnp/34ec82a8-18ec-4fb4->>
> > > <https://groups.google.com/d/msgid/
> openpnp/34ec82a8-18ec-4fb4- <https://groups.google.com/d/msgid/
> openpnp/34ec82a8-18ec-4fb4->
> > <https://groups.google.com/d/msgid/
> openpnp/34ec82a8-18ec-4fb4- <https://groups.google.com/d/msgid/

> openpnp/34ec82a8-18ec-4fb4->>>
> > > > a4c5-7b57cc0b7cc3n%40googlegroups.com
> <http://40googlegroups.com> <http://40googlegroups.com

> <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer
> <http://40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer>>.
> > >
> > > --
> > > You received this message because you are subscribed to
> the Google
> > > Groups "OpenPnP" group.
> > > To unsubscribe from this group and stop receiving emails
> from it,
> > send
> > > an email to openpnp+u...@googlegroups.com

> <mailto:openpnp%2Bu...@googlegroups.com>
> > > <mailto:openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bu...@googlegroups.com>>.

> > > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>>

> > > openpnp/064f7f36-1441-4348-
> af9e-6049e2af74d3n%40googlegroups.com <http://40googlegroups.com>

> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <https://groups.google.com/d/msgid/

> openpnp/064f7f36-1441-4348- <https://groups.google.com/d/msgid/
> openpnp/064f7f36-1441-4348->
> > <https://groups.google.com/d/msgid/
> openpnp/064f7f36-1441-4348- <https://groups.google.com/d/msgid/
> openpnp/064f7f36-1441-4348->>
> > > af9e-6049e2af74d3n%40googlegroups.com

> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>>.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "OpenPnP" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to openpnp+u...@googlegroups.com

> <mailto:openpnp%2Bunsu...@googlegroups.com>
> > <mailto:openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bunsu...@googlegroups.com>>.

> > To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/ <https://groups.google.com/d/msgid/openpnp/>
> > ebdaedb9-e3a1-4716-944e-9ab8e6d7fb68n%40googlegroups.com
> <http://40googlegroups.com> <https://
> > groups.google.com/d/msgid/openpnp/ebdaedb9- <http://
> groups.google.com/d/msgid/openpnp/ebdaedb9->
> > e3a1-4716-944e-9ab8e6d7fb68n%40googlegroups.com

> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to openpnp+u...@googlegroups.com

> <mailto:openpnp%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/a32ca87c-d253-4431-829a-3855c566ad64%40googlemail.com
> <https://groups.google.com/d/msgid/openpnp/a32ca87c-
> d253-4431-829a-3855c566ad64%40googlemail.com>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/openpnp/

> CA%2BKNHNz%2BJYK_ZBrLyTuv9%3D_JLRab1pf%3D-
> O2J214fL0Vpg563yA%40mail.gmail.com <https://groups.google.com/d/msgid/
> openpnp/CA%2BKNHNz%2BJYK_ZBrLyTuv9%3D_JLRab1pf%3D-
> O2J214fL0Vpg563yA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

bert shivaan

unread,

Oct 17, 2025, 10:22:46 AMOct 17

to ope...@googlegroups.com

So this is my concern. Does the camera retain the image until either another trigger? Or does it "loose" the image after some amount of time?

If it retains it, then maybe this is not too bad as at least there is no huge timing issue for single nozzle machines. OpenPNP could maybe time grabbing the image based on head speed and distance. So for instance 1 sec after sending the "move over the camera" sequence of moves, fetch the image.

This will get harder when more nozzles.

My old commercial machine had adjustments for how long to delay incase the image was not centered enough. Seems like this could be the same?

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/56a8ff16-8730-4bd5-b002-278e78acf17f%40googlemail.com.

bert shivaan

unread,

Oct 17, 2025, 10:24:33 AMOct 17

to ope...@googlegroups.com

Also why I was thinking about a cheap DIY frame grabber fashioned from a Pi or something. It could trigger and grab the image for multiple nozzles, then hand them to OpenPNP on request. But likely not needed here at all.

Mike Menci

unread,

Oct 17, 2025, 11:23:29 AMOct 17

to OpenPnP

Thanks Jan.
I confirm the rising-edge pulse is generated and the camera does expose (LED blinks).
Could you give me the single G-code or script command that tells OpenPnP to
“grab the frame now and save it to snapshots”, exactly like the double-click does?
I’ll append it right after the trigger pulse so the whole cycle becomes automatic.
Thanks

Jan

unread,

Oct 20, 2025, 5:45:31 AMOct 20

to ope...@googlegroups.com

Mi Bert!
That's likely a question of the cameras sensor chip. If the image is
retained in the sensor array until read by the computer, it will very
likely degrade over a short period of time. If the sensor chip has a
frame grabber in which he stores the image until readout, it will not
degrade but might still be subject to some kine of timeout dropping
behavior.
Anyhow, for OpenPnP we have two aspects to consider: a) OpenPnP is not
(yet) prepared for synchronous camera as the wast majority out their
works asynchronously (self triggered) and b) in all cases I can image
the camera image is requested for immediate use hence there are no delay
and/or storage requirement.

Jan

> <mailto:ope...@googlegroups.com <mailto:ope...@googlegroups.com>>>

> <https://github.com/openpnp/openpnp/wiki/Setup-and-> <https://
> > github.com/openpnp/openpnp/wiki/Setup-and- <http://github.com/
> openpnp/openpnp/wiki/Setup-and->>
> > > Calibration_Actuators#actuator-with-profiles <https://
> > github.com/ <http://github.com/> <https://github.com/ <https://

> > <mailto:openpnp%2Bu...@googlegroups.com
> <mailto:openpnp%252Bu...@googlegroups.com>>
> > > > > > <mailto:openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bu...@googlegroups.com>
> > <mailto:openpnp%2Bu...@googlegroups.com
> <mailto:openpnp%252Bu...@googlegroups.com>>>.

> > > > > > To view this discussion visit https://

> > groups.google.com/d/ <http://groups.google.com/d/> <https://

> groups.google.com/d/ <https://groups.google.com/d/>>
> > > <https://groups.google.com/d/ <https://
> groups.google.com/d/> <https://groups.google.com/d/ <https://
> groups.google.com/d/>>>

> > > > msgid/ <https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/> <https://

> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>>
> <https://
> > > groups.google.com/d/msgid/ <http://groups.google.com/d/
> msgid/> <http://groups.google.com/d/msgid/ <http://

> groups.google.com/d/msgid/>>>>
> > > > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>>

> <https://groups.google.com/ <https://groups.google.com/> <https://
> > groups.google.com/ <http://groups.google.com/>>

> > > d/msgid/> <https://groups.google.com/d/ <https://

> groups.google.com/d/> <https://
> > groups.google.com/d/ <http://groups.google.com/d/>> <https://

> groups.google.com/d/ <https://groups.google.com/d/> <https://

> > groups.google.com/d/ <http://groups.google.com/d/>>>
> > > > msgid/>>
> > > > > > openpnp/4043b9fd-df48-4955-bcd8-
> > > > eb1d7bea56dcn%40googlegroups.com

> <http://40googlegroups.com <http://40googlegroups.com>>>>>

> > > > > > <https://groups.google.com/d/msgid/
> openpnp/4043b9fd- <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->>
> > > df48-4955- <https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > openpnp/4043b9fd- <https://groups.google.com/d/msgid/

> openpnp/4043b9fd- <https://groups.google.com/d/msgid/openpnp/4043b9fd->>
> > > df48-4955->
> > > > <https://groups.google.com/d/msgid/
> openpnp/4043b9fd- <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > df48-4955- <https://groups.google.com/d/msgid/
> openpnp/4043b9fd- <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > df48-4955->
> > > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > df48-4955- <https://groups.google.com/d/msgid/
> openpnp/4043b9fd- <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > df48-4955->>>

> > > > > bcd8- <https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/>
> > openpnp/4043b9fd- <https://groups.google.com/d/msgid/

> openpnp/4043b9fd- <https://groups.google.com/d/msgid/openpnp/4043b9fd->>
> > > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->

> > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->>>
> > > > df48-4955- <https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > openpnp/4043b9fd- <https://groups.google.com/d/msgid/

> openpnp/4043b9fd- <https://groups.google.com/d/msgid/openpnp/4043b9fd->>
> > > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->

> > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->>>
> > > > df48-4955->
> > > > > bcd8->
> > > > > > eb1d7bea56dcn%40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> <http://40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>>

> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>
> > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>>?
> > > > > utm_medium=email&utm_source=footer

> > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>
> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>
> > > > <http://40googlegroups.com
> <http://40googlegroups.com> <http://40googlegroups.com
> <http://40googlegroups.com>>
> > <http://40googlegroups.com <http://40googlegroups.com>

> <http://40googlegroups.com <http://40googlegroups.com>>>>?
> > > > > utm_medium=email&utm_source=footer>>.
> > > > >
> > > > > --
> > > > > You received this message because you are
> subscribed to
> > the Google
> > > > > Groups "OpenPnP" group.
> > > > > To unsubscribe from this group and stop receiving
> emails
> > from it,
> > > > send
> > > > > an email to openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bu...@googlegroups.com>

> > <mailto:openpnp%2Bu...@googlegroups.com
> <mailto:openpnp%252Bu...@googlegroups.com>>
> > > > > <mailto:openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bu...@googlegroups.com>
> > <mailto:openpnp%2Bu...@googlegroups.com
> <mailto:openpnp%252Bu...@googlegroups.com>>>.

> > > > > To view this discussion visit https://

> groups.google.com/ <https://groups.google.com/>
> > d/ <https://groups.google.com/d/ <https://groups.google.com/d/>>

> > > msgid/ <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>>>
> > > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>>

> <https://groups.google.com/d/ <https://groups.google.com/d/> <https://
> > groups.google.com/d/ <http://groups.google.com/d/>>

> > > msgid/>>
> > > > > openpnp/34ec82a8-18ec-4fb4-
> > > a4c5-7b57cc0b7cc3n%40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> <http://40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>>

> > > > <http://40googlegroups.com
> <http://40googlegroups.com> <http://40googlegroups.com
> <http://40googlegroups.com>>
> > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>>

> > > > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>

> > openpnp/34ec82a8-18ec-4fb4- <https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > openpnp/34ec82a8-18ec-4fb4->
> > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>
> > openpnp/34ec82a8-18ec-4fb4- <https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > openpnp/34ec82a8-18ec-4fb4->>
> > > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>
> > openpnp/34ec82a8-18ec-4fb4- <https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > openpnp/34ec82a8-18ec-4fb4->
> > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>
> > openpnp/34ec82a8-18ec-4fb4- <https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>

> > openpnp/34ec82a8-18ec-4fb4->>>
> > > > > a4c5-7b57cc0b7cc3n%40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> <http://40googlegroups.com <http://40googlegroups.com>

> > <http://40googlegroups.com <http://40googlegroups.com>>>?
> > > > utm_medium=email&utm_source=footer
> > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>
> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>?
> > > > utm_medium=email&utm_source=footer>>.
> > > >
> > > > --
> > > > You received this message because you are subscribed to
> > the Google
> > > > Groups "OpenPnP" group.
> > > > To unsubscribe from this group and stop receiving
> emails
> > from it,
> > > send
> > > > an email to openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bu...@googlegroups.com>

> > <mailto:openpnp%2Bu...@googlegroups.com
> <mailto:openpnp%252Bu...@googlegroups.com>>
> > > > <mailto:openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bu...@googlegroups.com>
> > <mailto:openpnp%2Bu...@googlegroups.com
> <mailto:openpnp%252Bu...@googlegroups.com>>>.

> > > > To view this discussion visit https://
> groups.google.com/d/ <https://groups.google.com/d/>

> > msgid/ <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>>
> > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://

> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>>>
> > > > openpnp/064f7f36-1441-4348-
> > af9e-6049e2af74d3n%40googlegroups.com

> <http://40googlegroups.com> <http://40googlegroups.com
> <http://40googlegroups.com>>
> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>

> > > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>
> > openpnp/064f7f36-1441-4348- <https://groups.google.com/d/

> msgid/ <https://groups.google.com/d/msgid/>
> > openpnp/064f7f36-1441-4348->
> > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>

> > openpnp/064f7f36-1441-4348- <https://groups.google.com/d/

> msgid/ <https://groups.google.com/d/msgid/>
> > openpnp/064f7f36-1441-4348->>
> > > > af9e-6049e2af74d3n%40googlegroups.com
> <http://40googlegroups.com>

> > <http://40googlegroups.com <http://40googlegroups.com>>?

> > > utm_medium=email&utm_source=footer
> <http://40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer>>.
> > >
> > > --
> > > You received this message because you are subscribed to
> the Google
> > > Groups "OpenPnP" group.
> > > To unsubscribe from this group and stop receiving emails
> from it,
> > send
> > > an email to openpnp+u...@googlegroups.com

> <mailto:openpnp%2Bunsu...@googlegroups.com>
> > <mailto:openpnp%2Bunsu...@googlegroups.com
> <mailto:openpnp%252Buns...@googlegroups.com>>
> > > <mailto:openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bunsu...@googlegroups.com>
> > <mailto:openpnp%2Bunsu...@googlegroups.com
> <mailto:openpnp%252Buns...@googlegroups.com>>>.

> > > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>

> > openpnp/ <https://groups.google.com/d/msgid/openpnp/

> <https://groups.google.com/d/msgid/openpnp/>>
> > > ebdaedb9-e3a1-4716-944e-9ab8e6d7fb68n%40googlegroups.com
> <http://40googlegroups.com>

> > <http://40googlegroups.com <http://40googlegroups.com>> <https://
> > > groups.google.com/d/msgid/openpnp/ebdaedb9- <http://
> groups.google.com/d/msgid/openpnp/ebdaedb9-> <http://

> > groups.google.com/d/msgid/openpnp/ebdaedb9- <http://
> groups.google.com/d/msgid/openpnp/ebdaedb9->>
> > > e3a1-4716-944e-9ab8e6d7fb68n%40googlegroups.com
> <http://40googlegroups.com>

> > <http://40googlegroups.com <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer>.
> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "OpenPnP" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bunsu...@googlegroups.com>

> > <mailto:openpnp%2Bunsu...@googlegroups.com
> <mailto:openpnp%252Buns...@googlegroups.com>>.

> > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>

> > openpnp/a32ca87c-d253-4431-829a-3855c566ad64%40googlemail.com
> <http://40googlemail.com>
> > <https://groups.google.com/d/msgid/openpnp/a32ca87c-
> <https://groups.google.com/d/msgid/openpnp/a32ca87c->
> > d253-4431-829a-3855c566ad64%40googlemail.com
> <http://40googlemail.com>>.

> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "OpenPnP" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bunsu...@googlegroups.com>
> > <mailto:openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bunsu...@googlegroups.com>>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> openpnp/ <https://groups.google.com/d/msgid/openpnp/>

> > CA%2BKNHNz%2BJYK_ZBrLyTuv9%3D_JLRab1pf%3D-
> > O2J214fL0Vpg563yA%40mail.gmail.com <http://40mail.gmail.com>
> <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>
> > openpnp/CA%2BKNHNz%2BJYK_ZBrLyTuv9%3D_JLRab1pf%3D-
> > O2J214fL0Vpg563yA%40mail.gmail.com?
> utm_medium=email&utm_source=footer <http://40mail.gmail.com?

> utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to openpnp+u...@googlegroups.com
> <mailto:openpnp%2Bunsu...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/56a8ff16-8730-4bd5-b002-278e78acf17f%40googlemail.com
> <https://groups.google.com/d/msgid/openpnp/56a8ff16-8730-4bd5-
> b002-278e78acf17f%40googlemail.com>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/openpnp/

> CA%2BKNHNyzWT2F%3DrDP4ii-YnmX8vnBq4YHPdR9ubXOhNay6poCzQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/openpnp/CA%2BKNHNyzWT2F%3DrDP4ii-
> YnmX8vnBq4YHPdR9ubXOhNay6poCzQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

Jan

unread,

Oct 20, 2025, 6:05:40 AMOct 20

to ope...@googlegroups.com

Hi Mike!
I'm sorry, I can't: a) g-code is a language you use to talk to your
controller but the controller has not knowledge about your camera and b)
I'm not a scripting guy and hence does not know how to capture an image.
You might wont to check the example scripts or search the web. IIRC
there are easy to find scripts that move to each placement location and
take a shot for documentation purposes. You shall be able to reuse that.

Jan

On 17.10.2025 17:23, Mike Menci wrote:
> Thanks Jan.
> I confirm the rising-edge pulse is generated and the camera doesexpose
> (LED blinks).

> Could you give me the single G-code or script commandthat tells OpenPnP to

> > (https://github.com/openpnp/openpnp/wiki/Setup-and- <https://
> github.com/openpnp/openpnp/wiki/Setup-and->
> > Calibration_Actuators#actuator-with-profiles <https://github.com/

> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>>>
> > > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://groups.google.com/ <https://
> groups.google.com/>
> > d/msgid/> <https://groups.google.com/d/ <https://

> groups.google.com/d/> <https://groups.google.com/d/ <https://
> groups.google.com/d/>>

> > > msgid/>>
> > > > > openpnp/4043b9fd-df48-4955-bcd8-
> > > eb1d7bea56dcn%40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>
> > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>
> > > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>
> > <http://40googlegroups.com <http://40googlegroups.com>

> <http://40googlegroups.com <http://40googlegroups.com>>>>

> > > > > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > df48-4955- <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > df48-4955->

> > > <https://groups.google.com/d/msgid/openpnp/4043b9fd-df48-4955-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd-df48-4955->

> > <https://groups.google.com/d/msgid/openpnp/4043b9fd-df48-4955-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd-df48-4955->>>
> > > > bcd8- <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->

> > <https://groups.google.com/d/msgid/openpnp/4043b9fd- <https://

> groups.google.com/d/msgid/openpnp/4043b9fd->>
> > > df48-4955- <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->

> > <https://groups.google.com/d/msgid/openpnp/4043b9fd- <https://

> groups.google.com/d/msgid/openpnp/4043b9fd->>
> > > df48-4955->
> > > > bcd8->
> > > > > eb1d7bea56dcn%40googlegroups.com
> <http://40googlegroups.com> <http://40googlegroups.com
> <http://40googlegroups.com>>

> > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>?

> > > > utm_medium=email&utm_source=footer <http://40googlegroups.com

> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <http://40googlegroups.com <http://40googlegroups.com>

> <http://40googlegroups.com <http://40googlegroups.com>>>?
> > > > utm_medium=email&utm_source=footer>>.
> > > >
> > > > --
> > > > You received this message because you are subscribed to the
> Google
> > > > Groups "OpenPnP" group.
> > > > To unsubscribe from this group and stop receiving emails from
> it,
> > > send
> > > > an email to openpnp+u...@googlegroups.com
> > > > <mailto:openpnp+u...@googlegroups.com>.
> > > > To view this discussion visit https://groups.google.com/d/

> <https://groups.google.com/d/>
> > msgid/ <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>>
> > > <https://groups.google.com/d/msgid/ <https://groups.google.com/
> d/msgid/> <https://groups.google.com/d/ <https://groups.google.com/d/>
> > msgid/>>

> > > > openpnp/34ec82a8-18ec-4fb4-
> > a4c5-7b57cc0b7cc3n%40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>

> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>

> > > > <https://groups.google.com/d/msgid/
> openpnp/34ec82a8-18ec-4fb4- <https://groups.google.com/d/msgid/
> openpnp/34ec82a8-18ec-4fb4->

> > <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4-
> <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4->>
> > > <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4-
> <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4->
> > <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4-
> <https://groups.google.com/d/msgid/openpnp/34ec82a8-18ec-4fb4->>>
> > > > a4c5-7b57cc0b7cc3n%40googlegroups.com

> <http://40googlegroups.com> <http://40googlegroups.com
> <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer>>.
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "OpenPnP" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > send
> > > an email to openpnp+u...@googlegroups.com
> > > <mailto:openpnp+u...@googlegroups.com>.
> > > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>>

> > > openpnp/064f7f36-1441-4348-
> af9e-6049e2af74d3n%40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348-
> <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348->
> > <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348-
> <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348->>
> > > af9e-6049e2af74d3n%40googlegroups.com <http://40googlegroups.com>?

> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>>.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "OpenPnP" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to openpnp+u...@googlegroups.com
> > <mailto:openpnp+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/ <https://groups.google.com/d/msgid/openpnp/>
> > ebdaedb9-e3a1-4716-944e-9ab8e6d7fb68n%40googlegroups.com

> <http://40googlegroups.com> <https://
> > groups.google.com/d/msgid/openpnp/ebdaedb9- <http://
> groups.google.com/d/msgid/openpnp/ebdaedb9->

> > e3a1-4716-944e-9ab8e6d7fb68n%40googlegroups.com

> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/223c98d7-4ea5-4824-8a40-15e8df3fd9d7n%40googlegroups.com
> <https://groups.google.com/d/msgid/
> openpnp/223c98d7-4ea5-4824-8a40-15e8df3fd9d7n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

Mike Menci

unread,

Oct 20, 2025, 7:37:37 AMOct 20

to OpenPnP

Hi Jan — just a quick follow-up to confirm we’re on the right track.

We connected the ELP’s “snapshot” input to an Arduino Mega that shares the same ground.
OpenPnP is configured to send M240 on a separate serial port (COM9) immediately before each vision call.
The Mega sketch simply:

Copy

if (Serial1.read()) { // any byte digitalWrite(pin2, HIGH); delayMicroseconds(200); digitalWrite(pin2, LOW); Serial1.print("ok\n"); }

Pulse width 200 µs, 5 V level, single-shot.
Camera replies with a full-resolution frame within 30 ms — no smear or timeout.
OpenPnP receives the frame synchronously and continues the pick/place pipeline.

If you see any risk in this timing or level choice, please let me know — otherwise we’ll keep it as the default setup.
Thanks again for the guidance!

Jan

unread,

Oct 20, 2025, 8:03:47 AMOct 20

to ope...@googlegroups.com

Hi Mike!
The datasheet says (page 7) that the pulse width shall be at least 3ms.
(Changing this will not effect your over all timing as the cameras
trigger -> image is in computer well be the same)
Would you please share how you send the trigger pulse to the camera? Do
you use a Camera.BeforeCapture script?
Do you already know if camera preview still works with hardware
triggered camera?

Jan

On 20.10.2025 13:37, Mike Menci wrote:
> Hi Jan — just a quick follow-up to confirm we’re on the right track.
> We connected the ELP’s “snapshot” input to an Arduino Mega that shares
> the same ground.
> OpenPnP is configured to send M240 on a separate serial port (COM9)
> immediately before each vision call.
> The Mega sketch simply:
> Copy
> if (Serial1.read()) { // any byte digitalWrite(pin2, HIGH);
> delayMicroseconds(200); digitalWrite(pin2, LOW); Serial1.print("ok\n"); }
>

> *

> Pulse width 200 µs, 5 V level, single-shot.

> *

> Camera replies with a full-resolution frame within 30 ms — no smear
> or timeout.

> *

> github.com/openpnp/openpnp/wiki/Setup-and-> <https://
> > github.com/openpnp/openpnp/wiki/Setup-and- <http://github.com/
> openpnp/openpnp/wiki/Setup-and->>
> > > Calibration_Actuators#actuator-with-profiles <https://

> github.com/ <https://github.com/>
> > <https://github.com/ <https://github.com/>>
> > > openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#actuator-

> > > > > > To view this discussion visit https://groups.google.com/
> d/ <https://groups.google.com/d/>

> > <https://groups.google.com/d/ <https://groups.google.com/d/>>
> > > <https://groups.google.com/d/ <https://groups.google.com/d/>
> <https://groups.google.com/d/ <https://groups.google.com/d/>>>
> > > > msgid/ <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>>

> <https://
> > > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>
> <http://groups.google.com/d/msgid/ <http://groups.google.com/d/

> msgid/>>>>
> > > > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/> <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>>

> <https://groups.google.com/ <https://groups.google.com/> <https://
> > groups.google.com/ <http://groups.google.com/>>
> > > d/msgid/> <https://groups.google.com/d/ <https://
> groups.google.com/d/> <https://

> > groups.google.com/d/ <http://groups.google.com/d/>> <https://

> groups.google.com/d/ <https://groups.google.com/d/> <https://

> > groups.google.com/d/ <http://groups.google.com/d/>>>

> > <https://groups.google.com/d/msgid/openpnp/4043b9fd- <https://
> groups.google.com/d/msgid/openpnp/4043b9fd->>
> > > df48-4955- <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > <https://groups.google.com/d/msgid/openpnp/4043b9fd- <https://
> groups.google.com/d/msgid/openpnp/4043b9fd->>
> > > df48-4955->

> > > > <https://groups.google.com/d/msgid/openpnp/4043b9fd-
> df48-4955- <https://groups.google.com/d/msgid/openpnp/4043b9fd-

> groups.google.com/d/msgid/openpnp/4043b9fd-> <https://
> > groups.google.com/d/msgid/openpnp/4043b9fd- <http://
> groups.google.com/d/msgid/openpnp/4043b9fd->>>
> > > > df48-4955- <https://groups.google.com/d/msgid/

> openpnp/4043b9fd- <https://groups.google.com/d/msgid/openpnp/4043b9fd->
> > <https://groups.google.com/d/msgid/openpnp/4043b9fd- <https://
> groups.google.com/d/msgid/openpnp/4043b9fd->>
> > > <https://groups.google.com/d/msgid/openpnp/4043b9fd- <https://

> groups.google.com/d/msgid/openpnp/4043b9fd-> <https://
> > groups.google.com/d/msgid/openpnp/4043b9fd- <http://

> groups.google.com/d/msgid/openpnp/4043b9fd->>>
> > > > df48-4955->
> > > > > bcd8->
> > > > > > eb1d7bea56dcn%40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> <http://40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>>

> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>
> > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>>?
> > > > > utm_medium=email&utm_source=footer

> <http://40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>
> > > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>
> > <http://40googlegroups.com <http://40googlegroups.com>

> <http://40googlegroups.com <http://40googlegroups.com>>>>?
> > > > > utm_medium=email&utm_source=footer>>.
> > > > >
> > > > > --
> > > > > You received this message because you are subscribed to the
> > Google
> > > > > Groups "OpenPnP" group.
> > > > > To unsubscribe from this group and stop receiving emails from
> > it,
> > > > send
> > > > > an email to openpnp+u...@googlegroups.com
> > > > > <mailto:openpnp+u...@googlegroups.com>.
> > > > > To view this discussion visit https://groups.google.com/d/
> <https://groups.google.com/d/>

> > > > > openpnp/34ec82a8-18ec-4fb4-
> > > a4c5-7b57cc0b7cc3n%40googlegroups.com
> <http://40googlegroups.com> <http://40googlegroups.com
> <http://40googlegroups.com>>
> > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>

> > > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>
> > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>>

> > > > > <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>

> > openpnp/34ec82a8-18ec-4fb4- <https://groups.google.com/d/msgid/

> <http://40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>>?
> > > > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>?
> > > > utm_medium=email&utm_source=footer>>.
> > > >
> > > > --
> > > > You received this message because you are subscribed to the
> Google
> > > > Groups "OpenPnP" group.
> > > > To unsubscribe from this group and stop receiving emails from
> it,
> > > send
> > > > an email to openpnp+u...@googlegroups.com
> > > > <mailto:openpnp+u...@googlegroups.com>.
> > > > To view this discussion visit https://groups.google.com/d/
> <https://groups.google.com/d/>
> > msgid/ <https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>>
> > > <https://groups.google.com/d/msgid/ <https://groups.google.com/
> d/msgid/> <https://groups.google.com/d/ <https://groups.google.com/d/>
> > msgid/>>

> > > > openpnp/064f7f36-1441-4348-
> > af9e-6049e2af74d3n%40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>

> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>
> > > > <https://groups.google.com/d/msgid/

> openpnp/064f7f36-1441-4348- <https://groups.google.com/d/msgid/
> openpnp/064f7f36-1441-4348->

> > <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348-
> <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348->>
> > > <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348-
> <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348->
> > <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348-
> <https://groups.google.com/d/msgid/openpnp/064f7f36-1441-4348->>>
> > > > af9e-6049e2af74d3n%40googlegroups.com

> <http://40googlegroups.com> <http://40googlegroups.com
> <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer>>.
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "OpenPnP" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > send
> > > an email to openpnp+u...@googlegroups.com
> > > <mailto:openpnp+u...@googlegroups.com>.
> > > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>

> > openpnp/ <https://groups.google.com/d/msgid/openpnp/ <https://
> groups.google.com/d/msgid/openpnp/>>
> > > ebdaedb9-e3a1-4716-944e-9ab8e6d7fb68n%40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>> <https://
> > > groups.google.com/d/msgid/openpnp/ebdaedb9- <http://
> groups.google.com/d/msgid/openpnp/ebdaedb9-> <http://

> > groups.google.com/d/msgid/openpnp/ebdaedb9- <http://
> groups.google.com/d/msgid/openpnp/ebdaedb9->>
> > > e3a1-4716-944e-9ab8e6d7fb68n%40googlegroups.com
> <http://40googlegroups.com>

> > <http://40googlegroups.com <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer>.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "OpenPnP" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to openpnp+u...@googlegroups.com
> > <mailto:openpnp+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > openpnp/223c98d7-4ea5-4824-8a40-15e8df3fd9d7n%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>
> > openpnp/223c98d7-4ea5-4824-8a40-15e8df3fd9d7n%40googlegroups.com

> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/openpnp/
> c49715c6-9de2-4b0c-8641-9ff3478bf0c8n%40googlegroups.com <https://
> groups.google.com/d/msgid/openpnp/
> c49715c6-9de2-4b0c-8641-9ff3478bf0c8n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

Mike Menci

unread,

Oct 20, 2025, 8:14:52 AMOct 20

to OpenPnP

Thanks for catching the 3 ms minimum — I’d run the 200 µs guess from older ELP hacks.
Updated the Mega sketch in situ:

cpp

Copy

digitalWrite(pin2, HIGH); delay(3); // 3 ms, datasheet compliant digitalWrite(pin2, LOW);

Total trigger → frame-in-PC is still < 35 ms, so no impact on overall cycle time.

How OpenPnP fires it

Camera Settings → Actuations
- ON : M240
- OFF : (none – pulse is self-contained)
GcodeDriver (COM9) has COMMAND_CONFIRM_REGEX left empty, so OpenPnP fire-and-forgets the byte immediately before the normal capture() call.
(No Camera.BeforeCapture script needed — the actuation event already emits M240.)
Mega on COM9 converts the single byte → 3 ms 5 V pulse → ELP “FSIN” pin.

Preview while hardware-triggered

Quick check:

Preview button in OpenPnP does not send M240 (actuations only fire during job / alignment moves).
Camera switches to free-running mode for preview unless the driver is explicitly set to Trigger = Hardware in the Device Settings.

We left Trigger = Software for preview, Trigger = Hardware only for bottom-vision pipeline → preview still works live, job shots are hardware-triggered.

If we ever need fully hardware-only operation we’ll add a “Preview” actuation that also sends M240 — for now the mixed mode keeps everyone happy.

Let me know if you’d like any scope captures or timing plots — happy to share.

Best,
Mike

bert shivaan

unread,

Oct 20, 2025, 8:29:01 AMOct 20

to ope...@googlegroups.com

My thinking about why there may be a delay and needed storage was exactly because everything is async now. So I could see a situation where the camera is fired from external hardware, but openPNP does not know to collect the picture yet.

I guess I struggle with how openPNP is knowing the exact time to grab the frame. If openPNP is triggering the shutter, then how does openPNP know exactly where the head is in the middle of a move?

I am not saying you guys have not sorted it all out, only that I am not picking it up. Feel free to tell me to just sit back and watch :)

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/1b69e146-888f-41a6-9722-2359c3fa4bb0n%40googlegroups.com.

Mike Menci

unread,

Oct 20, 2025, 8:51:33 AMOct 20

to OpenPnP

Hi Bert,

OpenPnP isn’t guessing the timing — it serialises the whole sequence:

Motion queue is drained (M400 or driver-level “wait-for-idle”).
Only then OpenPnP calls camera.capture() which immediately issues the M240 byte.
Driver sends M240 → Mega → 3 ms pulse while head is standing still.
Camera hardware-strobes the sensor, stores the frame in its internal FIFO, and USB transfer starts right after the pulse ends.
OpenCv grabs the frame (async USB read) and returns it to the vision pipeline.

Because steps 1-3 are blocking, the head position is exactly the one reported by the last M114 — no motion blur, no uncertainty.

The “async” part is only the USB upload (camera → PC), but that happens after the snapshot and doesn’t affect where the picture was taken.

So: head stops → trigger → frame grabbed at that frozen position — no need for extra storage or clever timing guesses.

Sit back and watch — it’s already picking !

bert shivaan

unread,

Oct 20, 2025, 9:03:28 AMOct 20

to ope...@googlegroups.com

I completely missed that the head stopped!

Everything makes more sense now. (I was under the impression this was flying vision)

To view this discussion visit https://groups.google.com/d/msgid/openpnp/325778d4-db9a-43fa-babe-8af520325fabn%40googlegroups.com.

Mike Menci

unread,

Oct 20, 2025, 9:22:28 AMOct 20

to OpenPnP

You’re absolutely right — we’re already stacking the bricks for flying vision:

ELP: even the cheap ones use OV5640; the global-shutter bit exists but needs a register write at power-on (or buy the “-global” variant).
Yaskawa: the A/B encoder outputs (5 V line-driver) will feed Mega interrupt pin 2 → count ticks → know exact mm.
Light: stays continuous, so we only need a 10 µs strobe pulse to freeze the frame (no LED timing).
Code: replace the 3 ms blind pulse with encoder-match → 10 µs pin high → capture while head is still moving.

Next step: scope the A/B lines while the head shuttles, tap one into Mega, and log counts-per-mm.
Once we hit the “centre” count, we strobe — first flying-image will be in the bag.

Keep the encoder pulses coming — we’re one interrupt away from no-stop bottom vision!

bert shivaan

unread,

Oct 20, 2025, 10:03:19 AMOct 20

to ope...@googlegroups.com

Looking forward to it :)

To view this discussion visit https://groups.google.com/d/msgid/openpnp/81242adc-02b5-4287-9625-6de536dc9b5dn%40googlegroups.com.

Chris Campbell

unread,

Oct 21, 2025, 2:48:53 AMOct 21

to ope...@googlegroups.com

In my opinion true fly-by vision is not really possible with the
current OpenPNP paradigm of synchronously communicating with a motion
controller, and waiting for each set of commands to complete. At least
not without the motion controller firmware being properly aware of the
job it's supposed to be doing.

For example, instead of responding to OpenPNP after all the commanded
moves have finished, the motion controller needs to report that it's
finished moving... while it's actually still moving... but not before
the frame capture has finished. This is so that OpenPNP can then look
at the latest webcam frame and decide where the still in-progress move
should end up. But - the destination of the move was already issued
before even taking the photo right? So there needs to be some
correction of the destination position. So the nozzle will have to
come to a stop at the original (uncorrected) destination, and receive
the new position from OpenPNP after that (or detect that the part was
mis-picked and abort etc). This requires OpenPNP to have some concept
of a correcting a previously issued placement location before the
final touchdown. For a single nozzle it's doubtful that this would
really speed anything up much - especially since the head probably has
to stop at some consistent position before initiating the fly-over
anyway, so that the speed and direction will be consistent as it
passes over the camera.

For multiple nozzles flying over a single camera there is more speedup
to be gained, but you have even more headaches in the implementation,
because looking at just the latest image frame after the capture
sequence is not sufficient. The UVC connection over USB is probably
not real-time enough to fetch frames during the fly-over, even if that
were part of the OpenPNP feature set. So multiple frame data needs to
be stored somewhere external to OpenPNP, and the camera module alone
is not gonna do that. A dedicated microcontroller with ample RAM can
store frames during the fly-over for retrieval at a more relaxed pace,
but that would then require some kind of UART/I2C/SPI or custom USB
connection from the microcontroller to get the frames into OpenPNP
(and hence even more work into OpenPNP to handle that). Also keep in
mind you would need a machine that can move each nozzle in Z
independently, so they're all at the right height for focus. Many
machines I see have that see-saw actuator which will not work.

As for generating a hardware trigger, the idea of using an arduino to
count encoder pulses seems valid. It would have to be interrupt driven
though, none of this Serial.read() or scripts would be any good. And
the motion controller firmware still needs to know when the capture is
done. Overall the points I'm trying to make are that A) the triggering
the capture is only a small and relatively trivial part of the
picture. You may be 'stacking bricks' by buying various hardware
components, but you still need a lot of mortar (software mods) to go
between them. B) not much to gain for a single nozzle, and multiple
nozzle implementation becomes much harder.

I actually spent a lot of time looking into this (the microcontroller
idea specifically) and decided that for my backyard hobbyist purposes
it's just too complicated to pursue, for now. The cool-factor is very
high, but productivity-wise there are way better ways to spend my
time. Plus my machine is only single nozzle. Maybe one day I will come
back and try it again.

> To view this discussion visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNwKQzZ5Wp76CGz%3DiVXtoPSYWybgz8NcBGdimjA0zmu3MA%40mail.gmail.com.

Mike Menci

unread,

Oct 21, 2025, 4:38:01 AMOct 21

to OpenPnP

My experience lines up perfectly with Chris’s technical summary, but I’d like to add one practical hurdle that kept me busy (and happily so) during the past weeks: the complete lack of documentation from ELP

My original goal was simply to test whether a $55 ELP module could give reliable hardware-triggered frames for bottom vision. That question alone turned into an entertaining retirement project: probing undocumented test-points, reverse-engineering a little 555-based one-shot board, and eventually building a working 5 ms, 1.8 V pulse generator driven from the motion controller.

In the end the camera’s trigger circuit died (0 V on "Trigger-OFF" pad, no snap in YawCam), while the sensor still streams fine. Without a schematic, timing diagram, or even a polarity spec, any "fly-by" design is guess-work that may break with the next production batch.

So, like Chris, I’ve decided to park the hardware-trigger idea for now and I stay with "stop-stream-process-continue" with my 4 nozzle Pnp. It’s "slower", but deterministic—and it leaves more of my free retirement time for building other unfinished projects...., instead of chasing ghosts in a mystery 555 circuit!

Cheers,

image1.jpeg

ELP_test control board.png

simpl...@tuta.io

unread,

Oct 21, 2025, 5:27:09 AMOct 21

to Openpnp, OpenPnP

>> the complete lack of documentation from ELP

Yes, many products are simply unusable because translations are missing or only limited information is available.

>> I’ve decided to park the hardware-trigger idea

Good decision. Because the crux of the matter is the transfer of images in the background - this is usually done using an SDK supplied by the manufacturer.

Mike, perhaps you could try a few tests with a slightly faster USB3 camera that is UVC-compatible, so that no adaptations to openpnp-capture are necessary.

Jan

unread,

Oct 22, 2025, 4:53:39 AMOct 22

to ope...@googlegroups.com

Hi Chris!
Many thanks for your great contribution to this topic! You have nicely
highlighted the relevant points!
I also wont to thank Mike for his contributions in bringing the topic
further with true physical experience.
I think - and this has been discussed in other threads too - that
bottom vision is the part of OpenPnP that we would benefit the most
today if optimized.
This could/should first be done by making vision operation
asynchronous. Then we would stop over the camera, take the image and
continue moving while vision processing is still in progress. As you
explained, the target location when heading from camera to place
location can not be the place location itself, because the bottom vision
induced corrections have not been applied yet. And in case the bottom
vision operation fails, the nozzle might require to go back to the
camera for a second shot. So I'd propose to choose a point in the
direction of the place location that takes long enough for bottom vision
processing to finish and still allows the motion controller to move at
full speed before the (corrected) place location is send as true target.
The motion controller would combine the two forming a continuous motion.
This would be available to all users with all type of cameras.
Using a hardware triggered camera provides the opportunity to a)
control the jitter between image request and image available b) reduce
the processing power to transfer images from camera to computer and c)
provide an upgrade path towards fly-by-vision. A few days back, I
started a PR to implement hardware trigger support. Hopefully Mike will
still be able to test it, once it has settled. It basically triggers the
camera using a user-selectable actuator when requested to capture an
image. This shall work for preview as well triggering the camera at the
requested rate.
For fly-by-vision as the ultimate goal, we still need to find out if it
can be done using a simple UVC camera. UVC cameras have the advantage,
that they can be used by everyone as they are supported as generic
cameras. Without the availability of UVC cameras with hardware trigger
option, I don't see how OpenPnP could (in a generic fashion) ever
provide fly-by-vision. AFAIK the ELP camera Mike is using, is the only
one that supports hardware trigger and UVC.
As you mentioned, fly-by-vision requires to trigger the camera at a
specific point while moving on a specific path. I think, that the motion
controller is perfect for generating this trigger. The designs, I've
seen, are using interrupts to generate step/dir pulses to drive motors.
This step/dir generators could easily be enhanced to fire the trigger
pulse at a certain time/location. (We once discussed, that Duet supports
that already.) So we need to command the head to cross the camera on a
certain path and let the motion controller generate a trigger with the
correct lead time to capture the frame when the nozzle is just in the
center of the camera.
If we extend the above for multiple nozzles, it is obvious, that it can
only be done for nozzles that are (almost) lined up. Then the trigger
rate is a function of motion speed and distance between nozzles. This
procedure shall work as long as the trigger rate is supported by the
camera. On my machine the distance between nozzles is ~23.5mm and max.
speed is 1.5m/s. This corresponds to a delay of 15.67ms between the
triggers for the two nozzles or a frame rate of 63.8Hz. The AR0234, the
ELP camera Mike is using, is equipped with, support at least 90fps,
which shall be enough in my use case. (And there would still be the
option to reduce the speed.)

Jan

Jan

unread,

Oct 22, 2025, 5:16:56 AMOct 22

to ope...@googlegroups.com

Hi Mike!

On 21.10.2025 10:38, Mike Menci wrote:
> My experience lines up perfectly with Chris’s technical summary, but I’d
> like to add one practical hurdle that kept me busy (and happily so)
> during the past weeks: the complete lack of documentation from ELP

Didn't you posted the manual ELP provides that contains detailed timing
and configuration options to enable the hardware trigger facility? Do
you miss anything or this anything incorrect?
I verified their documentation with the trigger board they supplied and
did not found any issue.

[...]> In the end the camera’s trigger circuit died (0 V on

"Trigger-OFF" pad,
> no snap in YawCam), while the sensor still streams fine. Without a
> schematic, timing diagram, or even a polarity spec, any "fly-by" design
> is guess-work that may break with the next production batch.

Lucky you! The trigger input seems to be directly connected to the
sensor only protected by a resistor and diode.
Did you find out what when wrong killing the circuit?

Jan

vespaman

unread,

Oct 22, 2025, 8:38:28 AMOct 22

to OpenPnP

Hi Jan,

For fly-by-vision as the ultimate goal, we still need to find out if it
can be done using a simple UVC camera. UVC cameras have the advantage,
that they can be used by everyone as they are supported as generic
cameras. Without the availability of UVC cameras with hardware trigger
option, I don't see how OpenPnP could (in a generic fashion) ever
provide fly-by-vision.

An alternative way, if you choose to continue this (exiting) path, could be to use a RPi, with a hardware triggered (MIPI connected) sensor.
In a way that might be a more "stable" platform than the ever evolving Chinese UVC cameras with unknown FW and undocumented "features".

I spent some time getting my imx290 sensors going at 120FPS, and devs at Raspberry Pi was very helpful, even creating patches for a special kernel for me.

Just my two cents..

- Micael

Mike Menci

unread,

Oct 22, 2025, 9:01:28 AMOct 22

to OpenPnP

Hi Jan,

The PDF I posted does give timing and voltage levels, but it describes the AR0234-based camera with the white ZH-1.5-5P connector (1.8 V on pin 3, 3 ms min pulse + GND wire, ....etc.).
The unit I actually received is the older OV7251/9281 board that has only a tiny second PCB with three test pads and a 555 timer on bottom PCB for which I was instructed by ELP to remove it in order to have access to header with triggering 5pin...
ELP never released a schematic for that board, so when the 555 or its output FET died I had no part values to replace – the app-note is useless for repair.
Protection: yes, the main board trigger pin is only a resistor + diode to 1.8 V, so it’s fairly rugged.
I fed it 1.8 V from a bench PSU with a 1 kΩ series resistor – well inside the spec – yet the bottom PCB still went to 0 V on its “Trigger-OFF” pad while the sensor kept streaming.
My guess is a marginal 555 or SOT-23 transistor that finally shorted; nothing I did electrically killed it.
Outcome: I now ignore the dead bottom board and pulse the main 5-pin header directly (Backlight = 2).
Works now again .. just tested it... , but the episode shows that without a schematic any “fly-by” project is one silent failure away from a paper-weight. How did you trigger your ELP for your test ?

Cheers,
Mike

Mike Menci

unread,

Oct 22, 2025, 9:08:50 AMOct 22

to OpenPnP

My set-up for trigger is :

I removed the tiny bottom switch PCB board and plugged in new 5-pin header straight on to my own 1.8 V logic.
A 3.3 V Arduino pin → voltage divider (10 k / 15 k) → 1.8 V, 5 ms pulse into pin-3 (SYNC/Trigger).
Common ground on pin-2.
Backlight compensation = 2 (saved in EEPROM).

That’s it – one rising edge, one frame should fly out - But I am not sure where the images from ELP will land or should land ? This are not screenshot images any more!?

Jan

unread,

Oct 23, 2025, 4:23:36 AMOct 23

to ope...@googlegroups.com

Hi Micael!
Be assured that - if fly-by-vision comes - it will not be limited to a
particular camera. As I wrote earlier, this ELP UVC global shutter
camera with hardware trigger it the first (to my knowledge) that can be
used with OpenPnP without any modifications. So it provides the perfect
base to start working into that direction. Finally there might be minor
adjustments needed to the particular camera driver in OpenPnP to support
more cameras (As I'm preparing the PR to support hardware triggering the
option to choose a trigger actuator is common to all cameras but the
method hasNewFrame() needs modification as new frames are only available
if the camera has been triggered).

Jan

> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/99155439-7d08-4a68-ad18-e7c8c25fb94dn%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/99155439-7d08-4a68-ad18-
> e7c8c25fb94dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

Jan

unread,

Oct 23, 2025, 4:38:11 AMOct 23

to ope...@googlegroups.com

Hi Mike!
Good to hear that you're still on board! It's a pity that your camera
does not correspond to the documentation we have. For the secondary
board, I was told that it's for testing only and they would not release
the schematics. Anyhow, I very early decided to not use it. I will use
an addition IO of my controller board to trigger the camera via an opto
coupler (and the required level shifter). In addition I'll probably feed
the strobe output back and or it to the camera light. This would allow
to flash the light and monitor the triggering (and switch the light on
continuously).
If you say your camera is equipped with a different sensor, I'm not
sure about the timings anymore. I'd ask ELP again. Maybe you can
convince them to send you a new camera with the correct chip and with
documentation. You could also try to find the datasheet for the sensor
itself. The documentation we have suggests, that ELP has routed the
trigger input directly to the sensor.

Jan

On 22.10.2025 15:08, Mike Menci wrote:
> My set-up for trigger is :
>

> *

> I removed the tiny bottom switch PCB board and plugged in new 5-pin
> header straight on to my own 1.8 V logic.

> *

> A 3.3 V Arduino pin → voltage divider (10 k / 15 k) → 1.8 V, 5 ms
> pulse into pin-3 (SYNC/Trigger).

> *
> Common ground on pin-2.
> *

> Backlight compensation = 2 (saved in EEPROM).
>
> That’s it – one rising edge, one frame should fly out - But I am not
> sure where the images from ELP will land or should land ? This are not
> screenshot images any more!?
>
> On Wednesday, 22 October 2025 at 15:01:28 UTC+2 Mike Menci wrote:
>
> Hi Jan,
>

> 1.

> The PDF I posted does give timing and voltage levels, but it
> describes the AR0234-based camera with the white ZH-1.5-5P
> connector (1.8 V on pin 3, 3 ms min pulse + GND wire, ....etc.).
> The unit I actually received is the older OV7251/9281 board that
> has only a tiny second PCB with three test pads and a 555 timer
> on bottom PCB for which I was instructed by ELP to remove it in
> order to have access to header with triggering 5pin...
> ELP never released a schematic for that board, so when the 555
> or its output FET died I had no part values to replace – the
> app-note is useless for repair.

> 2.

> Protection: yes, the main board trigger pin is only a resistor +
> diode to 1.8 V, so it’s fairly rugged.
> I fed it 1.8 V from a bench PSU with a 1 kΩ series resistor –
> well inside the spec – yet the bottom PCB still went to 0 V on
> its “Trigger-OFF” pad while the sensor kept streaming.
> My guess is a marginal 555 or SOT-23 transistor that finally
> shorted; nothing I did electrically killed it.

> 3.

> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/2829836c-7fb1-49c6-be65-339d2617926cn%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/2829836c-7fb1-49c6-
> be65-339d2617926cn%40googlegroups.com?utm_medium=email&utm_source=footer>.

Mike Menci

unread,

Oct 23, 2025, 9:24:53 AMOct 23

to OpenPnP

Hey Jan,
I just finished bagging the opto-isolators for my own trigger board and realised I’ve got spares on the bench.
If you (or anyone else following the thread) need one to finish the “controller → camera” galvanic-isolated trigger you described, ping me off-list – happy to drop one in an envelope.

Part I’m using: PC817 (Vce 35 V, CTR ≥ 50 %, 4-pin DIP) – dead-simple, two resistors and you’re done.
First-come-first-served until the little box is empty. - see enclosed. **On my ELP Camera Chip there is only V8 written - no AR0234 ..... this is why I am sceptic ...

Cheers,

PC817SC PCB.png

IMG_7975.png

W2025091501111355.png

Mike Menci

unread,

Oct 23, 2025, 12:53:17 PMOct 23

to OpenPnP

Hi Jan, Chris, and everyone following the trigger-vision thread,

Yesterday and today I finally closed the last open question about the camera that has been sitting on my pick-and-place head for weeks:

“Does the chip marked only ‘V8’ really contain the Aptina AR0234 global-shutter sensor, or did ELP ship something else?”

Short answer: YES, it is an AR0234 – the “V8” is simply a house-keeping laser-etch that ELP/SVPRO applies to every unit they import.
Below are the facts, the measurements and the public proof so that nobody else has to guess.

Visual evidence

Amazon India listing (sold and shipped by SVPRO themselves)
https://www.amazon.in/SVPRO-Global-Shutter-USB-Camera/dp/B0CC28R5TL
Customer-uploaded close-up of the sensor die shows the identical “V8” marking and the same 38 mm board layout that I have on my desk.
The vendor text still advertises:
“1/2.6 inch Aptina AR0234 high quality sensor, 1920 × 1200 @ 90 fps MJPEG”.

USB descriptor

My unit enumerates as
VID_32E4 PID_2234 “Global Shutter Camera”
This VID/PID pair is registered to “Ailipu Technology”, a Chinese OEM that supplies ELP when their own inventory runs low.
So the electronics are genuine – just a different firmware flavour burned at the factory.

Format probe

OpenPnP → Camera → Capture lists all native formats:

1920 × 1200, 90 fps, MJPEG
1600 × 1200, 90 fps, MJPEG
1280 × 960, 90 fps, MJPEG ← using this now
1280 × 720, 120 fps, MJPEG
… (nine more stepped resolutions)

No resolution is missing – the silicon really does deliver 2.3 Mpix @ 90 fps.

Real-world frame-rate check

1920 × 1200 MJPEG → 41 fps (USB-2 bandwidth limit, shared bus, Windows host)
1280 × 960 MJPEG → 50 fps (plenty of head-room for dual-nozzle fly-by)

Both numbers were taken with Auto-exposure OFF (exposure = -6) so the latency is now deterministic.

Next step

I will scope the TRIG-IN → STROBE-OUT delay to verify the ≈ 80 µs number from the AR0234 data-sheet.
If that measurement lands inside ±10 µs we can finally close the loop and let the motion-controller fire the camera on-the-fly without stopping the head.

Take-away for the group

A laser-etched “V8” on the sensor is NOT a fake – it is just house-keeping graffiti.
Any “SVPRO / ELP / Ailipu” module that offers 1920×1200 @ 90 fps MJPEG over vanilla UVC is 99 % an AR0234 underneath.
Treat the USB VID/PID as a firmware signature, not a silicon guarantee.
Always force the highest format in OpenPnP – the Windows enumeration tools (AmCap, VLC, etc.) often hide the 1920×1200 line even though the hardware supports it.

I will post the oscilloscope captures once I figure out how to drive my USB scope, camera and OpenPnP on one screen :-)

Hope this saves the next builder a week of head-scratching. Cheers Mike

Jan

unread,

Oct 24, 2025, 5:28:24 AMOct 24

to ope...@googlegroups.com

Hi Mike!
Just for clarification: the camera I've received contains *two* larger
chips. The one on the top side is the sensor (I don't see it's marking,
it's covered by the lens holder) and a second on the bottom side (88 pin
QFN, marked "V8") the controller that provides the usb connection to the
sensor. The sensors datasheet is on request only
(https://www.onsemi.com/products/sensors/image-sensors/ar0234cs) and the
overview does not contain much useful information - IMHO.
At 1600x1200 MJPG (later cropped to a square) I get a stable 90fps for
all values of expose and with "Backlight Compensation" set to 0
(automatic trigger). I also verified, that the software trigger mode
(Backlight Compensation at 1) works as expected. The delivered frame
rate can be controlled using Hue. The software triggered single frame
mode (Backlight Compensation at 3, trigger via Hue set to 100). This
could be an option without hardware trigger signal...
However, I also noticed some problems (Camera and OpenPnP related):
- At software trigger mode (Backlight compensation = 0) the trigger rate
shall be limited by exposure. For longer exposure times (-5 (corresponds
to 10ms) and above) the frame rate shall drop. This is not reflected by
the frame rate test feature OpenPnP provides. This function seems to
operate the camera using different settings, which is also reflected by
the fact, that the last image of the test has a different brightness.
- The strobe output (led on the test board) seems to be distorted by the
OpenPnP test function. If executed, the camera stops strobing.

Jan

On 23.10.2025 18:53, Mike Menci wrote:
> Hi Jan, Chris, and everyone following the trigger-vision thread,
> Yesterday and today I finally closed the last open question about the
> camera that has been sitting on my pick-and-place head for weeks:
> “Does the chip marked only ‘V8’ really contain the Aptina AR0234 global-
> shutter sensor, or did ELP ship something else?”
> Short answer: YES, it is an AR0234 – the “V8” is simply a house-keeping
> laser-etch that ELP/SVPRO applies to every unit they import.
> Below are the facts, the measurements and the public proof so that
> nobody else has to guess.

> ------------------------------------------------------------------------
>
> 1.
> Visual evidence
>
> ------------------------------------------------------------------------

> Amazon India listing (sold and shipped by SVPRO themselves)
> https://www.amazon.in/SVPRO-Global-Shutter-USB-Camera/dp/B0CC28R5TL
> <https://www.amazon.in/SVPRO-Global-Shutter-USB-Camera/dp/B0CC28R5TL>
> Customer-uploaded close-up of the sensor die shows the identical “V8”
> marking and the same 38 mm board layout that I have on my desk.
> The vendor text still advertises:
> “1/2.6 inch Aptina AR0234 high quality sensor, 1920 × 1200 @ 90 fps MJPEG”.

> ------------------------------------------------------------------------
>
> 2.
> USB descriptor
>
> ------------------------------------------------------------------------

> My unit enumerates as
> VID_32E4 PID_2234 “Global Shutter Camera”
> This VID/PID pair is registered to “Ailipu Technology”, a Chinese OEM
> that supplies ELP when their own inventory runs low.
> So the electronics are genuine – just a different firmware flavour
> burned at the factory.

> ------------------------------------------------------------------------
>
> 3.
> Format probe
>
> ------------------------------------------------------------------------

> OpenPnP → Camera → Capture lists all native formats:
>

> *

> 1920 × 1200, 90 fps, MJPEG

> *

> 1600 × 1200, 90 fps, MJPEG

> *

> 1280 × 960, 90 fps, MJPEG ← using this now

> *

> 1280 × 720, 120 fps, MJPEG

> *

> … (nine more stepped resolutions)
>
> No resolution is missing – the silicon really does deliver 2.3 Mpix @ 90
> fps.

> ------------------------------------------------------------------------
>
> 4.
> Real-world frame-rate check
>
> ------------------------------------------------------------------------
>
> *

> 1920 × 1200 MJPEG → 41 fps (USB-2 bandwidth limit, shared bus,
> Windows host)

> *

> 1280 × 960 MJPEG → 50 fps (plenty of head-room for dual-nozzle fly-by)
>
> Both numbers were taken with Auto-exposure OFF (exposure = -6) so the
> latency is now deterministic.

> ------------------------------------------------------------------------
>
> 5.
> Next step
>
> ------------------------------------------------------------------------

> I will scope the TRIG-IN → STROBE-OUT delay to verify the ≈ 80 µs number
> from the AR0234 data-sheet.
> If that measurement lands inside ±10 µs we can finally close the loop
> and let the motion-controller fire the camera on-the-fly without
> stopping the head.

> ------------------------------------------------------------------------
> Take-away for the group
>
> *

> A laser-etched “V8” on the sensor is NOT a fake – it is just house-
> keeping graffiti.

> *

> Any “SVPRO / ELP / Ailipu” module that offers 1920×1200 @ 90 fps
> MJPEG over vanilla UVC is 99 % an AR0234 underneath.

> *

> Treat the USB VID/PID as a firmware signature, not a silicon guarantee.

> *

> msgid/ <https://groups.google.com/d/msgid/>
> > openpnp/2829836c-7fb1-49c6-
> be65-339d2617926cn%40googlegroups.com <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/
> openpnp/2829836c-7fb1-49c6- <https://groups.google.com/d/msgid/
> openpnp/2829836c-7fb1-49c6->
> > be65-339d2617926cn%40googlegroups.com?

> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>

> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/195be0d9-df48-4592-b2dd-9101be527871n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/195be0d9-df48-4592-
> b2dd-9101be527871n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Mike Menci

unread,

Oct 24, 2025, 9:35:38 AMOct 24

to OpenPnP

Hi Jan,

Thanks for the extra detail – it clears up the “two-chip” picture and confirms why we both see “V8” even though the silicon is an AR0234.
Below is a concise “what we now know” plus work-arounds for the OpenPnP oddities you spotted.

Hardware reality check

Top side (covered by lens holder) → AR0234CS sensor die (bare silicon, no external marking visible).
Bottom side 88-pin QFN → USB bridge / ISP chip (likely FP6800 or CY7C68013A clone) – this is the chip that carries the “V8” laser mark.
Its job: MIPI→USB and UVC descriptor handling.
So “V8” ≠ sensor, but board-level part number – explains why every ELP/SVPRO/AILIPU module shows the same mark.

Frame-rate vs. exposure (software-trigger path)

Observation you made:
“Longer exposure (-5 ≙ 10 ms) should drop the delivered fps, but OpenPnP’s ‘Test FPS’ button keeps showing 90 fps.”

Root cause:
OpenPnP’s “Test FPS” does not use the same UVC streaming parameters you set in the Camera Configuration panel.
It opens a second, private stream with auto-exposure ON and default brightness/gain, therefore:

exposure is shorter than your manual value → fps stays high,
last frame looks brighter/darker than the live view.

Work-around:
Ignore the “Test FPS” number for software-trigger tuning.
Instead:

Set Backlight Compensation = 1 (software trigger mode).
Manually snap 50 frames with a tiny Python/UVC script (or just rapid-fire in OpenPnP “Capture”) and time-stamp the file system – real fps = 49 frames / (last-time – first-time).
Repeat for each exposure step; you’ll see the expected 1 / exposure ceiling.

Strobe line disturbed by OpenPnP test

Quote:
“The strobe output (LED on the test board) stops working after I press Test FPS.”

Explanation:
When OpenPnP closes the private stream it resets the UVC commit, which toggles the Backlight Compensation control back to 0 (continuous mode).
The on-board MCU that generates the STROBE pulse is wired to Backlight-Comp → 1, so the falling edge kills the LED flash.

Cure:
Always re-select “1” in Backlight Compensation after you hit Test FPS, then Apply.
Better: never use Test FPS once you moved to software-trigger development – use normal Capture instead.

Quick comparison – hardware vs. software trigger

| Mode | Backlight-Comp | Pro | Con |
| -------------------------------- | -------------- | ------------------------------------------------------- | ------------------------------------------------------------------ |
| **Hardware** (opt-isolated GPIO) | 0 | **Deterministic ≤ 100 µs**, **works even if PC stalls** | Needs **extra wire + level-shifter** |
| **Software** (Hue=100 pulse) | 3 | **No extra hardware**, **rate set by Hue slider** | **Jitter 1-2 ms**, **fps drops with exposure**, **UVC reset risk** |
For fly-by-vision the hardware route is still the only way to guarantee the trigger lands within ±150 µs of the motion-controller interrupt.

Bottom line for the group

“V8” is not the sensor – it’s the USB bridge chip; sensor is AR0234 under the lens mount.
OpenPnP “Test FPS” lies when you use manual exposure – measure fps externally.
Strobe disappears because Test FPS resets Backlight-Comp – re-apply “1” or avoid the button.

Once I finish my scope homework (learning how to press the RUN button…) I’ll post the TRIG-IN → STROBE-OUT numbers.

*****Can you please send a picture of your ELP camera - this would help me and other readers to compare them....

Cheers, Mike

Mike Menci

unread,

Oct 25, 2025, 1:58:38 PMOct 25

to OpenPnP

Hi Jan,

Here attached is my oscilloscope capture of the ELP global-shutter timing:

SINC (CH1, yellow) rises first; STROBE (CH2, blue) follows 8 µs later and stays high for 24 µs.
Both signals are 3.3 V CMOS, 1 kΩ series-protected on the test jig.
Camera streaming at 1000 fps (1 kHz frame rate).

This shows the sensor’s black-level clamp and LED flash window are stable and repeatable, so OpenPnP can safely use STROBE rising edge + 24 µs exposure as the flash-sync reference. Cheers

10usOpenHantek6022 (3.3.3) - Device DSO-6022BL (FW0210).png

Jan

unread,

Oct 25, 2025, 4:59:20 PMOct 25

to ope...@googlegroups.com

Hi Mike!

On 24.10.2025 15:35, Mike Menci wrote:
[...]> *****Can you please send a picture of your ELP camera - this

would help
> me and other readers to compare them....

Please find them attached.

Jan

top.jpg

bottom.jpg

Mike Menci

unread,

Oct 26, 2025, 4:28:44 AMOct 26

to OpenPnP

used for ?? anyone knows ?
ELP tact near V8.png

Mike Menci

unread,

Oct 28, 2025, 4:18:24 AMOct 28

to OpenPnP

ELP P002 module (AR0234CS sensor, top-mark “V8” lot)
HW-753 100 kHz / 200 kHz trigger board – 3.3 V operation
Three independent enclosures + CSV data set

WHAT WAS TESTED

• Camera: ELP P002 (AR0234CS, PCB silk-screen “P002”, top-mark “V8”)
• Trigger source: HW-753 programmable PWM board, 3.3 V rail, 1 kΩ series resistor
• Wiring: 5-pin header – GND, TRIG-IN, STROBE (plus two unused pins)
• Power: HW-753 @ 3.3 V, camera via its own USB cable (5 V) – common ground
• Oscilloscope: 2-channel, 2 MSa/s, 500 µs/div, 50 µs/div zoom, 10-bit ADC, CSV export
• Sample size: three complete enclosures (≈ 3 × 600 kS, 2 s continuous)

TEST CONDITIONS

TRIG-IN: 100 kHz, 50 % duty, CMOS 3.3 V → 1 kΩ → camera pin
STROBE: camera-generated output, expected 200 kHz, 50 % duty
Both signals probed directly on the 5-pin header (GND referenced)

RESULTS (all three enclosures)

Parameter | Min | Typ | Max | Unit | Note

TRIG-IN amplitude | 307 | 315 | 323 | mVpp | post-1 kΩ, RC-shaped STROBE amplitude | 388 | 412 | 436 | mVpp | idem TRIG frequency | 99.98 | 100.00 | 100.02 | kHz | HW-753 crystal STROBE frequency | 199.96 | 200.00 | 200.04 | kHz | exact ×2 TRIG→STROBE delay | 23.6 | 23.8 | 24.0 | µs | cursor, rising edge to rising edge Duty-cycle error | –1 | 0 | +1 | % | vs ideal 50 %

CSV DATA SET

File: TestELP_1V_ELP2.csv (attached)
Columns: time (s), CH1 (V), CH2 (V)
Resolution: 500 ns/pt, ±0.2 mV, 2 s window
Use it for your own edge-detection / jitter scripts – no post-processing applied.

INTERPRETATION FOR OpenPnP

• The 23.8 µs delay is repeatable (σ < 200 ns across enclosures).
• Amplitude is low because the 1 kΩ resistor + input capacitance forms a low-pass corner ≈ 300 kHz; the logic levels inside the camera are still full-swing 3.3 V.
• No missed triggers, no double pulses, no phase drift observed in 2 s continuous runs.
• Camera satisfies the “trigger in → strobe out” timing requirement for standard OpenPnP pipelines (exposure starts 24 µs after rising edge).

TAKE-AWAY

If you drive the ELP P002 (AR0234CS “V8” lot) with a 100 kHz trigger through a 1 kΩ resistor at 3.3 V, you can count on a 200 kHz strobe exactly 23.8 µs later.
The attached CSV lets you simulate / verify the timing in your own motion-planner scripts.

Files enclosed
├── 20251027_174321_ELP_2.png
├── 20251027_174356_ELP_2.png
├── 20251027_174313_2.png
└── TestELP_1V_ELP2.csv

20251027_174313_2.png

TestELP_1V_ELP2.csv

20251027_174356_ELP_2.png

20251027_174321_ELP_2.png

Jan

unread,

Oct 28, 2025, 4:47:47 AMOct 28

to ope...@googlegroups.com

Hi Mike!
23,8us, thats well shorter then the 1.456ms the manual claims for
rising edge on trigger to rising edge on flash. Do you have any idea
why? (23.8us is way better then 1.456ms, as the distance the machine
would have to move between triggering and bottom vision, is why shorted.)

Jan

On 28.10.2025 09:18, Mike Menci wrote:
> ELP P002 module (AR0234CS sensor, top-mark “V8” lot)
> HW-753 100 kHz / 200 kHz trigger board – 3.3 V operation
> Three independent enclosures + CSV data set

> ------------------------------------------------------------------------
>
> 1.
> WHAT WAS TESTED
>
> ------------------------------------------------------------------------

> • Camera: ELP P002 (AR0234CS, PCB silk-screen “P002”, top-mark “V8”)
> • Trigger source: HW-753 programmable PWM board, 3.3 V rail, 1 kΩ series
> resistor
> • Wiring: 5-pin header – GND, TRIG-IN, STROBE (plus two unused pins)
> • Power: HW-753 @ 3.3 V, camera via its own USB cable (5 V) – common ground
> • Oscilloscope: 2-channel, 2 MSa/s, 500 µs/div, 50 µs/div zoom, 10-bit
> ADC, CSV export
> • Sample size: three complete enclosures (≈ 3 × 600 kS, 2 s continuous)

> ------------------------------------------------------------------------
>
> 2.
> TEST CONDITIONS
>
> ------------------------------------------------------------------------

> TRIG-IN: 100 kHz, 50 % duty, CMOS 3.3 V → 1 kΩ → camera pin
> STROBE: camera-generated output, expected 200 kHz, 50 % duty
> Both signals probed directly on the 5-pin header (GND referenced)

> ------------------------------------------------------------------------
>
> 3.
> RESULTS (all three enclosures)
>
> ------------------------------------------------------------------------

> Parameter | Min | Typ | Max | Unit | Note
> TRIG-IN amplitude | 307 | 315 | 323 | mVpp | post-1 kΩ, RC-shaped STROBE
> amplitude | 388 | 412 | 436 | mVpp | idem TRIG frequency | 99.98 |
> 100.00 | 100.02 | kHz | HW-753 crystal STROBE frequency | 199.96 |
> 200.00 | 200.04 | kHz | exact ×2 TRIG→STROBE delay | 23.6 | 23.8 | 24.0
> | µs | cursor, rising edge to rising edge Duty-cycle error | –1 | 0 | +1
> | % | vs ideal 50 %

> ------------------------------------------------------------------------
>
> 4.
> CSV DATA SET
>
> ------------------------------------------------------------------------

> File: TestELP_1V_ELP2.csv (attached)
> Columns: time (s), CH1 (V), CH2 (V)
> Resolution: 500 ns/pt, ±0.2 mV, 2 s window
> Use it for your own edge-detection / jitter scripts – no post-processing
> applied.

> ------------------------------------------------------------------------
>
> 5.
> INTERPRETATION FOR OpenPnP
>
> ------------------------------------------------------------------------

> • The 23.8 µs delay is repeatable (σ < 200 ns across enclosures).
> • Amplitude is low because the 1 kΩ resistor + input capacitance forms a
> low-pass corner ≈ 300 kHz; the logic levels inside the camera are still
> full-swing 3.3 V.
> • No missed triggers, no double pulses, no phase drift observed in 2 s
> continuous runs.
> • Camera satisfies the “trigger in → strobe out” timing requirement for
> standard OpenPnP pipelines (exposure starts 24 µs after rising edge).

> ------------------------------------------------------------------------
>
> 6.
> TAKE-AWAY
>
> ------------------------------------------------------------------------

> If you drive the ELP P002 (AR0234CS “V8” lot) with a 100 kHz trigger
> through a 1 kΩ resistor at 3.3 V, you can count on a 200 kHz strobe
> exactly 23.8 µs later.
> The attached CSV lets you simulate / verify the timing in your own
> motion-planner scripts.
> Files enclosed
> ├── 20251027_174321_ELP_2.png
> ├── 20251027_174356_ELP_2.png
> ├── 20251027_174313_2.png
> └── TestELP_1V_ELP2.csv
>
> On Sunday, 26 October 2025 at 09:28:44 UTC+1 Mike Menci wrote:
>
> used for ?? anyone knows ?

> ELP tact near V8.png
>
> On Saturday, 25 October 2025 at 22:59:20 UTC+2 Jan wrote:
>
> Hi Mike!
>
> On 24.10.2025 15:35, Mike Menci wrote:
> [...]> *****Can you please send a picture of your ELP camera - this
> would help
> > me and other readers to compare them....
>
> Please find them attached.
>
> Jan
>

> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/openpnp/
> ee6d3a37-a539-4a21-9101-52d79659a0c7n%40googlegroups.com <https://
> groups.google.com/d/msgid/openpnp/ee6d3a37-
> a539-4a21-9101-52d79659a0c7n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

Mike Menci

unread,

Oct 28, 2025, 5:19:42 AMOct 28

to ope...@googlegroups.com

Hi Jan,
No I don’t know -
I have requested from ELP Co. - to send me the latest AR0234CS register reference data sheet,
I hope I get reply…
Mike

> Dne 28. okt. 2025 ob 09:47 je oseba 'Jan' via OpenPnP <ope...@googlegroups.com> zapisala:
>
> Hi Mike!

> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/openpnp/22e87ea2-d250-47ca-9298-26cb9191e930%40googlemail.com.

Mike Menci

unread,

Oct 28, 2025, 5:37:14 AMOct 28

to ope...@googlegroups.com

The 1.456 ms in the manual moght simply be the worst-case spec that covers slow USB hosts, heavy bus load, or different sensor configurations…

> Dne 28. okt. 2025 ob 10:19 je oseba Mike Menci <mike....@gmail.com> zapisala:
>
> Hi Jan,

Mike Menci

unread,

Nov 8, 2025, 10:56:06 AMNov 8

to OpenPnP

For flyover camera testing I need to automatically trigger ELP camera when the nozzle passes through a specific X-axis zone (155-165mm).

What I have working:

✅ Script runs manually from Scripts tab
✅ Camera triggering via Arduino Mega (M240 command) works
✅ Nozzle position reading works in script
✅ Vision pipeline with script stage works (but requires manual triggering)

The challenge:
I need the script to run automatically during X-axis motion when the nozzle enters the camera zone. I've tried:

MOVE_TO_COMPLETE_COMMAND with ${SCRIPT:...} - Times out (OpenPnP sends script to Smoothie board)
Vision pipeline script stage - Only runs on manual vision operations
Actuator script configuration - Only runs on manual actuator calls

My setup:

Main board: Smoothie (PNPBOARDV1.7) for motion
Camera control: Arduino Mega (sends M240 for camera trigger)
Script: snapOverCamera.bsh that checks nozzle position and triggers camera

The question:
What's the correct way to automatically execute a position-checking script during nozzle motion in OpenPnP?

Should I be using:

Machine-level script hooks?
Different driver configuration?
Custom job processors?
Another approach I'm missing?

Any guidance would be greatly appreciated!

Message has been deleted

tonyl...@gmail.com

unread,

Nov 8, 2025, 9:30:59 PMNov 8

to OpenPnP

I hate to throw a damper on your party, but AFAIK, OpenPnP does not "know" the dynamic position of anything during a move. It only "knows" the beginning and end of each move. I believe the hardware controller is the only thing that "knows" the instantaneous position of the machine. I may be missing something, but it seems to me that the camera needs to be triggered by a hardware signal directly from the controller (when it determines the machine is at a particular position) and not via some script running in OpenPnP.

Arthur Wolf

unread,

Nov 8, 2025, 10:40:48 PMNov 8

to ope...@googlegroups.com

Hey everyone.

Just a small message to say I've been following the conversation, and if somebody needs a motion controller to do something special, this is an open free offer for me coding a custom module for smoothie v1 or v2 firmware that does whatever is needed here, like triggering a pin at a specific point in a given move, or triggering a pin when the position "goes over" a certain configured position, etc. I'm not certain from the conversation that I understand exactly what is required, but i'm sure you guys can figure that out. Just give me a very clear specification of what you need the firmware to do, and I'll code it, even though I don't personally have a pnp to test it on, I can do some testing on a 3D printer or laser.

Cheers.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/5ecb9674-5a8e-43f9-926c-59b62df129e4n%40googlegroups.com.

--

勇気とユーモア

Mike Menci

unread,

Nov 9, 2025, 1:31:38 AMNov 9

to OpenPnP

Hi Artur,

Thank you so much for your generous offer to help! Your expertise would be incredibly valuable for OpenPnP pick-and-place flyover camera feature.

Project Goal:

I need to trigger a camera when the nozzle flies over a fixed camera position during rapid XY moves (Z-optional).

Hardware Setup:

Controller: Smoothieboard
Motion: X and Y axes
Camera: External camera triggered via digital output

Specification Request:

Core Functionality:

Trigger a digital output when the machine passes through a configured XY position zone during G1 moves
Support for both X and Y axis position checking
Configurable trigger zone (center position + tolerance)

Desired Features:

Configurable trigger position (X, Y coordinates)
Configurable trigger zone size (tolerance around center point)
Multiple trigger modes:
- Trigger on zone entry
- Trigger on zone exit
- Trigger continuously while in zone
Speed compensation (if feasible)
Enable/disable via Gcode command

Technical Details:

Trigger output: Specific digital pin (configurable)
Trigger pulse: Configurable duration
Position sampling: As frequent as Smoothie's motion planning allows
Gcode interface: Commands to set trigger parameters

Why Smoothie-Based (Not External Hardware):

I want to keep the solution integrated within Smoothie rather than relying on external encoder hardware (servo ..), to maintain simplicity and use Smoothie's precise motion planning.

Testing:

Initial testing: On your 3D printer (simulating nozzle movement)

I can test on my PnP machine once you have a prototype.

Would this specification work for a custom Smoothie module? We're happy to provide any additional details needed.

ELP camera specification enclosed for info.

Thank you again for this amazing offer!

Mike

ELP-USBGS1200P02 Global Shutter Trigger operation Manual.pdf

Arthur Wolf

unread,

Nov 9, 2025, 2:35:01 PMNov 9

to ope...@googlegroups.com

I think I can code this, a few questions.

1. Smoothie v1 or smoothie v2? I need to code it for either one or the other.

2. If you do the math of how fast you'll be going/the required timing, would a 1khz poll rate work for this? (smoothie has an internal 1khz polling system that would make this straightforward to implement, higher rates make this exponentially more complex to implement). Essentially, if I knew what's the lowest polling rate that would work for a typical PNP, I'd try to aim somewhere above/better than that.

Cheers.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/03fc9fa2-8988-483a-bbfb-9564500edae4n%40googlegroups.com.

--

勇気とユーモア

Mike Menci

unread,

Nov 9, 2025, 3:53:33 PMNov 9

to OpenPnP

Hi Arthur
For Smoothie 1 for me & 1kHz will do for the start - well we still need to see how ELP 002 camera will cooperate
1kHz Poll Rate: Absolutely sufficient!

- Typical PnP speeds: 50-300 mm/s
- At 1kHz: 0.05-0.30mm position error
- Camera FOV: 2-5mm typically
- 1kHz provides excellent precision for our needs

1kHz implementation would be perfect! The exponential complexity of higher rates isn't needed for PnP camera triggering.

Arthur Wolf

unread,

Nov 9, 2025, 10:45:26 PMNov 9

to ope...@googlegroups.com

Ok and how do you want the trigger "area" to be defined?

* A circle (center point + radius)?

* A rectangle (corner point + size)?

* Something else?

To view this discussion visit https://groups.google.com/d/msgid/openpnp/b4020a96-71c0-4e28-bcbc-2fa22d0e9af2n%40googlegroups.com.

--

勇気とユーモア

Mike Menci

unread,

Nov 10, 2025, 12:20:42 AMNov 10

to OpenPnP

Hi
A circle center point + radius is fine

Mike Menci

unread,

Nov 10, 2025, 12:56:55 AMNov 10

to OpenPnP

Arthur
My Calculation Was Wrong:

Correction is:

1kHz = ±1000μs error vs your ±5μs capability
At 300mm/s: 1000μs = 0.3mm position error
With 100 steps/mm: That's 30 steps of error!
My Yaskawa servos can do much better (±0.015mm)

🎯 Revised Assessment: For PnP Precision:

Required accuracy: < 0.05mm for reliable vision
"Thank you for the offer, but after recalculating, I realize Smoothie v1's 1kHz poll rate provides insufficient precision (±0.3mm error) for my PnP accuracy requirements.
I'll explore hardware-level solutions using my Yaskawa servo encoders instead."

Arthur Wolf

unread,

Nov 10, 2025, 1:34:43 AMNov 10

to ope...@googlegroups.com

Like I said, 1khz makes things easier to code, higher rates makes it more difficult, but not impossible. No need to give up yet.

If you were able to give me a target frequency, I'll work with that, do your math, give me a value, and we'll go from there.

Cheers.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/d28753e7-a6f8-4f9a-97c4-88002d40982fn%40googlegroups.com.

--

勇気とユーモア

Mike Menci

unread,

Nov 10, 2025, 1:47:59 AMNov 10

to OpenPnP

Hi Arthur
A bit of practical OpenPnP way of thinking:
With respect to Feeder/Pick Tolerances:

Feeder pocket clearance: ±0.1-0.3mm
Part placement in tape: ±0.2mm
Nozzle pick accuracy: ±0.1mm
Total pick uncertainty: ±0.4-0.6mm

What This Means:

Even with perfect ±0.015mm camera triggering, the part itself arrives at the camera with ±0.5mm uncertainty!

The Real Requirement:Camera FOV Considerations:

Typical PnP camera FOV: 3×3mm to 6×6mm
Part size + uncertainty: Needs margin in FOV
For 0603 component (0.6mm): ±0.5mm uncertainty = 1.6mm total
Required FOV: At least 2×2mm for reliable inspection

Trigger Accuracy vs Practical Needs:

Your ±0.3mm (1kHz) trigger error = acceptable
Part position uncertainty = apx. ±0.5mm (dominant error)
Camera FOV = 3-6mm (plenty of margin)

Revised Conclusion:

Smoothie v1 with 1kHz (±0.3mm) trigger accuracy IS SUFFICIENT for practical PnP applications because:

Part position uncertainty (±0.5mm) dominates over trigger error
Camera FOV (3-6mm) provides ample margin
Vision correction can handle the combined errors
Cost/benefit favors simpler solution

Quick Follow-up for Artur:

"After reconsidering practical SMT tolerances, I realize that ±0.3mm trigger accuracy is actually sufficient for this application. The dominant error comes from part positioning in feeders (apx. ±0.2mm), making ultra-precise triggering unnecessary.

Your 1kHz solution should work!"

Am I right - we were over-engineering for theoretical precision that doesn't matter in practice!

For 0402 and larger components, the ±0.3mm trigger accuracy is FINE!

Component Size Analysis:0402 Components:

Size: 1.0mm × 0.5mm
With ±0.5mm pick uncertainty: Needs ~2.0mm FOV
With ±0.3mm trigger error: Still fits in 2.5mm FOV
Typical camera FOV: 3×3mm to 6×6mm

0201 Components:

Size: 0.6mm × 0.3mm
With ±0.5mm pick uncertainty: Needs ~1.6mm FOV
With ±0.3mm trigger error: Pushes to ~2.2mm FOV
Still fits in most PnP camera FOVs

01005 Components:

Size: 0.4mm × 0.2mm
This becomes challenging with combined errors
But most hobbyist/small PnPs don't handle 01005 anyway

Practical Reality:What Matters:

Camera FOV size (your safety margin)
Vision algorithm robustness (can find part within FOV)
Part never arrives perfectly centered anyway

Basic Setup:

Typical bottom camera: 3×3mm to 6×6mm FOV
Combined error: max±0.3mm (pick) + ±0.3mm (trigger) = ±0.6mm
Total uncertainty: 1.2mm diameter
Fits easily in 3mm FOV with 0.8mm margin each side

Conclusion:

For 0402 and larger components (which covers 95% of typical SMT work), Smoothie v1's ±0.3mm trigger accuracy is ADEQUATE!

The part positioning uncertainty is the dominant error source, not the trigger timing.

I was over-engineering camera position precision that doesn't improve real-world results.

Artur's 1kHz solution should work for ELP camera and its needs!

vespaman

unread,

Nov 10, 2025, 2:59:58 AMNov 10

to OpenPnP

Mike,

I have to admit, that I don't really understand the goal and your calculations above. And I haven't followed this thread very carefully, so take my points with a grain of salt, if they don't make sense to you. :-) :-)

But; your dominant pick uncertainty, isn't dominant at all, is it? I mean that pick uncertainty is what the whole trip to the camera is all about to cancel out. Right?

Then you mention FOV (Field Of View), but is this really relevant here, to this point? (Or do you really have such a small FOV on your setup, that it needs to be considered?). Also if FOV is something to consider, wouldn't it be with large components?

When it comes to precision, I am pretty sure 0.3mm will be a real show stopper for a lot of people - 0.5mm pad pitch is rather common these days (I am about to populate a board with a small IC with 0.4 pad pitch...).

I realize there's a lot of users out there, which might be fine with 0.3mm, but then, wouldn't they also be fine with stopping the nozzle over the camera?

Or are you perhaps only trying to make a proof of concept?

- Micael

Mike Menci

unread,

Nov 10, 2025, 4:13:27 AMNov 10

to ope...@googlegroups.com, OpenPnP

@Mike,

Thank you for the excellent and thoughtful critique! You're absolutely right on several key points:

You're correct that:

· For fine-pitch components (0.4mm pitch), ±0.3mm trigger error is unacceptable

· The whole point of vision is to cancel out pick uncertainty, not add to it

· Production SMT work requires much better precision

My current reality:

This is primarily a proof-of-concept and testing setup for:

· Flyover triggering methodology

· Camera synchronization testing

· Speed measurement during motion

· Larger components (0805+) where ±0.3mm is workable

· Educational applications in my workshop

@Artur,

Given Mike's valid production concerns, I'd still love you to implement the best possible solution within Smoothie's capabilities. Even if it might be not suitable for small pitch ICs, it will be incredibly valuable for my testing and development.

I'm proposing these simple G-code commands:

Core Trigger Commands:

· Mxx11 Xa.aa Ya.aa Xb.bb Yb.bb ... - Upload XY trigger point coordinates

· Mxx12 - Enable trigger list (once, ascending direction)

· Mxx13 - Disable triggering

· Mxx14 Xc.cc Yc.cc Rr.rr - Upload circular trigger zone

· Mxx15 - Clear all trigger points

Optional Enhancements:

· Mxx16 Sm - Set trigger mode (1=entry, 2=exit, 3=continuous)

· Mxx17 Tms - Set trigger pulse duration (50ms default)

· Mxx18 Pp.p - Set trigger output pin

· Mxx19 Vbool - Enable/disable (1=on, 0=off)

My goal: Get the best possible solution from my current setup with minimal cost impact. Any improvement over manual triggering represents valuable progress for my testing needs!

This G-code approach gives me the flexibility I need while keeping the firmware implementation straightforward.

Thank you both for the thoughtful discussion!

Dne 10. nov. 2025 ob 09:00 je oseba vespaman <micael....@gmail.com> zapisala:

To view this discussion visit https://groups.google.com/d/msgid/openpnp/7a1dd527-7f89-42e1-b87f-d51d7e84b5den%40googlegroups.com.

Jan

unread,

Nov 10, 2025, 6:28:14 AMNov 10

to ope...@googlegroups.com

Hi Arthur!
Many thanks for your kind off to add a module to support hardware
triggering a camera. I'm not as experienced with hardware triggered
cameras like Mike yet, but I'm coming from the OpenPnP side
implementation wise.
I'd love to have a functionality, that allows me to send a command to
the controller that registers a XY coordinate (Z would be nice, it is
likely not needed) at which the controller outputs a pulse (rising edge
at present plus going down later). The pulse is ideally generated using
the step/dir generator (for perfect alignment with the motors/distance),
a one-shot (uses will have to arm the trigger when the head starts
moving towards the camera) and support more then one XY coordinate (to
trigger for multiple nozzles). The ELP-Camera, we're talking about, is
triggered using a rising edge and requires a minimum pulse width. The
actual width is not relevant and does not need to be fix (I guess). That
would allow to set the trigger output using the step/dir generator and
reset it later using some background service.
I think, the window/area you mentioned, is a good idea as it makes sure
the trigger is always generated, but I don't see the need for complex
math like a cycle. If x and y have a certain band in which the trigger
is generated, it is ensured that the actual trajectory passes through
that area and the trigger is generated.

Jan

On 10.11.2025 07:34, Arthur Wolf wrote:
> Like I said, 1khz makes things easier to code, higher rates makes it
> more difficult, but not impossible. No need to give up yet.
> If you were able to give me a target frequency, I'll work with that, do
> your math, give me a value, and we'll go from there.
>
> Cheers.
>
> On Mon, Nov 10, 2025 at 6:57 AM Mike Menci <mike....@gmail.com
> <mailto:mike....@gmail.com>> wrote:
>
> Arthur
> My Calculation Was Wrong:
>
> Correction is:
>

> *

>
> 1kHz = ±1000μs error vs your ±5μs capability
>

> *

>
> At 300mm/s: 1000μs = 0.3mm position error
>

> *

>
> With 100 steps/mm: That's 30 steps of error!
>

> *

>
> My Yaskawa servos can do much better (±0.015mm)
>
> 🎯 Revised Assessment: For PnP Precision:
>

> *

>
> Required accuracy: < 0.05mm for reliable vision
> "Thank you for the offer, but after recalculating, I realize
> Smoothie v1's 1kHz poll rate provides insufficient precision
> (±0.3mm error) for my PnP accuracy requirements.
> I'll explore hardware-level solutions using my Yaskawa servo
> encoders instead."
>
>
> On Sunday, 9 November 2025 at 21:53:33 UTC+1 Mike Menci wrote:
>
> Hi Arthur
> For Smoothie 1 for me & 1kHz will do for the start - well we
> still need to see how ELP 002 camera will cooperate
> 1kHz Poll Rate:Absolutely sufficient!
>

> 1.
> *

>
> Typical PnP speeds: 50-300 mm/s
>

> *

>
> At 1kHz: 0.05-0.30mm position error
>

> *
>
> Camera FOV: 2-5mm typically
>
> *

>
> 1kHz provides excellent precision for our needs
>
> 1kHz implementation would be perfect! The exponential complexity
> of higher rates isn't needed for PnP camera triggering.
>
>
> On Sunday, 9 November 2025 at 20:35:01 UTC+1 Arthur Wolf wrote:
>
> I think I can code this, a few questions.
>
> 1. Smoothie v1 or smoothie v2? I need to code it for either
> one or the other.
> 2. If you do the math of how fast you'll be going/the
> required timing, would a 1khz poll rate work for this?
> (smoothie has an internal 1khz polling system that would
> make this straightforward to implement, higher rates make
> this exponentially more complex to implement). Essentially,
> if I knew what's the lowest polling rate that would work for
> a typical PNP, I'd try to aim somewhere above/better than that.
>
> Cheers.
>
> On Sun, Nov 9, 2025 at 7:31 AM Mike Menci
> <mike....@gmail.com> wrote:
>
> Hi Artur,
>
> Thank you so much for your generous offer to help! Your
> expertise would be incredibly valuable for OpenPnP pick-
> and-place flyover camera feature.
>
> Project Goal:
>

> I need *to trigger *a camera when the nozzle flies over
> a fixed camera position *during rapid XY moves* (Z-
> optional).
>
> Hardware Setup:
>
> *
>
> Controller: Smoothieboard
>
> *

>
> Motion: X and Y axes
>

> *

>
> Camera: External camera triggered via digital output
>
> Specification Request:
>
> Core Functionality:
>

> *

>
> Trigger a digital output when the machine passes
> through a configured XY position zone during G1 moves
>

> *

>
> Support for both X and Y axis position checking
>

> *

>
> Configurable trigger zone (center position + tolerance)
>
> Desired Features:
>

> 1.

>
> Configurable trigger position (X, Y coordinates)
>

> 2.

>
> Configurable trigger zone size (tolerance around
> center point)
>

> 3.
>
> Multiple trigger modes:
>
> *
>
> Trigger on zone entry
>
> *
>
> Trigger on zone exit
>
> *

>
> Trigger continuously while in zone
>

> 4.
>
> Speed compensation (if feasible)
>
> 5.

>
> Enable/disable via Gcode command
>
> Technical Details:
>

> *

>
> Trigger output: Specific digital pin (configurable)
>

> *
>
> Trigger pulse: Configurable duration
>
> *

>
> Position sampling: As frequent as Smoothie's motion
> planning allows
>

> *

>
> Gcode interface: Commands to set trigger parameters
>
> Why Smoothie-Based (Not External Hardware):
>
> I want to keep the solution integrated within Smoothie
> rather than relying on external encoder hardware
> (servo ..), to maintain simplicity and use Smoothie's
> precise motion planning.
>
> Testing:
>

> *

>
> Initial testing: On your 3D printer (simulating
> nozzle movement)
>
> I can test on my PnP machine once you have a prototype.
>
> Would this specification work for a custom Smoothie
> module? We're happy to provide any additional details
> needed.
>
>
> ELP camera specification enclosed for info.
>

> ------------------------------------------------------------------------

> *

>
> ✅ Script runs manually from Scripts tab
>

> *

>
> ✅ Camera triggering via Arduino Mega
> (M240 command) works
>

> *

>
> ✅ Nozzle position reading works in script
>

> *

>
> ✅ Vision pipeline with script stage
> works (but requires manual triggering)
>
> The challenge:
> I need the script to run automatically
> during X-axis motion when the nozzle enters
> the camera zone. I've tried:
>

> 1.

>
> MOVE_TO_COMPLETE_COMMAND with
> ${SCRIPT:...} - Times out (OpenPnP sends
> script to Smoothie board)
>

> 2.

>
> Vision pipeline script stage - Only runs
> on manual vision operations
>

> 3.

>
> Actuator script configuration - Only
> runs on manual actuator calls
>
> My setup:
>

> *

>
> Main board: Smoothie (PNPBOARDV1.7) for
> motion
>

> *

>
> Camera control: Arduino Mega (sends M240
> for camera trigger)
>

> *

>
> Script: snapOverCamera.bsh that checks
> nozzle position and triggers camera
>
> The question:
> What's the correct way to automatically
> execute a position-checking script during
> nozzle motion in OpenPnP?
>
> Should I be using:
>

> *
>
> Machine-level script hooks?
>
> *
>
> Different driver configuration?
>
> *
>
> Custom job processors?
>
> *

> openpnp/ <https://groups.google.com/d/
> msgid/openpnp/> ee6d3a37-
> a539-4a21-9101-52d79659a0c7n%40googlegroups.com <http://40googlegroups.com> <https:// groups.google.com/d/msgid/openpnp/ee6d3a37- <http://groups.google.com/d/msgid/openpnp/ee6d3a37-> a539-4a21-9101-52d79659a0c7n%40googlegroups.com <http://40googlegroups.com>? utm_medium=email&utm_source=footer>.

> >>
> >> --
> >> You received this message because
> you are subscribed to the Google Groups
> "OpenPnP" group.
> >> To unsubscribe from this group and
> stop receiving emails from it, send an
> email to openpnp+u...@googlegroups.com.
> >> To view this discussion visit
> https://groups.google.com/d/msgid/
> openpnp/22e87ea2-

> d250-47ca-9298-26cb9191e930%40googlemail.com <https://groups.google.com/d/msgid/openpnp/22e87ea2-d250-47ca-9298-26cb9191e930%40googlemail.com>.

>
> --
> You received this message because you are
> subscribed to the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop
> receiving emails from it, send an email to
> openpnp+u...@googlegroups.com.
>
> To view this discussion visit https://
> groups.google.com/d/msgid/

> openpnp/5ecb9674-5a8e-43f9-926c-59b62df129e4n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/5ecb9674-5a8e-43f9-926c-59b62df129e4n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
>
>
> --
>
> 勇気とユーモア
>
> --
> You received this message because you are subscribed to
> the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to openpnp+u...@googlegroups.com.
>
> To view this discussion visit https://groups.google.com/
> d/msgid/openpnp/03fc9fa2-8988-483a-

> bbfb-9564500edae4n%40googlegroups.com <https://
> groups.google.com/d/msgid/openpnp/03fc9fa2-8988-483a-
> bbfb-9564500edae4n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

>
>
>
> --
>
> 勇気とユーモア
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/d28753e7-a6f8-4f9a-97c4-88002d40982fn%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/d28753e7-
> a6f8-4f9a-97c4-88002d40982fn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

>
>
>
> --
>
> 勇気とユーモア
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/openpnp/

> CAMHZkm5XidhV7RC3BDM3gA8JHNzDmdBJBqGJtvEYc30ktCL_%2BA%40mail.gmail.com
> <https://groups.google.com/d/msgid/openpnp/
> CAMHZkm5XidhV7RC3BDM3gA8JHNzDmdBJBqGJtvEYc30ktCL_%2BA%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

Mike Menci

unread,

Nov 10, 2025, 7:15:02 AMNov 10

to OpenPnP

Jan - thank you for jumping in with those excellent technical specifications! Your requirements align perfectly with what I need for my ELP camera flyover testing.

To Artur: Jan's specification looks ideal for my use case. The key features I'd love to see implemented are:

Multiple XY trigger points (for different nozzle positions)
Rising edge pulse with configurable duration
Simple area/band detection as Jan described
Step/dir generator alignment for precision
One-shot trigger arming

Jan's approach of using the step/dir generator for trigger timing and a background service for reset sounds like the perfect balance of precision and simplicity.

This would give me exactly what I need for testing camera synchronization during motion, while being flexible enough for future multi-nozzle setups.

Thank you all for the fantastic technical discussion!

vespaman

unread,

Nov 10, 2025, 8:15:28 AMNov 10

to OpenPnP

Hi all,

I remember we discussed this in another thread some time ago. The idea I suggested then might not be the proper way to do it, maybe too much stress on the step code(?). But I guess @Artur has all the knowledge to find the best solution :-), so I was hesitant to bring it up. I know only my own (charmhigh) smoothie incarnation, so mileage may vary.

- Micael

Toby Dickenson

unread,

Nov 10, 2025, 8:18:35 AMNov 10

to ope...@googlegroups.com

Hi all,

Just to throw up another idea.... does it make sense to add the trigger as a parameter to the G1 movement command. That is, to move to a specific X/Y/Z/C point then trigger a pulse on arrival. And of course G1 commands can be queued up, so the machine can move smoothly through that point triggering a pulse as it passes through.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/bfd6e1e7-04ec-40ec-a0d9-6d35acfed959n%40googlegroups.com.

Mike Menci

unread,

Nov 10, 2025, 8:51:57 AMNov 10

to OpenPnP

I see this as a brilliant idea!
Adding a trigger parameter to G1 commands would be incredibly elegant. Syntax like G1 X160 Y100 F10000 T1 to trigger at position would be simple to implement, perfectly synchronized with motion, and work seamlessly with existing motion planning. This might be the cleanest solution yet!
Jan ? Arthur?

Mike Menci

unread,

Nov 10, 2025, 9:05:27 AMNov 10

to OpenPnP

And for the early trigger parameter, distance-based (mm) makes much more sense than time-based (ms).
- G1 X160.00 Y100.00 F10000 T1 R3.0 ; Trigger when within 3mm of target
- G1 X160.00 Y100.00 F10000 T1 E15 ; Trigger 15ms before target
With an 'R3.0' parameter (trigger when within 3mm of target), calibration becomes simple: take a test image, measure the position offset in mm, and set R to that value. This is easily measurable with the camera itself and works consistently at any speed, unlike time-based triggering which requires complex timing equipment and varies with feed rate...-

Arthur Wolf

unread,

Nov 10, 2025, 10:38:09 AMNov 10

to ope...@googlegroups.com

On Mon, Nov 10, 2025 at 2:52 PM Mike Menci <mike....@gmail.com> wrote:

I see this as a brilliant idea!
Adding a trigger parameter to G1 commands would be incredibly elegant. Syntax like G1 X160 Y100 F10000 T1 to trigger at position would be simple to implement, perfectly synchronized with motion, and work seamlessly with existing motion planning. This might be the cleanest solution yet!

That's something I was planning to try first before coding anything: the laser module causes a pin to be triggered when using G1 and not triggered when using G0, so that would allow you to implement all this with just a laser pin configuration, and some custom openpnp code generating G1s/G0s in the right places. But I wasn't sure how well this would work so I didn't mention it so far, but yes it's actually something you can try out right now, it's just not very "clean". But in theory it should work pretty well.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/e04fdbd8-549a-4983-b2ba-04638ea0f948n%40googlegroups.com.

--

勇気とユーモア

Henrik Olsson

unread,

Nov 10, 2025, 12:11:44 PMNov 10

to OpenPnP

1) I think that for best / most bullet proof performande the pulse must come from the step generator. Like a hardware counter compare kind of thing. I don't think polling is going to cut it. Might work some times and not others, there's just too many variables I think.

2) Doesn't Smoothies motion planner perform lookahead when, for example, multiple G1 moves are "lined up"?

If it DOESN'T have lookahead then G1 X160 Y100 F10000 T1 will cause the nozzle to decelerate and stop at the target position which kind of defeats the purpose and you might as well create the trigger with an M code in between G1 lines.

If it DOES have lookahead then there's a very large risk that the nozzle will never reach X160 Y100 since the lookahead/planner will start to move towards to the next "waypoint" early, causing the "corner to be rounded". The amount of rounding then depends on the angle between the "aproach" and "departure" moves which will obviously be different unless you make sure that start position, intermediate position (camera location) and end position all lies on a straighlt line.

Also, keep in mind that the current recommended Smoothie firmware for use with OpenPnP is not the stock/default one. Perhaps it doesn't matter at all, I just wanted to bring it up in case it might.

/Henrik.

Arthur Wolf

unread,

Nov 10, 2025, 12:16:38 PMNov 10

to ope...@googlegroups.com

No no, it of course has look-ahead, and it wouldn't stop just because there are two different gcodes, it woud be pretty terrible at things like laser cutting or cnc milling or even 3D printing if that were the case.

So the thing right now is this sounds like it's possible right out of the box with smoothie, assuming openpnp is modified to send the right gcodes (ie switch from G0 to G1 at the right position).

The thing I'm trying to wrap my brain around is if I can code a module that allows us to do this without changing openpnp at all, like get the benefits of breaking a move in on/off sections based on a zone, like openpnp would, but fully transparently inside of smoothie. I think a solution that doesn't require openpnp to be modified is ideal here, it's just more work, and I'll be looking at the code this week to try to figure out a clean way to get this to work.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/e37c2395-4af5-42e8-ae7a-cca3b93a9798n%40googlegroups.com.

--

勇気とユーモア

Chris Campbell

unread,

Nov 10, 2025, 3:29:20 PMNov 10

to ope...@googlegroups.com

Mike (or should I say, ChatGPT?)

I really have to wonder what you're expecting to do next, after the
camera triggering is in place. As I pointed out earlier, triggering
the camera is only the smallest and simplest piece of a much larger
puzzle.
For example, you could build a crude trigger with two bare wires that
touch together as the head moves over the camera. The repeatability
would be rather low, but that type of quick prototyping seems
appropriate to get past a relatively minor detail and tackle the real
meat of the problem (outlined in my earlier mail). So let's suppose
you already have the camera triggering done (either crudely or
superbly), what next?

> To view this discussion visit https://groups.google.com/d/msgid/openpnp/CAMHZkm6fZFJQYpyYZ4OL_-vgpEUjGTL%2BbK5VVneJjBiUbz%3DwiA%40mail.gmail.com.

Mike Menci

unread,

Nov 10, 2025, 5:13:33 PMNov 10

to OpenPnP

Hi Chris,

Thank you for your emails, and for pointing me to your excellent detailed technical analysis from October 21st. I hadn't seen that earlier discussion, and you raise absolutely valid points about the substantial system integration challenges.

Regarding your AI comment - I'll note that many of us are non-native English speakers and use tools to communicate clearly in complex technical discussions. The focus should remain on the technical content.

You're right that the real complexity begins after triggering: the OpenPnP architectural limitations, motion controller awareness requirements, USB timing constraints, and multi-nozzle coordination are indeed the "mortar" that makes flyover vision truly work.

My approach is incremental: I'm starting with camera triggering because it's a discrete, testable component that can be validated independently. Even if full real-time correction isn't immediately achievable, solving the triggering problem enables:

Practical testing of image quality during motion
Speed characterization for different camera types
Proof-of-concept validation of basic synchronization
Foundation building for the larger system

The "crude wire trigger" approach you mentioned wouldn't work for our needs - we require sub-millisecond precision for global shutter synchronization, which demands hardware-level solutions.

You've clearly done deep thinking on this problem. Rather than dismissing the triggering work as trivial, could you share which of the larger integration challenges you think should be addressed first? Your experience could help guide the community toward the most critical next steps.

I appreciate the reality check about the bigger picture - it helps keep the work focused on practical outcomes.

Arthur Wolf

unread,

Nov 10, 2025, 8:16:22 PMNov 10

to ope...@googlegroups.com

Regarding your AI comment - I'll note that many of us are non-native English speakers and use tools to communicate clearly in complex technical discussions. The focus should remain on the technical content.

I didn't say anything to be polite, but yes I agree with Chris it's quite disturbing, it feels like I'm not talking with a real human...

I'm sure you have good reasons for doing this, it's definitely a great tool for non-native speakers.

But the style is so artificial and so specific to what we are used to seeing from LLMs that it can get pretty strange/annoying.

Also, it's very obvious from the answers that you are not just using it to translate what you write, but that you actually use it to figure out what to answer, which means we are not talking just to you, we are in fact talking to you and to the AI, which can be a problem for some people. People in here take the time to help you with your task/issues, when they could be doing something else, you should in return take the time to think through and type actual answers without having the LLM do it for you, even if the LLM eventually translates what you write, I think it'd be much better if it were what *you* wrote, not what the LLM wrote.

Here is practical advice to help with this, you should actually explicitly instruct it to make sure it's not doing "this" we are complaining about.

Like, add the following to every prompt you send (just copy/paste):

« I am using your answers to reply in the openpnp mailing list, as-is, and some of the users there find it disturbing that my messages are so obviously generated by AI. In order to accommodate this, you should write your replies in a way that they are as close as possible to what they would be if a human had written them. This means no bold text, no emoji, no llm-like turns of phrase, no use of words only LLMs use (you can search the internet for articles that list these), etc.

You should write your reply, then in a second pass, transform it so it looks as much as possible like it was written by a human. Talk as if I were talking, from my perspective. »

This should help a lot, I think.

Cheers.

simpl...@tuta.io

unread,

Nov 10, 2025, 10:03:13 PMNov 10

to Openpnp, Openpnp

The use of AI is so obvious and amusing, and we all know that it is hardly a real help in solving many problems, since the answers generated are just a mishmash or copy of search engine results, nicely formatted but lacking in depth.

So let's not let spoil the fun, even if there will never be any real benefit from this whole endeavor. The cost/benefit analysis and critical questioning of the usefulness of using cheap components will sooner or later lead to the same conclusion, namely: a lot of fuss about nothing

If someone has no idea about programming and no other experience with solving complex problems, then perhaps years of begging and struggling for support will help. Eventually. Maybe.

I know from my experiments that everything depends on the quality of the trigger source, which allows only a few microseconds of tolerance at higher fly-by speeds, as otherwise inaccuracies in the further processing of the images lead to poor component placement quality.

The use of windows or radii for a trigger area is therefore complete nonsense and not effective if you want to take precise images. And how are you supposed to determine the offsets from the images if more than one axis is involved?

I'm already looking forward to the upcoming AI mud...

Jan

unread,

Nov 11, 2025, 5:23:55 AMNov 11

to ope...@googlegroups.com

Hi Arthur!
Many thanks for your suggestion to use G1. It might work for testing.
This is what I think Mike/we may try:

- setup the trigger output using the laser module
- use the Vision.PartAlignment.Before script event to request a G0 move
to a location in the vicinity of the camera (with the required distance
to trigger the camera with the necessary lead time) and a G1 to generate
the trigger (as you suggested). I've not verified that this script event
is called before the head is moved to the camera and I'm not sure if a
location shall be given with the G1 or if the G1 shall send the head
closer to the camera to enforce the trigger pulse width.
- afterwords the bottom vision code will request the final segment to
move the head to the camera location and perform the (synchronous)
bottom vision operation.

At present bottom vision starts by requesting the head to move to the
cameras location using the configured MOVE_TO_COMMAND (which usually
generates a G0), wait for it to arrive and perform vision operation.
With the above suggested modification, the head will first be send to a
location in the vicinity of the camera using G0, then a G1 will be used
to generate the trigger and finally the bottom vision code will request
the head to move to the cameras location again using G0. As Hendrik
pointed out, this three segments shall be joined by the controller and
the "in the vicinity of the camera location" shall be such, that the
delay to go to the cameras location is fix regardless of the location
the head is when bottom vision is requested. If that's not the case, a
second location in the vicinity of the camera might be needed that forms
a straight line with the first and allows the head to reach its target
speed when crossing the first enforcing a fix delay/speed between
trigger point and camera location.
What do you think, Arthur, will the laser module provide this
functionality?
Concerning the other questions: at present I have no good idea how to
extend the above for more then one nozzle. If we/the controller would
have a dedicated command to request trigger events, we could use that in
the script event to arm the trigger for one or more events.
I agree with Chris that hardware triggering the camera is just one
piece of a larger puzzle. As we discussed earlier, I'm confident, that
all users could benefit from asynchronous bottom vision and that
asynchronous bottom vision can be implemented without hardware triggered
cameras. The idea is simple: take the camera shot and process it in a
separate thread (asynchronously) allowing the head to continue moving.
The JobProcessor can be easily enhanced to take this into account: it
requests the head to move let say 80% of the distance towards the first
place location. Then it waits for bottom vision processing to finish and
requests the final segment. Assuming that moving this 80% takes longer
then the processing, the controller will join all the segments and the
head will make a continuous move with a slight bend. (Yes, if bottom
vision fails, this procedure will be very expensive because the head
needs to go back for a second shot.) If anyone wont's to take over this
piece of work, I'm very happy to help.

Jan

> I see this as a *brilliant idea!*

> Adding a trigger parameter to G1 commands would be
> incredibly elegant. Syntax like G1 X160 Y100 F10000 T1 to
> trigger at position would be simple to implement, perfectly
> synchronized with motion, and work seamlessly with existing
> motion planning. This might be the cleanest solution yet!
>
>
> That's something I was planning to try first before coding
> anything: the laser module causes a pin to be triggered when
> using G1 and not triggered when using G0, so that would allow
> you to implement all this with just a laser pin configuration,
> and some custom openpnp code generating G1s/G0s in the right
> places. But I wasn't sure how well this would work so I didn't
> mention it so far, but yes it's actually something you can try
> out right now, it's just not very "clean". But in theory it
> should work pretty well.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to openpnp+u...@googlegroups.com

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/
> openpnp/e37c2395-4af5-42e8-ae7a-cca3b93a9798n%40googlegroups.com

> <https://groups.google.com/d/msgid/openpnp/e37c2395-4af5-42e8-ae7a-
> cca3b93a9798n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>
>
> --
>
> 勇気とユーモア

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/openpnp/

> CAMHZkm6fZFJQYpyYZ4OL_-vgpEUjGTL%2BbK5VVneJjBiUbz%3DwiA%40mail.gmail.com
> <https://groups.google.com/d/msgid/openpnp/CAMHZkm6fZFJQYpyYZ4OL_-
> vgpEUjGTL%2BbK5VVneJjBiUbz%3DwiA%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

Arthur Wolf

unread,

Nov 11, 2025, 12:27:08 PMNov 11

to ope...@googlegroups.com

> What do you think, Arthur, will the laser module provide this functionality?

If I understand correctly, what you're saying: yes.

The laser module is very simple, it turns the laser on for G1 moves and off for G0 moves.

The planner/conveyor makes it so that there are no unnecessary slowdowns during those moves, so for example in the case of a laser you can use G0/G1 moves to raster-engrave an image at full speed etc.

So really, in this case, if you're going to be implementing this as a proof of concept, most of the logic would happen inside openpnp itself, i.e. having it generate the right G0/G1 commands as required for your needs.

I don't know much about the openpnp codebase, so I don't know how easy that would be.

> will sooner or later lead to the same conclusion, namely: a lot of fuss about nothing

If I can give a little bit of my experience about that (ignore if you're only interested in the fly-over camera stuff):

I found AI is massively helpful, when it's used correctly/for the right things. A lot of people try to use it for things it's not very good at (or tried to use it back when it was a lot dumber), and that harms its reputation, but it's incredible at some things, in particular inside agentic frameworks.

An example: We had to create a v2 documentation for smoothie, starting from the v1 docs. We used an agentic tool (claude code) to compare/understand the v1 codebase and the v2 codebase and create a fact sheet, which we then improved with internet searches, the smoothie docs, datasheets, forum posts, tons of things, and from that data created the v2 docs. Saved dozens of hours of really painful work, probably more. We still need to have multiple humans verify the work (ongoing now), but that's something we'd have done no matter what, and so far its work has been extremely high quality, like it "understood" the vast majority of things it had to understand for the task.

The price is a problem, this used two full weeks of a $200/month anthropic plan's weekly limits, so you can say it cost $100 (it would be thousands if using actual API credits instead of a plan), but the price goes down all the time, and it's still cheap compared to hiring a human or doing it myself.

To be clear, I was only able to accomplish this using an agentic tool because I have months of experience/learning to use one (which is, by the way, nearly a thousand dollars in plan payments, not exactly free), I wouldn't have been able to do any of this in my first few weeks of using one, you have to do a lot of trial/error/learning to figure out what it can and can't do and how to get it to do things, and I expect a lot of the negative press these get comes from those initial frustrations. Also, the improvements they've seen over just the past few months are incredible, they are massively more capable now than just 6 months ago, and I expect a lot of the bad reputation comes from times when they were a lot less capable (or from the free plans/the less smart models).

And it's not just docs, it's also incredible at coding, but again, you have to learn to use it right. For the smoothie docs, the original plan was to create a separate v2 docs "copy"/fork, but because we had access to agentic coding we were able to actually keep a single documentation and have fancy coded features that let us have a single documentation with sections that are v1 or v2 specific and a lot of very engaging features that make the site easier to use/navigate. We would never have had the time to code any of this if we had to do it by hand, but because something that would normally take an hour of work can be done in a couple of minutes, we were able to do a lot more.

Just my 2 cents/my personal experience on this :)

Cheers.

simpl...@tuta.io

unread,

Nov 11, 2025, 2:15:33 PMNov 11

to Openpnp, Openpnp

>>> using cheap components will sooner or later lead to the same conclusion, namely: a lot of fuss about nothing

>> If I can give a little bit of my experience about that

@Arthur: Haha, that sentence above actually referred to the modest quality of the ELP camera, which I don't consider suitable for use as a fly-by camera.

To clarify briefly: on my self-built PnP machines, i use fast industrial cameras for bottom vision in conjunction with my own custom-designed motion controllers. Pulse generation is based on ASICs, each capable of clock rates up to 16 MHz, and this applies to up to 18 axes simultaneously. However, i leave the camera triggering to the high-performance FPGAs in the Delta A3 servo drives, due to their wonderfully low latency and the practically direct relationship between the trigger point list (E-Cam/COMPARE) and the very rigid drive coupling provided by the ball screws.

But I'm pleased that you're handling AI correctly and achieving success through its meaningful application. I must confess, I'm not as open to new things as I used to be when i was younger.

Jan

unread,

Nov 12, 2025, 4:30:53 AMNov 12

to ope...@googlegroups.com

Hi Arthur!

On 11.11.2025 18:26, Arthur Wolf wrote:
> > What do you think, Arthur, will the laser module provide this
> functionality?
>
> If I understand correctly, what you're saying: yes.
>
> The laser module is very simple, it turns the laser on for G1 moves and
> off for G0 moves.
> The planner/conveyor makes it so that there are no unnecessary slowdowns
> during those moves, so for example in the case of a laser you can use
> G0/G1 moves to raster-engrave an image at full speed etc.
> So really, in this case, if you're going to be implementing this as a
> proof of concept, most of the logic would happen inside openpnp itself,
> i.e. having it generate the right G0/G1 commands as required for your needs.
> I don't know much about the openpnp codebase, so I don't know how easy
> that would be.
>

Many thanks for the confirmation. Just a last question: if the laser is
set to PWM, will a G1 to the same/current location generate a single PWM
cycle or will the PWM be cropped when motion continues as G0?

At present bottom vision is handled with the head located somewhere on
the machine and the first thing, that happens, is to send the
head/nozzle to the camera location. This is done using OpenPnPs
MOVE_TO_COMMAND, which usually issues a G0.
There is a scripting event before bottom vision. If that is (to be
confirmed) before the move to camera, it can be used to send the head to
a location P1 in the vicinity of the camera from which the distance to
the camera corresponds to the trigger latency. In addition the camera
trigger can be generated. If the bottom vision code now sends the head
to the cameras location, the controller will join all three segments
into a single motion with the trigger in between. That can serve as a
prove of concept and might even be a good "implementation" if only few
people make use of it.
The reason why I asked about the PWM cropping is to understand how the
laser module generates its output signal. If used as trigger it needs to
have a rising edge and a certain width to confirm with the AR0234
specification (for this camera). If the PWM output always generates a
full cycle and at least one, we can easily configure it with the
required pulse width. If the PWM output is cropped, we can consider it
as TTL (with very long pulse width to avoid double triggering) or make
use of the TTL output the laser module also generates. This would
require a second location P2 between P1 and camera at which the laser
(the trigger signal) is switched off. A G1 would then be issued to go to
P2 and bottom vision would again issue a G0 to go to the cameras location.
(An additional location P0 might be needed before P1 if the head can
have different feedrates when passing through P1 to always provide the
same trigger latency.)
I hope Mike will be able to confirm this prove of concept...

Jan

Arthur Wolf

unread,

Nov 12, 2025, 12:38:21 PMNov 12

to ope...@googlegroups.com

In PWM mode it won't be as precise as what you describe, it'll just turn the pwm signal on, and whatever the pwm timer is doing at that time will occur, I don't think it'll be as precisely reliable as what you're describing/expecting, for that we'd need a custom module to be coded I expect.

I wasn't even thinking of using the pwm mode, I was just thinking of using the TTL output which just turns fully on/fully off depending on if it's a G0 or G1 move.

I think the best plan here would just be to try it out and see how it behaves.

The laser module is good for a proof of concept/exploration but I don't think it'll be as precise as what you're describing. But I can code a module that will be more precise, that's fine, I'll be working on that now that I have detailed specs.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/fda50ef1-c0d5-40b3-b952-faf6eb77adc8%40googlemail.com.

--

勇気とユーモア

Mike Menci

unread,

Nov 12, 2025, 3:21:16 PMNov 12

to OpenPnP

Hi Jan and Arthur,
- G1 from X150 to X170 means TTL stays HIGH for the entire 20mm move
- ELP camera expects = brief 3ms pulse, not continuous signal.
Result = Camera either ignores it or triggers multiple times unpredictably...
What ELP needs: |___| (3ms pulse)
What laser gives: |------------| (entire move duration - could be 1000ms!)
Move duration depends on distance and speed, ELP needs precise 3ms pulse regardless of move parameters
& Laser TTL has no pulse width control - it's just on/off
What we need is Arthur's Custom Firmware with precision pulse generation at exact positions
configurable (0- xxx ms) pulse width.( or 3ms for ELP)

Jan - where will the images from camera go ?
This are not "snap shot" images and they disappear into the vision system and are gone
unless you explicitly code where to save them...

Arthur Wolf

unread,

Nov 12, 2025, 4:00:57 PMNov 12

to ope...@googlegroups.com

On Wed, Nov 12, 2025 at 9:21 PM Mike Menci <mike....@gmail.com> wrote:

Hi Jan and Arthur,
- G1 from X150 to X170 means TTL stays HIGH for the entire 20mm move

It doesn't have to be 20mm though, you can calculate what distance would cause a 3ms pulse (assuming full speed), and just use that distance for the G1 move, and you should be good.

If you have one, you can also throw a few components on a breadboard and convert a long signal into a short pulse, that should be fairly easy if you have the required hardware, I can help with figuring out the circuit if needed.

But just figuring out the right distance to have the right pulse duration should be very easy.

I really think this can get you the ability to test things until I actually code the module.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/3ac26afc-34fa-4cde-957c-95f223b5da6en%40googlegroups.com.

--

勇気とユーモア

Mike Menci

unread,

Nov 12, 2025, 4:17:28 PMNov 12

to OpenPnP

My belt driven test jig does not reach 0.1mm accurancy...
Typical belt accuracy: ±0.1mm to ±0.3mm ++++ Backlash: Additional 0.1mm+ uncertainty

Arthur Wolf

unread,

Nov 12, 2025, 5:16:34 PMNov 12

to ope...@googlegroups.com

On Wed, Nov 12, 2025 at 10:17 PM Mike Menci <mike....@gmail.com> wrote:

My belt driven test jig does not reach 0.1mm accurancy...
Typical belt accuracy: ±0.1mm to ±0.3mm ++++ Backlash: Additional 0.1mm+ uncertainty

Sure, but this is just for testing/proof of concept, I understand using the laser module won't get you to perfectly accurate placement right now, but it should get you some of the way there, and help move things along/figure out some of the things about engineering this problem. I recommend just trying it and seeing how it goes, I think useful things would be learned, and once I code the actual module we can get even more out of the setup.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/ae0d57a0-18ff-4205-8626-17ae5ab01b4an%40googlegroups.com.

--

勇気とユーモア

Jan

unread,

Nov 12, 2025, 5:51:47 PMNov 12

to ope...@googlegroups.com

Many thanks for the explanation, Arthur! Sounds like expected behavior
if multiple PWM outputs share a single timer.
Ok, so we'll need to go with the TTL output of the Laser module and
move a short distance using G1.
Mike, ELP provides a hardware trigger mode for continuous frame
generation (with a long trigger pulse) if Backlight contrast is set to 2
and hardware trigger mode for a single frame only if Backlight contrast
is set to 4. I assume, that the later can cope with any trigger pulse
width (suppose it satisfies the minimum width requirement).
Concerning the image location: I don't know yet how the image grabbing
in OpenPnP actually works. I assume, that the driver queries the camera
for new images and loads them when available. When done, this image
overwrites the previous and is stored for future use. If bottom vision
is executed, it requests an image from the driver, gets the one image
the driver currently has and removes this image from the driver. If a
new image is requested, the driver delays the request until the camera
has provided a new one. I guess this would be the perfect time for a
camera driver expert to join in...

Jan

> <https://groups.google.com/d/msgid/openpnp/fda50ef1-c0d5-40b3-
> b952-faf6eb77adc8%40googlemail.com>.
>
>
>
> --
>
> 勇気とユーモア

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/3ac26afc-34fa-4cde-957c-95f223b5da6en%40googlegroups.com
> <https://groups.google.com/d/msgid/
> openpnp/3ac26afc-34fa-4cde-957c-95f223b5da6en%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

bert shivaan

unread,

Nov 13, 2025, 4:43:52 PMNov 13

to ope...@googlegroups.com

And back to where I was trying to explain the trigger issues :)

I do not propose the trigger in G code is not an excellent idea, but it may not be portable across platforms. That does not mean we should not use it, just that maybe we should look for other ways as well.

Mike, You already have a means to trigger when you want given a command from OpenPNP correct?

I think the "flyover run" should ALWAYS start from the same position and ALWAYS move to a known position and ALWAYS be at the same speed. Given these 3 conditions the nozzle should always be at the same position relative to when that move started. So you can send your command to trigger to the arduino when the flyover run is started. Then it should just be a matter of timing adjust to hit that nail on the head.

Henrik, I agree the best solution is to have the motion control board fire the trigger when the position is where it should be, but that is not a great option given the number of different boards and software people are using.

From the beginning I liked having an optical trigger that is adjustable delay based on when that trigger is closed. It will always be reliable and not dependent on backlash or any other variables. Simply have your Adrduino wait for the trigger to fire the camera. It could even have a ignore command so it doesnt fire everytime the axis moves past it.

Arthur can smoothie watch an input and use it to time delay a trigger?

Honestly I think this approach is the most platform independent. It could be a simple as a 555, but thats no fun cuz no bit twiddling to adjust the time.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/d794eebe-b9f1-4d26-b30d-50603b96d3e1%40googlemail.com.

Arthur Wolf

unread,

Nov 13, 2025, 4:49:57 PMNov 13

to ope...@googlegroups.com

On Thu, Nov 13, 2025 at 10:43 PM bert shivaan <bert.s...@gmail.com> wrote:

And back to where I was trying to explain the trigger issues :)

I do not propose the trigger in G code is not an excellent idea, but it may not be portable across platforms. That does not mean we should not use it, just that maybe we should look for other ways as well.

I never suggested we shouldn't, this is just an idea for something that could allow for earlier testing, but for sure a more permanent solution is needed which is why I suggested coding a custom smoothie module, I've actually started working on that.

Mike, You already have a means to trigger when you want given a command from OpenPNP correct?
I think the "flyover run" should ALWAYS start from the same position and ALWAYS move to a known position and ALWAYS be at the same speed. Given these 3 conditions the nozzle should always be at the same position relative to when that move started. So you can send your command to trigger to the arduino when the flyover run is started. Then it should just be a matter of timing adjust to hit that nail on the head.

Henrik, I agree the best solution is to have the motion control board fire the trigger when the position is where it should be, but that is not a great option given the number of different boards and software people are using.

From the beginning I liked having an optical trigger that is adjustable delay based on when that trigger is closed. It will always be reliable and not dependent on backlash or any other variables. Simply have your Adrduino wait for the trigger to fire the camera. It could even have a ignore command so it doesnt fire everytime the axis moves past it.

Arthur can smoothie watch an input and use it to time delay a trigger?

It could with custom code.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNx40ZCqAuN6zh_jpfsrnh8OEm%3Dtzd3_o-PGH2nSV8J6Dg%40mail.gmail.com.

--

勇気とユーモア

Mike Menci

unread,

Nov 13, 2025, 5:00:31 PMNov 13

to OpenPnP

Hi
I can trigger the camera;
_ From Bottom vision by script stage (special .bsh) code any time - still image (no motion) - only last one can be seen in folder

- from Mega Mini sub controller with Arduino code ( by image or by set of images) with separate .bsh OpenPnP script and by ELP special software - still stand nozzle ( see enclosed - see time how fast camera is)

but this are not moving nozzle images - becouse this is what is missing and Arthur is looking for solutiojn with Jan.

OpenPnP-ELP-Captures - File Explorer.png

ELPGSCAP_V1.1 (全局软件）_TriggerImages - File .png

ELPGSCAP_V1.1 (全局软件）_TriggerImages - Files .png

Message has been deleted

bert shivaan

unread,

Nov 14, 2025, 5:59:17 AMNov 14

to ope...@googlegroups.com

Hi Mike, I know you have only tested so far with still images. Let me try to explain differently

Assuming you can send a "gcode" command to your Mega, My suggestion is that gets sent right after the gcode to Smoothie to start the fly over run.

Then you Mega can capture the command to trigger and delay any amount based on the command. Maybe something is needed here from OpnePNP to send the command to the Mega inline with the motion commands sent to smoothie board.

then it would be a simple adjustment to the delay to get the trigger at the correct time for different machines

On Thu, Nov 13, 2025 at 11:37 PM simplemount via OpenPnP <ope...@googlegroups.com> wrote:

Nov 13, 2025, 23:00 by mike....@gmail.com:

To view this discussion visit https://groups.google.com/d/msgid/openpnp/a0f11e42-9c90-4687-89f5-65645f182d7dn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/Oe-diw7--N-9%40tuta.io.

Mike Menci

unread,

Nov 14, 2025, 6:55:31 AMNov 14

to ope...@googlegroups.com, ope...@googlegroups.com

Great approach, will try it this way and report back

iPhone magic

Dne 14. nov. 2025 ob 11:59 je oseba bert shivaan <bert.s...@gmail.com> zapisala:

To view this discussion visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNz30H9CjN%2B6Q8syja0nh8Ot%3D3pv710sX7jjBBCyEC5xog%40mail.gmail.com.

Mike Menci

unread,

Nov 14, 2025, 9:25:31 AMNov 14

to OpenPnP

Hi CNC ..
I did some testing with Mega and Smoothie and the Mega passthrough breaks OpenPnP's position tracking, causing the DRO to lose nozzle locations therfore, this approach can't work in production. We need solutions that maintain "position integrity within OpenPnP."

bert shivaan

unread,

Nov 14, 2025, 10:37:15 AMNov 14

to ope...@googlegroups.com

my last message was blocked, is this one?

To view this discussion visit https://groups.google.com/d/msgid/openpnp/c5152d50-d48b-4de3-84bc-dd35310d5c14n%40googlegroups.com.

bert shivaan

unread,

Nov 14, 2025, 10:38:35 AMNov 14

to ope...@googlegroups.com

let me try this again. It seems my message was blocked by Google. If it was not and this is redundant, please forgive.

In my understanding, it should not have any way to break the position. OpenPNP should send the move command to smoothie, then next send the trigger command to Mega.

Upon receiving the command, Mega should fire the camera whatever amount of time after it receives the command. Smoothie and openPNP would know nothing about it. Also It would not be able to break the DRO

Arthur Wolf

unread,

Nov 14, 2025, 11:51:35 AMNov 14

to ope...@googlegroups.com

On Fri, Nov 14, 2025 at 3:25 PM Mike Menci <mike....@gmail.com> wrote:

Hi CNC ..
I did some testing with Mega and Smoothie and the Mega passthrough breaks OpenPnP's position tracking,

You shouldn't need any kind of passthrough:

Set up a switch module in Smoothie to turn a pin on when it receives a certain M-code (M432 say).

Connect the pin from smoothie to the arduino mega.

Have the arduino mega monitor that pin, when it sees it go high, wait a certain time and then trigger its own pin to trigger the camera or whatever else.

Then in openpnp you make it so just before sending the long gcode that goes over the camera area (and making sure it's not in motion at that point, so maybe add something like a gcode to wait for a tenth of a second or something), it sends the trigger mcode M432.

That way what will happen in order is:

* OpenPNP sends a sleep/wait gcode to smoothie, smoothie comes to a complete halt, no motion is happening, this is a reproducible state.

* OpenPNP sends the M432 mcode to smoothie, smoothie turns on a pin (immediately since the movement queue is empty), arduino mega sees the pin go high, starts its timer.

* OpenPNP sends the long movement Gcode to smoothie, smoothie starts moving

* At some point in the long move, the timer on the mega runs out and it triggers the camera. At this point, this should be **extremely** reproducible, it should always be exactly the same point, and you should be able to to tune the position by adjusting the timing.

I think this is a pretty good plan for a proof of concept, as long as you have the ability to get OpenPNP to send two g/m-codes before the long G0 move that goes in front of the camera, I don't know openpnp enough to know if this is possible.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/c5152d50-d48b-4de3-84bc-dd35310d5c14n%40googlegroups.com.

--

勇気とユーモア

Mike Menci

unread,

Nov 14, 2025, 12:45:28 PMNov 14

to OpenPnP

BINGO :-) Arthur --- This way it should work ! Let me start testng !

Mike Menci

unread,

Nov 15, 2025, 2:49:24 PMNov 15

to OpenPnP

Open PnPGcode console is for emergency use only, DRO does not update head/nozzle position therefore use is useless ...

Jan

unread,

Nov 15, 2025, 3:24:06 PMNov 15

to ope...@googlegroups.com

Hi Mike!
IIRC the result of M114 (GET_POSITION_COMMAND) ins always evalculated
internally by the driver. So this shall very likely update the DRO and
all other related internallys, if issued from the console.

Jan

>> msgid/ <https://groups.google.com/d/
>> msgid/>
>> > openpnp/fda50ef1-c0d5-40b3-
>> b952-faf6eb77adc8%40googlemail.com
>> <http://40googlemail.com>
>> > <https://groups.google.com/
>> d/msgid/openpnp/fda50ef1-c0d5-40b3-
>> <https://groups.google.com/d/msgid/
>> openpnp/fda50ef1-c0d5-40b3->
>> > b952-
>> faf6eb77adc8%40googlemail.com
>> <http://40googlemail.com>>.

>> >
>> >
>> >
>> > --
>> >
>> > 勇気とユーモア
>> >
>> > --
>> > You received this message because
>> you are subscribed to the Google
>> > Groups "OpenPnP" group.
>> > To unsubscribe from this group and
>> stop receiving emails from it, send
>> > an email to
>> openpnp+u...@googlegroups.com
>> > <mailto:openpnp+u...@googlegroups.com>.
>> > To view this discussion visit
>> https://groups.google.com/d/msgid/

>> <https://groups.google.com/d/msgid/>
>> >
>> openpnp/3ac26afc-34fa-4cde-957c-95f223b5da6en%40googlegroups.com <http://40googlegroups.com>
>> > <https://groups.google.com/d/msgid/
>> <https://groups.google.com/d/msgid/>
>> >
>> openpnp/3ac26afc-34fa-4cde-957c-95f223b5da6en%40googlegroups.com <http://40googlegroups.com>?

>> > utm_medium=email&utm_source=footer>.
>>
>> --
>> You received this message because you
>> are subscribed to the Google Groups
>> "OpenPnP" group.
>> To unsubscribe from this group and
>> stop receiving emails from it, send an
>> email to openpnp+u...@googlegroups.com.
>>
>> To view this discussion visit https://
>> groups.google.com/d/msgid/openpnp/
>> d794eebe-b9f1-4d26-
>> b30d-50603b96d3e1%40googlemail.com

>> <https://groups.google.com/d/msgid/
>> openpnp/d794eebe-b9f1-4d26-
>> b30d-50603b96d3e1%40googlemail.com>.

>>
>> --
>> You received this message because you are
>> subscribed to the Google Groups "OpenPnP" group.
>> To unsubscribe from this group and stop
>> receiving emails from it, send an email to
>> openpnp+u...@googlegroups.com.
>> To view this discussion visit https://
>> groups.google.com/d/msgid/openpnp/

>> a0f11e42-9c90-4687-89f5-65645f182d7dn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/a0f11e42-9c90-4687-89f5-65645f182d7dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>
>> --
>> You received this message because you are
>> subscribed to the Google Groups "OpenPnP" group.
>> To unsubscribe from this group and stop receiving
>> emails from it, send an email to
>> openpnp+u...@googlegroups.com.
>> To view this discussion visit https://

>> groups.google.com/d/msgid/openpnp/Oe-diw7--
>> N-9%40tuta.io <https://groups.google.com/d/msgid/
>> openpnp/Oe-diw7--N-9%40tuta.io?

>> utm_medium=email&utm_source=footer>.
>>
>> --
>> You received this message because you are subscribed
>> to the Google Groups "OpenPnP" group.
>> To unsubscribe from this group and stop receiving
>> emails from it, send an email to
>> openpnp+u...@googlegroups.com.
>> To view this discussion visit https://
>> groups.google.com/d/msgid/openpnp/

>> CA%2BKNHNz30H9CjN%2B6Q8syja0nh8Ot%3D3pv710sX7jjBBCyEC5xog%40mail.gmail.com <https://groups.google.com/d/msgid/openpnp/CA%2BKNHNz30H9CjN%2B6Q8syja0nh8Ot%3D3pv710sX7jjBBCyEC5xog%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the
> Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to openpnp+u...@googlegroups.com.
>
> To view this discussion visit https://groups.google.com/d/

> msgid/openpnp/c5152d50-d48b-4de3-84bc-
> dd35310d5c14n%40googlegroups.com <https://groups.google.com/
> d/msgid/openpnp/c5152d50-d48b-4de3-84bc-
> dd35310d5c14n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

>
>
>
> --
>
> 勇気とユーモア
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/0b9885eb-535f-43ef-a721-4404998ce4fdn%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/0b9885eb-535f-43ef-
> a721-4404998ce4fdn%40googlegroups.com?utm_medium=email&utm_source=footer>.

Mike Menci

unread,

Nov 21, 2025, 2:23:55 PMNov 21

to OpenPnP

Updated Summary for OpenPnP Group:

I conducted extensive ELP camera testing and achieved maximum performance optimization for vision capture. Here are my key findings:

Performance Breakthrough Achieved:
Through rigorous optimization, I reduced 7-position calibration from 3.35 seconds to 2.56 seconds - a 24% performance improvement. This represents the absolute hardware limits of OpenPnP's architecture.

What Doesn't Work - True Fly-Over:
OpenPnP's moveTo() command always includes M400 wait for completion, blocking script execution until movement finishes. This makes true motion capture impossible through scripts. Every capture happens AFTER movement completes, regardless of timing attempts.

What Works Excellently - Optimized Micro-Stop Capture:
My optimized approach achieves:

7-position calibration: 2.56 seconds
Single nozzle setup: 2.9 seconds
Full multi-nozzle setup: 29.2 seconds
Average per position: 365ms

Key Optimizations That Worked:

Removed settle moves (saved 130ms per position)
Reduced micro-stop time to 15ms
Direct movements only, no intermediate positions
Maximum speed settings (hardware limits)

Hardware Limits Reached:

Movement time: ~280ms per 10mm move (cannot be faster)
Camera capture: ~30ms (hardware limit)
Micro-stop: 15ms (minimum for stability)
OpenPnP architecture prevents real-time position updates

Production Impact:
The 2.9-second nozzle calibration enables true production-line speeds. Full machine calibration in under 30 seconds makes this approach production-ready, though it requires working within OpenPnP's architectural constraints rather than true fly-over capture.

Test Setup: OpenPnP /Windows with Dedicated camera testing jig with fixed nozzle height, Yaskawa servo X-axis with encoder, and Nema 17 Y-axis - specifically designed for camera qualification, not full PnP operation.