New Basic Footprint Generator

[ma...@makr.zone]

Hi all,

there is a new basic footprint generator for packages in the OpenPnP testing version:

Details in the Pull Request Instruction for Use:

https://github.com/openpnp/openpnp/pull/1436

Download:

https://openpnp.org/test-downloads/

Footprints will be required in upcoming features.

_Mark

[Shai]

Hi Mark, just curious, what's the benefit of having footprints of components? Easier to find the proper center of component? Is that the goal with this?

[mark maker]

Hi Shai,

It can have several purposes:

1. Give the size of the part to parametrize bottom vision Pipelines (masks and search ranges for certain stages).
2. Give the size of the part to parametrize the Size Check, as an alternative/complement to the (sometimes difficult) vacuum check.
3. Support the upcoming Multi-Shot bottom vision, when the camera view is not large enough to "see" a very large package. The footprint is needed to interpret the partial view of a package. That is work in progress.
   

Note 1: despite all of the above, it is still optional.

Note 2: some E-CADs can import the footprint (although this actually gives you solder lands i.e. not necessarily 100% the same as the vision footprint). See this recent Pull Request by  qwertymodo:
https://github.com/openpnp/openpnp/pull/1422

_Mark

--
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 on the web visit https://groups.google.com/d/msgid/openpnp/600edaea-1665-4b1e-b990-00cf7ea13840n%40googlegroups.com.

[Jan]

Hi Mark!
Thats really cool! May I ask for two things:
1) would you please add the letters, that are commonly used in
datasheets, to the dimensions your generator is expecting like 'D' for
Body Width or 'e' for Pad Pitch? And/or could you add a scatch that
indicates where the dimensions are taken from?
2) would you please add an indication for pin 1 so that the footprint,
thats overlayed when viewing feeder and/or place locations using the
down looking camera, can be used to validate the orientations?
May I ask again for a pipeline suggestions to use the footprint
information for bottom vision?
Thank You!

Jan

On 03.07.2022 23:16, ma...@makr.zone wrote:
> Hi all,
>
> there is a new basic footprint generator for packages in the OpenPnP
> testing version:
>

> Screenshot_20220703_224031.png
>
> Details in the Pull Request *Instruction for Use*:
> https://github.com/openpnp/openpnp/pull/1436
> <https://github.com/openpnp/openpnp/pull/1436>
>
> Download:
> https://openpnp.org/test-downloads/ <https://openpnp.org/test-downloads/>

>
> Footprints will be required in upcoming features.
>
> _Mark
>

> --
> 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 on the web visit

> https://groups.google.com/d/msgid/openpnp/7ef33a67-cb67-434c-9974-f828bb60ca0en%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/7ef33a67-cb67-434c-9974-f828bb60ca0en%40googlegroups.com?utm_medium=email&utm_source=footer>.

[mark maker]

Hi Jan,

Re 1:

I was always under the impression that these letters were different from manufacturer to manufacturer (or worse). If they are used inconsistently, then using them in OpenPnP could even be more confusing.

Or can you provide standardization documentation?

Re 2:

I'll have a look. It would have to be configurable, because I noticed that there are footprints (even in the default OpenPnP Packages)  where pads are not ordered right. Indicating pin/pad1 wrongly would again be worse than not indicating at all.

Re pipeline:

This would require template image matching, and AFAIK this can only capture X/Y translation, not rotation in OpenCV.

https://docs.opencv.org/4.6.0/d4/dc6/tutorial_py_template_matching.html

To implement a template rotation + translation detection would probably be feasible by iteratively rotating the template and finding the peak match, but that's a formidable task in itself. Also probably quite computation intensive.

_Mark

[Jan]

Hi Mark!

> Re 1:
>
> I was always under the impression that these letters were different from
> manufacturer to manufacturer (or worse). If they are used

> inconsistently, then using them in OpenPnP could even be /more/ confusing.

>
> Or can you provide standardization documentation?
>

Unfortunately I can't. I've checked some datasheets and found that On is
referring to ANSI Y14.5M. They use the same letters as ST while TI is
not using any letters... Anyhow, I've just seen, that you added tool
tips, which is probably good enough for a tool, thats just used every
now and then.
Would you do us an other favor, please: provide a way to delete
multiple or all pads at once. (To test your generator, I create a 100pin
tfp with just few clicks - very nice - but now I can't delete it. I've
to select a pad, press delete and then confirm. The workaround I just
found is to generate a footprint with "Pad Count" = 0.)

> Re 2:
>
> I'll have a look. It would have to be configurable, because I noticed
> that there are footprints (even in the default OpenPnP Packages)  where
> pads are not ordered right. Indicating pin/pad1 wrongly would again be
> worse than not indicating at all.
>

Interesting, I did not noticed, that OpenPnp come with default packages.
They probably got lost while importing someone else's machine.xml.
I would really like to have this option to verify the part rotation. For
passives it's so easy to see, if a feeder is setup correctly. For
squared or polarized parts, I have to make a test place...
I understand the pad numbering can be difficult. How a about adding a
'*' to the pad name that shall be highlighted.

> Re pipeline:
>
> This would require template image matching, and AFAIK this can only

> capture X/Y translation, *not rotation* in OpenCV.
>
> https://docs.opencv.org/4.6.0/d4/dc6/tutorial_py_template_matching.html
>
> To implement a template *rotation + translation* detection would

> probably be feasible by iteratively rotating the template and finding
> the peak match, but that's a formidable task in itself. Also probably
> quite computation intensive.
>

Ah. That's very interesting. I haven't heart that before. But it makes
totally sense now, that nobody is talking about footprint matching if
the default method does not provide rotation information.
I've just done a short search on pattern matching with rotation and it
looks like a hot topic. Someone made this implementation
https://github.com/DennisLiu1993/Fastest_Image_Pattern_Matching and
posted some test images which look quite promising. Do you think
something like that could be added to OpenPnp?
I just recently talked to someone operating a few NXTs and he told me,
that their vision is quite picky. They have to train it again if the
mold color changes slightly. That sounds like pure pattern matching. He
also mentioned, that it's expert work...

Jan

> https://groups.google.com/d/msgid/openpnp/7e2a3871-b71b-5285-7a05-7b7643c6e011%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/7e2a3871-b71b-5285-7a05-7b7643c6e011%40makr.zone?utm_medium=email&utm_source=footer>.