Pick Retry Sequencing

[Toby Dickenson]

Hi all

I am looking into a behaviour that seems to me to be a simple bug. But, before I fix it, I am looking for reassurance from long-time users that I am not breaking something subtle.

The problem relates to the sequencing of pick retries. A post-pick vacuum check allows the nozzle to have a second (or more) dip down to pick up a part, if it didnt stick to the nozzle on the first attempt. I have definitely seen this working well in practice; the nozzle dips back down to the pick position and it can very often be successful at picking the part on the second attempt.

But I have also seen it go wrong, because the vacuum pump is running for the whole time. This means the part jumps onto the nozzle. For small parts this can often cause an edge pick, or even an upside-down pick.

The solution seems obvious; turn off the vacuum pump before descending for a retry pick, and turn it back on only after the nozzle tip is in contact with the part. Can anyone think of a reason to not do that?

Toby

https://github.com/openpnp/openpnp/issues/1894

[vespaman]

Hi Toby, 

Interesting find!  I guess when you write "pump", it means vacuum (-valve on most machines)? There may be something on another tip, so the pump mustn't be switched off.

I can't testify that I have had this problem, but possibly I have, without knowing it.

 -  Micael

[Jan]

Hi Toby!
Interesting finding! I'd guess you could debug it by forcing a bad pick
position.
I agree with You and Micael, that the valve shall be closed when retry
starts to avoid sucking components up. (There might even be a dwell time
needed to make sure there is no "wind" anymore before going down.
There are two more concerns to me:
1) I was not aware, that pick retry due to vacuum part on detection
skips feeding a new part. IMHO that should be done. (Imagine the case
where two 0402s are feed at once and the second gets kicked out while
picking the first. With what you described, pick retry would fail over
and over again.)
2) If pick try just goes down again, I don't see a good reason why it
shall succeed, making the entire process "useless". I see multiple
reasons why picking might fail:
- part not ready
- Z to height
- dwell time to short
- nozzle tip damaged
- part-on-sensing configured insufficiently
Just going down does not cover any of them, feeding a new part at least
some...
If the goal is to keep the machine active, the user needs to be
informed, that there is an issue he has to investigate. Then a retry
cycle might feed a new part, go lower by eg. 0.1mm and increase dwell
time by eg. doubling. This shall provide a good opportunity to succeed.

Jan

> https://github.com/openpnp/openpnp/issues/1894 <https://github.com/
> openpnp/openpnp/issues/1894>
>
>
> --
> 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/
> CAH35urecxZPoMLiPDFyLX03fTbnTNBtfKdEJn_yNOWPEAaV4Jw%40mail.gmail.com
> <https://groups.google.com/d/msgid/openpnp/
> CAH35urecxZPoMLiPDFyLX03fTbnTNBtfKdEJn_yNOWPEAaV4Jw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Toby Dickenson]

On Tue, 23 Sept 2025 at 10:44, 'Jan' via OpenPnP <ope...@googlegroups.com> wrote:

Hi Toby!
        Interesting finding! I'd guess you could debug it by forcing a bad pick
position.

I have been doing that today, and have found a problem with my suggestion.

Suppose there is a false negative result from the vacuum test. The nozzle thinks it failed to pick the part, but actually it succeeded. The current retry implementation causes the nozzle to dip back down while carrying the part, and maybe the next vacuum check will see that the part is present. But my proposed "fix" causes the part to get tossed in the air if it turns the vacuum off (vacuum valve, not pump!) before descending again.

All of these are marginal cases that occur very infrequently in practice of course.

 

1) I was not aware, that pick retry due to vacuum part on detection
skips feeding a new part. IMHO that should be done.

Openpnp has always had **both** types of retry. This is the difference between "pick retry count" in the part configuration, and "pick retry count" in the feeder configuration.

I have recently added this wiki page to explain how the existing retry loops stack up: https://github.com/openpnp/openpnp/wiki/Retries

