components data
Ben
mark maker
Usually, such data is only imported together with the placements,
i.e. only for those parts/packages that you actually require in a
project.
OpenPnP only has flat lists for parts and packages, so I believe it would be too much to import whole libraries.
To my knowledge, only Eagle has an import that also automatically
imports the footprints. For KiCAD there is a single footprint
import button.
_Mark
is there a way to import components / footprint data from PADS / ALTIUM files that I have in my library?
--
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/183a57c1-4f21-4e0a-bc03-645a925fe94cn%40googlegroups.com.
Ben
mark maker
It is usually the other way around. The ECAD has some format and you then write an importer for OpenPnP.
https://github.com/openpnp/openpnp/tree/develop/src/main/java/org/openpnp/gui/importer
Most placement export formats are simple CSV files.
But footprint data is usually more complex and you would probably have to go into the specifics of the ECAD.
Don't overestimate the usefulness of such a footprint import.
- Footprints are per package, so even if you have hundreds of
different resistor and capacitor values, they usually just have
a handful common packages.
- Footprints are not required by OpenPnP. Aside from GUI
cosmetics, they only have two functions:
- Support the size check, i.e. whether the part has the expected size in Alignment / bottom vision.
- Support Vision Compositing, a.k.a. multi-shot bottom vision for parts larger than your camera view (or other difficult parts).
These functions are not routinely a "must". OpenPnP works well without them.
- Therefore, the few footprints you really need, are easily generated inside OpenPnP. Watch the video scene.
- The next project will reuse the same packages/footprints
automatically.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/770761e1-297e-4041-a09a-5839f326d5e3n%40googlegroups.com.
Ben
mark maker
I'm by no means "expert in all things ECAD". Keep that in mind.
What I know so far is that all the (valid) placement data (what you call XY file), that I ever saw so far (with one exotic exception, see at the end) is always visually centered, with regard to the bounding box of its contacts, as seen from below. This allways assumes that the contacts are the visually brightest elements, that can then be isolated in bottom vision, and their minimal area bounding box, so-called MinAreaRect then be used for alignment.
This in turn means that all parts/packages/footprints in the ECAD must be designed to have this visual center as their drawing center too. Or at least there must be means inside the ECAD to make it so, when placement coordinates are exported.Note: With the bounding box there is no need for it to be symmetric, its just the bounds that count. So you DPAK can have a clunky contact on one side and two flimsy legs on the other. No problem, just make sure that the outer bounds/edges of your unequal pads go equally far on both sides, from the center:
Furthermore, the same center is also (almost) always the pick center. So the parts must be inside their tape pocket/feeder position in a way that makes it so.
Not surprisingly manufacturers make sure that all their parts are centered like that, both their overall physical body (if protruding) as aligned in their tape pocket, and the contacts on the package, are centered. Certainly this is also true for a DPAK.
If it is not so in your ECAD, then you should probably fix it
there. I see no valid reason, why it should not be like that. But
as I said in the beginning, I'm not the super expert there, so
some ECADs might have different principles. But then I'm sure they
have a way to compute and export the visual center for the XY
file.
OpenPnP has center offsets for vision alignment, that you can enter, but I strongly advise against using them. The only part that I ever saw that requires such treatment, was am "ESP32 something" mini PCB, that is completely asymmetric and even had white markings on the underside, so normal vision failed. Astonishingly stupid engineering.
But OpenPnP can do it, if you have a color shade and color
camera. This hairy story is here:
https://groups.google.com/g/openpnp/c/ucHeolNaPuk/m/U_ZyUA_kAwAJ
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/fac0dbbb-df47-41bc-8e83-ad731c99481dn%40googlegroups.com.
Jan
Many right angle connectors and buttons are troublesome as well as they
are asymmetric by nature. In the ECAD I prefer to have the reference
point at the PCB edge for easy precise placement. Obviously this
location is not good as Pick&Place data because it does neither
correspond to the rotation center nor to the location where the part can
be picked. Some ECAD software allows to specify an additional dedicated
pick location that's used for Pick&Place data generation. I think its
good practice to use the pick location as reference point when creating
parts in ECAD and output this as Pick&Place data.
Bottom vision within OpenPnP is then an other story: at present all
practical pipelines I've seen, detect some bounding rectangular and
return its center and rotation. For asymmetric parts an offset might be
required to join this center and the pick location. (Professional PnPs
use pattern matching only so they just setup an asymmetric pattern as
required.)
If you can have the location you output to Pick&Place data in the
visual center (usually the shiny part) and use this location as pick
location, its all very simple. If not, you'll have to play with the
vision offset. IIRC that's not that simple, but once setup, works well.
I recommend to provide footprint data for (at least) this package
because that's simplifies the visual inspection and orientation.
Jan
On 02.11.2023 12:25, 'mark maker' via OpenPnP wrote:
> I'm by no means "expert in all things ECAD". Keep that in mind.
>
> What I know so far is that all the (valid) placement data (what you call
> XY file), that I ever saw so far (with one exotic exception, see at the
> end) is always visually centered, with regard to the bounding box of its
> contacts, as seen from below. This allways assumes that the contacts are
> the visually brightest elements, that can then be isolated in bottom
> vision, and their minimal area bounding box, so-called MinAreaRect then
> be used for alignment.
>
> This in turn means that all parts/packages/footprints in the ECAD must
> be designed to have this visual center as their drawing center too. Or
> at least there must be means inside the ECAD to make it so, when
> placement coordinates are exported.
>
> Note: With the bounding box there is no need for it to be symmetric, its
>
>> have a handful common packages.
>> - Support the size check, i.e. whether the part has the
>> expected size in Alignment / bottom vision.
>> - Support Vision Compositing, a.k.a. multi-shot bottom vision
>> These functions are not routinely a "must". OpenPnP works well
>> without them.
>> 4. The next project will reuse the same packages/footprints
>>> --
>>> 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
>> --
>> 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
> --
> 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
Roland Exler
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c2fd8580-46fe-4618-89d0-4ab9371fe648%40makr.zone.
mark maker
Just FYI.
OpenPnP supports vision offsets, which then act as placement offsets, but only if you actually enable bottom vision (which is bad).
OpenPnP does not support pick offsets. Some feeders allow setting arbitrary pick locations, others relate to the tape (sprocket holes) and EIA481 geometry, and only allow pocket-centered picks.
The confusion about all this is one of the reason I don't recommend using the vision offsets.
Another is that the vision offsets are only applied after doing vision, not when initially holding the part over the camera. So assuming the part contacts are really asymmetric, it causes large initial correction moves that are slow and require more iterative vision passes, or can even fail when offsets are so large that parts are masked.
Finally, when you set vision offsets by mistake, or forget you
have them but fixed the reason for them in the meantime, it can
become extremely frustrating to find why you suddenly have offsets
in placements.
Of course we could fix all that, PRs are welcome! 🤑
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAA9D9gFkyD5qYt-t5ztqwmRwhPj%3D-ubvSCKtFu4XnhDkHQk1qQ%40mail.gmail.com.
Ben
Wayne Black
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/facd0ee0-65fa-4cc9-9498-2f9a4a06342e%40makr.zone.
Ben
Jan
Many thanks for the explanation!
If I understand you correctly, adding a pick offset feature would be
one thing. However, I assume there are many location this would have to
be factored in and in fact would only compensates, that some feeders do
not support arbitrary pick locations.
The vision offset is already available but maybe not yet intuitively
usable. To my limited understanding if it would be applied before bottom
vision everything should be find as with symmetric parts. Ok, rotation
errors would have to be translated into position errors as well because
the center of rotation is shifted. Anything else?
Jan
On 02.11.2023 15:35, 'mark maker' via OpenPnP wrote:
> Just FYI.
>
> offsets*, but /only/ if you actually enable bottom vision (which is bad).
>
> OpenPnP does *not* support *pick offsets*. Some feeders allow setting
> EIA481 geometry, and only allow pocket-centered picks.
>
> The confusion about all this is one of the reason I don't recommend
> using the vision offsets.
>
>>
>>> just have a handful common packages.
>>> - Support the size check, i.e. whether the part has the
>>> expected size in Alignment / bottom vision.
>>> - Support Vision Compositing, a.k.a. multi-shot bottom
>>> vision
>>> well without them.
>>> easily generated inside OpenPnP. Watch the video scene
>>> <https://youtu.be/P-ZudS7QQeE?feature=shared&t=486>.
>>>> --
>>>> 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
>>> --
>>> 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
>> 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
>> --
>> 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
> --
> 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
mark maker
We have the following scenarios, just to name those that I now
got:
(when I say "placement data" I mean what was imported from the ECAD / "XY-file". Offsets are always applied with the proper part rotation at the location in question)
- The part's contacts are symmetric in relation to how the part
is centered in the feeder, but the placement data (ECAD
footprint center) is off from the actual part center. The edge
connector being an example. We already have "Vision offsets".
Would be better named "Placement offsets", or even "Footprint
offsets" (in fact it would be implied by asymmetric pads).
Applied in placement only. But not yet
implemented, when bottom vision is disabled.
- The part's contacts are symmetric in relation to how the part
is centered in the feeder, but the feeder introduces a
systematic error, i.e. somehow the parts are always picked a bit
off-center, and we wish to trim that. We would need "Feeder
offsets" on the feeder. Applied in pick only.
- The part's contacts are symmetric in relation to how the part
is centered in the feeder, but the part is best picked at a
non-centric location, because the body (upper side) is
asymmetric. DPAK being an example. We would need "Pick offsets"
on the footprint. Applied in pick, and negatively
applied in alignment xor placement, meaning that the
negative Pick Offsets are the starting offsets for alignment,
refined by bottom vision, and carried over to placement; if
bottom vision is disabled, they are just taken for placement.
- The part's contacts are asymmetric in relation to how the part
is centered in the feeder. But the placement data relates to the
feeder centered location. We would need "Alignment offsets" on
the footprint. Applied in alignment only, as offsets for how the
part is to be held over the camera.
- All combinations of the above.
_Mark
Ben
mark maker
Hi Ben,
first, just to be strict, it is not the center of gravity of the contacts or of the part outline, but the center of the bounding rectangle. It is easy to see how it makes a difference for e.g. a SOT23, where the number of pins on each side are different and the outline is actually more of a triangle. You need to surround it with the bounding box to get the true center.
Feeder trays and other feeder types typically have tight pockets, so parts have little wiggle room, so they can be picked blindly from calculated grid coordinates. Some feeders have vision on sprocket holes or fiducials on the feeder (or feeder array) to calibrate the exact position.
Maybe have a look at the BlindsFeeder, or watch the video:
https://github.com/openpnp/openpnp/wiki/BlindsFeeder
https://youtu.be/dGde59Iv6eY
If you're still not convinced that the feeder should align the
part physically, have a look at the AdvancedLoosePartFeeder, it
does what you describe, even for loosely placed parts:
https://github.com/openpnp/openpnp/wiki/AdvancedLoosePartFeeder
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9108ee8b-681d-494b-9525-43bccd207b81n%40googlegroups.com.
Ben
