However, even in the most stripped down configuration, having no other components in my schematic and just connecting some of the pins to their proper net, I get over 50 DRC errors, as seen in the screen shots. The underlying issue seems to be that KiCad assigns the through holes to different nets than the pads they are inside of and that most of the center polygon isn’t part of the proper pad.
Is there something wrong with the footprint or is there some mistake I did in KiCad? Any help or ideas would be appreciated.
Other than most basic footprints seem to be difficult for those 3rd party footprint services. They have some internal file formats which they automatically convert to wanted files, for example for KiCad. Because different EDA program file formats handle more complex pads and other details in very different ways, those converters aren’t always up to date. Therefore you have to fix the footprints. You have to compare the footprint to the authoritative data sheet anyway, and you have learn how to use the KiCad footprint editor anyway, so you have to think if it’s worth fixing the faulty footprint or if it’s better to make your own from scratch.
You also have to learn what the DRC errors mean anyway.
In KiCad, complex pads which are made of a multiple of simpler pads normally all have the same pad number. Fix the pad numbers, and most of the DRC complaints will be gone.
In v4 this was common. In v5 (or was it v6?), custom pad shapes with graphic shapes became supported. My recollection is that, since then, the old method of overlaying many SMT pads with the same pad number has generated DRC errors.
No. It is still common. Take for example the screenshot above. This footprint has a bunch of thermal via’s which are also made from (THT) pads. (They have pad numbers).
I also verified this with an SMT footprint. I made a dummy project with the footprint: Package_SON:Texas_S-PVSON-N10_ThermalVias (Multiple overlapping SMT pads with pad no. 11) and there are no DRC complaints in KiCad V8.0.9.