Then a retry
cycle might feed a new part, go lower by eg. 0.1mm and increase dwell
time by eg. doubling. This shall provide a good opportunity to succeed.

Thats a great idea!! I shall add this to my tests.

[Jan]

Hi Toby!

On 23.09.2025 12:58, Toby Dickenson wrote:
> On Tue, 23 Sept 2025 at 10:44, 'Jan' via OpenPnP

> <ope...@googlegroups.com <mailto:ope...@googlegroups.com>> wrote:
>
> Hi Toby!
>         Interesting finding! I'd guess you could debug it by
> forcing a bad pick
> position.
>
>
> I have been doing that today, and have found a problem with my suggestion.
>
> Suppose there is a false negative result from the vacuum test. The
> nozzle thinks it failed to pick the part, but actually it succeeded. The
> current retry implementation causes the nozzle to dip back down while
> carrying the part, and maybe the next vacuum check will see that the
> part is present. But my proposed "fix" causes the part to get tossed in
> the air if it turns the vacuum off (vacuum valve, not pump!) before
> descending again.
>
> All of these are marginal cases that occur very infrequently in practice
> of course.
>

Hm... that's a good catch too! I suppose that a false positive even with
todays implementation (keep vacuum active, just go down to pick
location) will result in new issues as there is a good chance to push
the part off when going down to the pick location again.
To overcome that, a discard cycle seems mandatory...

> 1) I was not aware, that pick retry due to vacuum part on detection
> skips feeding a new part. IMHO that should be done.
>
>
> Openpnp has always had **both** types of retry. This is the difference
> between "pick retry count" in the part configuration, and "pick retry
> count" in the feeder configuration.
>

I remember that you talked about two different "pick retry count"
values/settings. Now I understand what you mean. So, what's actually
happening in the job processor and which of them is triggered? I assume,
that after picking a part, a single vacuum part on detection is used to
"retry". And which is it?

> I have recently added this wiki page to explain how the existing retry
> loops stack up: https://github.com/openpnp/openpnp/wiki/Retries

> <https://github.com/openpnp/openpnp/wiki/Retries>
>
Do I understand the wiki correctly, that vacuum part on detection is
used to check if part has been picked. If not the nozzle goes down again
trying to pick it once more (your initial question of this thread). If
there is finally no part on the nozzle, the entire process of feeding
and picking is retried according to the part-retry-counter?

> Then a retry
> cycle might feed a new part, go lower by eg. 0.1mm and increase dwell
> time by eg. doubling. This shall provide a good opportunity to succeed.
>
>
> Thats a great idea!! I shall add this to my tests.
>

Seems, there are lot of errors and false-positives to consider.
Hopefully we'll catch them all until you spend your time improving the
current situation...

Jan

[bert shivaan]

In the past I have pointed out how my old commercial machine worked. Before I do I want to give the setup of it :

2 heads each containing 6 "pneumatic" nozzles and 1 electronic nozzle.

 the difference is the 6 all rotated together on a rack and pinion with no encoder feedback. the other had a high res encoder on it with its own rotate motor.

It was intended for high precision bigger parts I think. I never used it.

The 6 worked great down to 0402. Only nozzle 1 on each head had a vac sensor. This was only used to get the height of things.

So in a typical cycle, the head would go grab up to 6 parts,

fly over the camera looking at all 6 parts 1 at a time,

any that were "bad" were discarded in the trash bin that was right after the camera. Bad was anything that was not correct. ie missing, tombstoned, bent pins etc.

that was counted as a mis pick for that feeder. on the next cycle it would attempt to get it again. 

Once this happen 3 times (amount was adjustable by user) the feeder was declared empty and not used again until the operator refilled it. It should be noted if the head picked 3 parts from the same feeder, and all three were bad, that was all 3 tries and feeder was marked empty.

So, the moral to the story is for me, everything is solved at the camera. If there is a good part on the nozzle correctly, it is placed.

