Dale, “all copper layers” is selected on the pads just like in your screenshot. The F.Silk.S. and Eco1.User boxes are not checked, but the F.Mask and B.Mask are.
I opened the .kicad_pcb file for my project in a text editor. I noticed that the entries for some components contain solder_mask_margin and clearance definitions and some are missing those two definitions:
(solder_mask_margin 0.1016)
(clearance 0.1016)
Are those needed? Neither of the two headers I pointed out in the original post have those lines, yet one of the headers has this issue and the other doesn’t.
Normally footprints shouldn’t define those values, as the global settings (per layout/project) are the ones that are defining how and if the fab is able to make your board (or which fab/price bracket you chose).
If some footprint needs different values, one usually modifies them in the layout on a local level just for that project.
But I’m just an amateur, so take with grain of salt
As an experiment, I added another 2x3 header to my project by copying the whole block in the schematic. So, it’s connected to the same nets, has the same footprint, etc. The new one is refdes TC2. The original one is TC1. TC1 is the original 2x3 header that has the correct clearance around its pads. When I added TC2 (inside the same fill zone as TC1), it did not get the clearance, and has the same issue as the 1x3 header (refres J4) in my original post. So, I took a look at the entries for TC1 and TC2 in the .kicad_pcb file for my project. There is a difference in the pad definitions. Take a look below. TC1 (the working one) only has 2 numbers inside the “(at x.xx y.xx)” part. ie, (at -2.54 -1.27) for pad P$1. TC2 has THREE numbers in that same place. For example, pad P$1 on TC2 has this: (at -2.54 1.27 270). What gives?
Maybe I’m being dumb, but I can’t figure out how to send a PM. There’s no “new message” button or anything like that in my PM area. I can read the welcome message from Chris Gammell, but I can’t create a new message. Maybe it’s because I’m a new user? Would you mind sending me one?
So… this issue appears to be caused by the way pins are named in the footprints for the headers I was using. The schematic symbol and footprint came from macrofab.com (for use with their house parts). The pins are named “P$x” where x is the pin number. eg, pin 1 would be named “P$1”. I have no idea why they use that convention, but something about that convention seems to be causing all the trouble. I modified one of their footprints by changing to normal pin names… ie, “1”, “2”, etc… and the problem I was having went away. No other thru-hole footprints have the issue I was having; just the macrofab thru hole footprints.
Maybe the $ is being interpreted as some kind of variable (like how $ is used in bash or perl, for example) and making the zones connect to them? I dunno, but getting rid of it seems to fix my issue.
Now, as I mentioned earlier, the header that was on the layout before I created the fill zones doesn’t have the issue. I’m not sure how to explain that, but any macrofab header I add after the zone was created has the issue.
What good example are you talking about that has P$ tags? I did say that the one component that was added prior to the filled zone being created did not show the issue, but adding another component with $ in the pin names after the zone was added did cause the issue. Removing the $ from the pin names and then adding a new component to the zone did not cause the issue.
Don’t read too much into the layers F&B.Cu vs *.Cu. I was trying a ton of different things to see what was going on at that point. In the end, only the P$ in the pin names mattered. Try it yourself if you don’t believe me. Grab the macrofab libraries and give it a shot with their through-hole components, keeping in mind I am on MacOS, if that matters.
Yes, correct. TC1 was the initial header added prior to the zone being created. TC2 was created afterwards.
My last email summarized the problem. You don’t need to be a clairvoyant. Maybe I should just delete all the other posts. The last one summarizes the issue.
I did contact Macrofab and asked why they had $ signs in their footprints. The answer was that they were created by a script and there was some shared-functionality with eagle, which uses $ in pins.
I’m fairly new to Kicad. Where do you raise bug reports? Maybe I will look at the code myself eventually when things slow down.
tldr: don’t use $ in your through hole footprint pin names or bad things may happen.
Unless there is spam or ‘unpleasant information’ in a post it’s not a good idea to do this in a public forum as there are a lot of people just reading (even years after the fact) and if the conversation is crippled the whole thread becomes absolutely useless to them.
For personal notes or a Wiki (even there you see wikipedia to keep a history) this is OK, but not for a discussion board
PS:
If you absolutely want to ‘fast forward’ to a conclusion/solution, edit the first post and ADD an extra marked section with the ‘conclusion/solution’. This will help people of the future as well, as they click on the thread and stumble upon the solution right in the first post, so they save time by not having to go through the whole thread…
I’ve had problems importing designs from Eagle, some of the conventions used there seem weird, and names with $ quite ugly to read. $ is somewhat confusable with S; there seems no reason to use $.
I’ve noticed Macrofab, SnapEDa and others providing automated KiCad translations of Eagle source data, often the KiCad version is poor quality and unchecked, in some cases gives an error loading into KiCad. Always use caution if you suspect the data originated with a different CAD package.
I didn’t find a spec for KiCad names, I tried !""£$%^&*()_+=?-[]}{:@~#'';/..,<> which seemed to be accepted… not sure “anything goes” is a good idea though.
I usually end up renaming everything to a more pleasant KiCad style, but KiCad supports direct import of Eagle PCBs and footprints, so if there is a bug it is worth reporting.