Autofeeder, feed-move-pick sequence

[Henrik Olsson]

Hi guys,

I'm starting to setup my feeders. They are FUJI KG type dual lane feeders for which I've designed a replacement PCB. They are on a RS485-bus on a separate G-code driver in OpenPnP. The ActuateDouble command is used to send M2000 P{IntegerValue} out on the bus, where the IntegerValue is the Index setup on the feeder. So far everything seems to work fine.

My question relates to the 'ok' response that I've programmed the feeders to respond with. I can set them to respond when the command is received OR when the feed is complete.

During testing (using the 'Perform feed and pick' operation followed by the Discard button) neither of these options seems optimal.

If the feeder responds with 'ok' on reception of command it sometimes happens that the component is not presented at the pick location when the nozzle 'hits it'. If set to respond with 'ok' on completion of operation the machine does not start moving TOWARDS the pick location until feeder responds.

Is this sequence of events different when actually running a job? Ie OpenPnP sends the feed command, then moves X&Y to pick location and only THEN waits if it hasn't received 'ok' from the feeder?

Would switching the feeder driver to the Async GCodeDriver make it any different?

I could also set a fixed delay before sending the 'ok' response but it isn't really optimal either.

Any insights?

Thanks!

   /Henrik.

[JW]

The two options you describe are correct for the standard g-code driver (not sure about the async driver).

However, why would you not want to wait until the feed is complete before moving the nozzle down to pick? Yes there is a slight optimisation to be had in moving in Z whilst the pick is in procedure, but for it to be robust you'd need full closed-loop control of feeder feed state progress and real time nozzle position feedback, something that I don't see you can reliably do with functions split between OpenPnP, the motion controller and your feeder controller.

I use 96 Yamaha CL feeders, and my feeder control board has a set wait time for the shutter to open before it returns ok/error. They only need around 20ms or so (except for the big 16/24mm feeders), so the OS latency of processing the incoming serial stream actually dominates.

Edit: I just re-read your post and realised I mis-read the whole thing, you just need to tick "move before feed" in the feeder setup. The nozzle will then move to the XY pick location, command a feed, wait for feeder controller to return ok, then move down in Z.

[Henrik Olsson]

Yeah, nah, you misread it the first time :-)

I DO want to wait for the feed to complete before moving Z down - that's the point. I just don't ALSO want to wait moving X and Y - which is what it does now IF I set the feeder to 'ok' on completion. If I set the feeder to 'ok' on reception it SOMETIMES doesn't complete the feed when the nozzle hits it.

Thanks for the "move before feed" I'll try that!

But if it does indeed move TO the feeder and THEN command a feed it's really not how I imagined it either.

When it's time to pick up a part I would imagine it to:

Command the feed then start moving towards the pick location (at safe Z). Feeder does its job and X/Y does theirs - at the same time.

If the feeder 'ok' arrives en-route (which in my case it would do ~95% of the time) you continue with the pick-operation. But if the feeder is slow and/or the distance to travel is short you might arrive at the pick location (still at safe Z) before the feed is complete - only THEN do you have to wait for the feeder to 'ok'.

This is somewhat academic at the moment, the machine isn't up and running but it's getting close and I'm trying to understand how the various things works in order to not paint myself into a corner. 

Again, I'll try the 'move before feed' setting and see what it does.

Thanks!

[Henrik Olsson]

Tried the 'move before feed' but no, that's not what I'm after.

It does indeed move X/Y to the pick location, then commands the feed, waits for 'ok' from feeder, then does the pick. In my case that's equivalent (time wise) to commanding the feed then wait for 'ok' from feeder, then move X/Y to the pick location and do the pick. Both ways looks like the machine is sort of hesitating :-)

20ms, that's crazy fast.

Mine are electric feeders. A stepper motor drives a cam mechanism that advances the tape and a DC-motor takes up the cover film. In my case (my PCB and my code) the whole process takes around 820ms. I don't know how fast they were originally. 'ok' is sent when the process is complete, perhaps I could change that to send it when the feed is complete but before the cover film takeup is complete, that might save 100ms or so.

[Toby Dickenson]

> It does indeed move X/Y to the pick location, then commands the feed, waits for 'ok' from feeder, then does the pick

"move before feed" is definitely what you want. I guess the only thing
wrong is the "machine coordination" setting on the actuator. openpnp
needs to know it is safe to send the "feed" command before the x/y
motion is complete.
https://github.com/openpnp/openpnp/wiki/Motion-Planner#actuator-machine-coordination

I am pretty sure you dont also need the async gcode driver, because
your feeders and motion are on a separate driver. But maybe you do.

> the machine is sort of hesitating :-)

You can fix that with the async driver, and enabling "continuous
motion" on the advanced motion controller. I found that eliminating
that stop/start hesitation gave a significant improvement to both
throughput and placement accuracy.

[Jan]

Hi Henrik!
What you're asking for is currently not supported by the feeder API. It
only provides a feed() method, that is expected to return when feeding
has finished. You can call it before or after the XY-move, but it will
always (by design) delays for the amount of time the feeding takes. (If
not feeding gets unreliable, as you have found out yourself then
replying OK to early.). You may search the archive and find that we
discussed proposals how to improve the feeder API. However, it needs
someone like you to implement, test and PR it.

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/
> dcd2cba2-7d38-4d6f-99dd-17f151453f2bn%40googlegroups.com <https://
> groups.google.com/d/msgid/openpnp/
> dcd2cba2-7d38-4d6f-99dd-17f151453f2bn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[Toby Dickenson]

Hi Jan,

I think this is working. See this discussion:
https://groups.google.com/g/openpnp/c/7EstsvVsCqU/m/iLI12e-kBgAJ

The discussion about extending the feeder API was in relation to
photon feeder, which is a bit different because its gcode driver is
often the same as that handling motion. And all of that discussion
came after feedback that the ReferenceAutoFeeder "Move Before Feed"
mechanism did not work in that case. But it turns out it does, and has
since been merged in PR 1843.

On Sun, 28 Sept 2025 at 22:33, 'Jan' via OpenPnP

> 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/a7bda767-8ade-4dde-a2a1-4e73927cfa42%40googlemail.com.

[Henrik Olsson]

Thank you guys. So it seems it might be possible if you get the all the settings correct. I'll play around with it a bit more.

In the meantime I sped up the the feeder so that it feeds in 320ms instead of >800 as it was originally. I might take my chances and 'ok' on reception and let vacuum sense and/or vision detect a missed feed. If the feeder detects an error it will not send 'ok' on the next feed so OpenPnP will/should see it then. 

Getting closer, one small step at a time.

Cheers!

[Jan]

Hi Toby!
If I understand the old discussions corectly, the mentioned setup was a
feeder controller modified to immediately respond ok on feed requests
(even if feed was not completed yet) and use a Z motion interlock to
generate a MOVE_TO_COMPLETE (usually M400) to the feeder controller to
delay until the feed sequence has finished before the nozzle goes down.
If the OP has controll over the feeder controller, he can likely copy
the setup.

Jan