If not it is discarded and tried again on the next round.

Lots of folks here don't seem to like this method as it could mean trips from the feeder to the camera that are wasted trips. I can understand that if your machine is slow. 

Anyway, I would love to see this trial and declared empty situation implemented. Me and another user had it a long time ago (he coded it and I helped trouble shoot) but right after we did, Jason released REV 2, since it did not use the same state machine logic it was not as easy to do this and above our head from a coding perspective.

If anyone want to take this on, I am more than happy to help out. The result is a much more commercial style machine in operation. At the end of the job it also gave a report of what was not placed. In my commercial machine it also had placement priority, so if something was not placed, it would ask if it should go to the next priority of stop to fix the feeder.

--
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/875488ce-af87-42b4-8f05-7cdbae57e4bb%40googlemail.com.

[Toby Dickenson]

I have some good news for you Bert,

> that was counted as a mis pick for that feeder. on the next cycle it would attempt to get it again.
> Once this happen 3 times (amount was adjustable by user) the feeder was declared empty and not used again until the operator refilled it. It should be noted if the head picked 3 parts from the same feeder, and all three were bad, that was all 3 tries and feeder was marked empty.

That is exactly what I am currently implementing, and what has led me
to look closely at all the retry loops.
https://github.com/openpnp/openpnp/issues/1891
https://github.com/openpnp/openpnp/pull/1898

> So, the moral to the story is for me, everything is solved at the camera. If there is a good part on the nozzle correctly, it is placed.
> If not it is discarded and tried again on the next round.

You will be able to get that policy by setting all the other retries to zero.

> In my commercial machine it also had placement priority, so if something was not placed, it would ask if it should go to the next priority of stop to fix the feeder.

That sounds like the "rank" feature which is already merged in the test branch.

Jan wrote:
> To overcome that, a discard cycle seems mandatory

Yes. That happens if all the task-specific retries still raise an
exception (or the retry counters have been set to zero). The job
processor handles any and all the discards at the end of its
pick/align/place cycle. Then the new feature in PR 1898 will allow it
to retry that placement.

[bert shivaan]

It would be nice if we can discard after the bottom vision before placing - 

If the situation is such that a part is barley hanging on, the vision will see it as bad (maybe because it is wrong size), then it would be discarded before going over the PCB risking it falling randomly on the PCB.

Also, if the machine layout puts a trash bin next to the camera, it is always the least amount of travel to get to it.

--
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/CAH35urf_acEBwWGjf1ozpjy71BYLAa7ZaHi-g-YfsEa%3Dw%3D9QEw%40mail.gmail.com.

[Toby Dickenson]

On Tue, 23 Sept 2025 at 15:56, bert shivaan <bert.s...@gmail.com> wrote:
>
> It would be nice if we can discard after the bottom vision before placing -
> If the situation is such that a part is barley hanging on, the vision will see it as bad (maybe because it is wrong size), then it would be discarded before going over the PCB risking it falling randomly on the PCB.

Discarding the bad before placing the good does make so much sense.

Are there any cases where the current process (placing the good before
discarding the bad) would be preferred? Does this need to be an
option?

[bert shivaan]

option would be nice, I can imagine at least somebody designed their build with the trash in a place not as convenient as next to the camera. 

Bonus points if we can assign different trash for different components. Like so all my passives just get trashed, but the good stuff is in a different bin for picking through and saving.

--
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/CAH35urdUAXimJtDJgTxnQ%2BkA18eTrzv4VycCGJf2TFy8wfV5rw%40mail.gmail.com.

[Toby Dickenson]

Yes, and I'm sure there are machines where a trip over to the discard bin could introduce some risk of nudging and misaligning the good parts on the other nozzles. An option makes sense.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNyGq0%2BAJKmkd4612nzd7bMUDa0usYKgiWOi1qUaTu0Gyw%40mail.gmail.com.