I am a bit confused because you appear to use screenshots of different footprints. In the last screenshot your footprint has 4 extra THT pads, all with pin number 9.
In the last screenshot you can also see that there are no clearance line indicators around the polygon part.
But the problem arises with the way that the footprint is defined.
A common way for this is to use multiple pads, all with the same pad number, just as the 4 THT pads used as thermal via’s. So to fix it, just add 4 SMT pads, all with pad number “9” and make sure they overlap (You could even use two very long pads). And then delete the polygon.
Another part I am confused about is that recent KiCad versions do have the ability to flag DRC clearance violations between tracks and graphical items on copper, but I can’t recall details from memory. What KiCad version are you using?
KiCad V5.1.6 was released on 2020-05-15, almost a year and a half ago.
Increments in the third number are generally just bug fixes and (maybe?) also small changes and it’s generally safe to update to the latest stable version.
If you post the footprint here, then I (or someone else) can have a look at how it’s made, and how it behaves in KiCad V5.1.10, but the best solution probably still is to use extra SMT pads instead of a polygon.
would you mind to post the link to the library file? or the kicad_mod file?
Normally a pad should be done as polyline pad and not as graphic pad.
Polyline pads are DRC complaint… graphic on Cu layer should be used for Net Tie entities.
On kicad 5.99 there is also a DRC check on graphic layers, but in general the rule should be kept.
I’m not going to create an account at snapeda just to look at a footprint problem from another KiCad user.
Snapeda creates footprints for many different PCB programs via some automated system. You should not expect such footprints to be “perfect” in any of those EDA programs and always do a careful verification if they work properly.
I do not have much interest in such sites. There are already quite a lot of good footprints in KiCad itself. KiCad has a good editor or creating and modifying footprints, and it also has a bunch of “Footprint Wizards” based on python scripts (just a few pages of code) to create footprints.
When checking and verifying footprints from external sources you have to check every aspect, while if you make (or modify an existing) KiCad footprint, then at least you know that the way pads and such are defined conforms to what KiCad understands.
I also tend to work more detail oriented than average, and for me that often means that If I use such external sources, then it needs a lot of tweaking and checking, while if I make a footprint myself I make it just the way I like it. I do pretty much trust the libraries that come with KiCad itself.
If you added the vias later (during PCB routing) then they would not get the number 9 I think. If they got number 9 that means they belong to footprint so it is different footprint than without them.
Via’s are grey with an orangy center in KiCad. THT Pads are a black hole surrounded by yellow. But when viewed on the PCB, THT pads and Via’s are very similar. The holes in THT pads is usually bigger, and THT pads have their own solder mask, while via’s can either be “tented” or not during the Gerber creation.
I did do a little test with the footprint: RF_Antenna:Texas_SWRA117D_2.4GHz_Right
This footprint also has a polygon, and it’s not seen by the Interactive router or DR in KiCad V5.1.10.
I am sorry for the confusion, when highlighting the polygon and the 9 pad, the Vias in the footprint didn’t appear.
This is the footprint being used, seen in the library.
Sorry if my previous msg " It is the same footprint, I added the vias later." was misleading.
"then is snapeda to blame, not the kicad library team "
Well, why would you add the possibility to add a copper polygon in one layer if later DRC is not gonna detect that that’s a copper area that shouldn’t be stepped in?
At the same time if when using the footprint in layout, if there is a polygon overlapped with a named pad, which is the case, shouldn’t the polygon be considered the same net ?
The snapeda footprint could be better made? Yes
The DRC should be smarter? As well
The only answer I can give here is that there is a limited amount of volunteers who are both knowledgeable enough to write software with the complexity as a program like KiCad and are willing to invest their own time in doing so. Donations on the KiCad project are growing, but it it is by far not enough to hire a team of developers.
And KiCad is making big progress. Just a few years ago it was mandatory to hack into KiCad’s files because of bugs or missing features. These day’s it’s rarely needed, and it’s more an “extra option” to do very unusual things.
In KiCad, graphic polygons on copper are also used for “net ties”, which add the ability to connect different nets at a specific place on the PCB (For example Feedback tracks from shunt resistors, or star ground points).
Learning KiCad’s limits and workarounds (such as using extra pads for this) is (still) part of KiCad. Every EDA program has it’s own quircks.
Also, I almost forgot:
In KiCad V5 you can combine graphic shapes and a pad into a “complex pad”. To do this, select both the pad and the polygon, and then select “Create pad from selected shapes” from the popup menu under the right mouse button. If I do this with the Antenna footprint from my earlier posts, then DRC does recognize it. This antenna footprint was probably made before that function was implemented in KiCad.
In KiCad-nightly V5.99 there is a new and better way to make custom pads, but that does not mean that sites like Snapeda will start using it soon. You’re always responsible for the footprints you make and/or use in your project, and checking them carefully is part of the process of PCB design.
The via thing is no biggie, I would not have bitten into that at all if Piotr had not responded.
In KiCad 5.1 graphic polygons in a copper layer of a footprint are ignored in DRC. (Graphic lines aren’t, so it’s inconsistent.
There’s a reason for that: to be able to create net ties.
This has been changed in v5.99/6.0. In net tie footprints the keywords ‘net tie’ must be added to Keywords property of the footprint, so it’s impossible to do this accidentally. This also is a hack and probably will be changed for v7 later. In v5.99 DRC catches all copper in normal footprints.
This is not a limitation, it’s just the way KiCad works. It’s possible to create real polygonal pads if they are needed.
SnapEDA is responsible for footprints generated by them. In general all services who offer footprints for several EDAs generate them automatically and they are not 100% reliable. You can leave a report to SnapEDA, they have been eager to fix bugs. Actually @NatashaABaker from SnapEDA might comment here.
Thanks for tagging me! I had our team investigate and we are indeed using graphic polygons for these custom pads, which are ignored in DRC, and they agreed we should be using the custom pad shapes like you all mentioned. We’re going to investigate whether it’s a possibility to update the method we use now based on the current file format available (otherwise, it looks like as @paulvdh said, we may have to wait until 5.99 when the new method is introduced, which we will absolutely implement).
On a separate note, one of the devs on our team is working on any and all “wishlist” items related to SnapEDA’s KiCad exporter this quarter, and plans to push all updates by end of month. If there’s anything else you wish we’d update in our exporter, please don’t hesitate to let me know.
No, it is not the right way.
The polygon has not been made part of the pad, as you can see from the missing thin red clearance line. It is around all pads, but not around the polygon.
In KiCad-nightly V5.99 the method to make complex pads has been changed.
The proper way to create complex pads is:
Select a pad in the Footprint Editor.
Right click on it, and select “Edit pad as graphic Shapes” from the popup menu:
KiCad V6 was expected to be released earlier this year, but it’s been delayed a bit. It is in Feature Freeze mode for quite a long time already, and any changes to file types are likely to be only minor bug fixes. I’m not a KiCad developer though and have no real authority to say such things.
After the Release candidates, and later KiCad V6.0 has been released, it may well take a year or so before companies who depend on it for their livelihood switch from KiCad V5.1.x to V6. It’s of course upto you what you decide to support.
DRC does flag the polygon in your previous post, but when it is part of a real pad, then, then KiCad won’t let you route through it in the first place, and the DRC violation is prevented.
Graphic Polygons in Footprints are still used for things like Net-ties and closed solder jumpers (which are very similar to Net-ties.
Code to generate these constructs is of course in KiCad itself, and therefore on gitlab. I have never looked too deep in the interaction between commercial software and FOSS
As far as I understand it (Not a lawyer) you can use any of KiCad’s code for in-house software without having to release anything. Problems start arising if you want to sell your software to other parties.
For a more authoritative answer it is better to contact:
There’s a danger of misunderstanding here. The file format has been changed a bit, but the custom pads are similar in 5.1 and 5.99. Only the UI workflow has been changed. If the footprints are created programmatically it works in the same way in both versions, sans the small file format changes which aren’t directly related to custom pads.
For comparison, here are custom pads made in 5.1 and 5.99:
As you can see, the differences aren’t related to the custom pad, but to pads and graphic shapes in general. The parts which make the pad a “custom” pad are exactly identical.
