add smt mounting hardware by wuerth

[poeschlr]

Script see: pointhi/kicad-footprint-generator#351

yaml file generated from product page tables. (every part has its own datasheet, but the datasheets of every series have equivalent dimensioned drawings in them. The product pages are the best to use for checking the part numbers vs height.)
https://katalog.we-online.com/en/em/browse/assembly/smd_spacer

I am not really sure about the naming convention (for both footprints and the library.) If anybody has a suggestion i am all for it.

3d model pull request: KiCad/kicad-packages3D#557

example screenshots

[poeschlr]

All scriptable versions are now part of this. The non npth version is not perfect as i use arc paste pads instead of a circle slice (The small improvement is not really worth the time required to implement it.)

[Shackmeister]

Hi Rene
Super glad you are making these, use them alot at work.

regarding naming, I was wondering if we could come up with a better library name.
In my personal library, I refer to these as either "SMD Standoff's" or "SMD Spacers", just for inspiration.

To the actual footprints:
all measurements I checked seems fine.

• description says "Wureth"

• couldn't some/alot of these be made with a through-hole, with only F.copper enabled? this way avoiding some of the complex pads.

• There is added some extra copper circles, is this due to thermal spokes or am I misunderstanding something?
  

[poeschlr]

The extra pads are on purpose such that there are connection snap points.

[Shackmeister]

alright in that case I think they are ready for merge as soon as the wureth is fixed

[poeschlr]

Typo fixed.

Regarding use of THT pads: sadly not an option as that would create a pad on the bottom side as well (and on inner layers)
Also the complexity mostly comes from the paste layout where i tried to follow wureth as best i can. (arcs with sharp corners are not really feasible. And i also think that rounded corners should behave better in production. At least this was the reasoning by IPC to switch to rounded rectangle pads)

[poeschlr]

@cpresser would you prepared to take a look at the script changes connected to this and also the footprints here? (Reason i ask is because i have the feeling you might be able to understand what i did in the script, mainly from your review of my ep round radius changes.)

[cpresser]

@cpresser would you prepared to take a look at the script changes connected to this and also the footprints here? (Reason i ask is because i have the feeling you might be able to understand what i did in the script, mainly from your review of my ep round radius changes.)

Can do. +3000 lines is quite a lot. But I will give it a try.

[Shackmeister]

Typo fixed.

Regarding use of THT pads: sadly not an option as that would create a pad on the bottom side as well (and on inner layers).

Wouldn't selecting "Copper: F.Cu" instead of "All Copper Layers" Fix this?
Otherwise I'm fine with merging these according to my review

[poeschlr]

I don't think it is a good idea to assign copper to a npth.

Using a pth will mean gerber export will place it in the drill file for plated holes -> fabs who use this fact to determine which holes to plate will now plate it.

This is why i think it is important to have an explicit npth hole plus an smd pad.

[Shackmeister]

I had another look, and I'm happy with merging. Any objections?

[Shackmeister]

Thanks!

[Shackmeister]

Hi @poeschlr
I have noticed the footprints gets sorted in a slightly weird manner in the footprint browser
eg:

I believe it can be fixed by adding a trailing zero (is that the right term?) to all the single digit heights.
When looking at KLC and other footprints, it doesn't look like there is a specific rule/pattern.

[Shackmeister]

added Mounting_Wuerth:Mounting_Wuerth_WA-SMSI-M2_H3mm_9774030243
in a board. I get a DRC error, due to the NPTH pad being too close to all the pad 1's.
Changing the NPTH pad to pin number 1 in a text editor, fixes the issue, I'm however not sure it's the appropriate fix

[poeschlr]

The sorting might be something where we want to make an issue for the devs.

I am not how your second complained could be solved. The reason this is made as a ring pad is to ensure that even cheap fabs make it unplated. It really does not matter if the non plated hole interferes with the ring pad as long as it is not plated.

[Shackmeister]

Hi @poeschlr

I can make an issue for the devs, adding the ".0" was just a suggestion (and would perhaps make the names look a bit more uniform) .

I agree it's not an issue per se, I just prefer not to have DRC errors in my boards. Especially since these footprints creates 4 errors each, it adds up quickly

[Shackmeister]

Adding a DRC check screenshot for reference.
Should I ask on the devs for support on the DRC issue?

[poeschlr]

The strange thing is that not all pads are reported.
Your workaround is also not possible right now as KiCad no longer allows non plated pads to have a pad number (opening the pad properties clears the number)

A true solution would be a separate DRC setting for the minimum distance between a non plated pad and any copper feature (including pads). This would allow users to encode manufacturing constrains.
The proposed virtual anchor pads would also help as these would allow traces to be attached but not add to the DRC problems.

---

I could also reduce the sizes of the anchor pads and only have the ring this large. That should also help.

[poeschlr]

My last hunch was correct. If i reduce the size of the anchor pads then the drc error goes away. I will make a pull request for that shortly.

[Shackmeister]

Hi @poeschlr

The strange thing is that not all pads are reported.

Indeed strange

Your workaround is also not possible right now as KiCad no longer allows non plated pads to have a pad number (opening the pad properties clears the number)

Thats why I said it was changed in a text editor. (We got similar hacks with edgecuts)
I found this bug report which seems somewhat similar.
https://bugs.launchpad.net/kicad/+bug/1741702

My last hunch was correct. If i reduce the size of the anchor pads then the drc error goes away. I will make a pull request for that shortly.

I tried this as well, only removed 2 of the errors. All Anchorpads are 0.1mm in my test.
Right clicking the error gives me the choice between the ring pad or the NPTH pad.

[poeschlr]

Fix in #2058

---

I find the argumentation in the bug report quite strange. DRC is in the first instance a check for manufacturing constrains not for voltage hardness compliance with nearby parts. But well we found a workaround that makes these usable for now so i leave such discussions to others.