Copper fill clearance around through hole pins


#8

Does this behavior indicate the pad definitions are not linked to “All Copper Layers”?

Dale


#9

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.


#10

I’ll definitely take you up on that offer. Thanks! I’ll send you a PM shortly with my email address.


#11

Possibly related question:

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.


#12

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 :slight_smile:


#13

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?

TC1 (correct clearance):

(module MF_Connectors:MF_Connectors-PTH_2.54MM_02X03 (layer F.Cu) (tedit 5862DFF3) (tstamp 584E5EB4)
(at 168.2496 105.2322)
(descr “DESCRIPTION: PACKAGE FOR 2.54MM PITCH HEADER 2 ROW 6 POSITION. BASED ON 4UCON 00989.”)
(tags “DESCRIPTION: PACKAGE FOR 2.54MM PITCH HEADER 2 ROW 6 POSITION. BASED ON 4UCON 00989.”)
(path /58612799)
(attr virtual)
(fp_text reference TC1 (at -0.254 4.572 180) (layer F.SilkS)
(effects (font (size 1.016 1.016) (thickness 0.1524)))
)
(fp_text value CON_02X03_PTH_2.54MM (at -7.0866 -0.01778 90) (layer F.SilkS)
(effects (font (size 1.016 1.016) (thickness 0.1524)))
)
(fp_line (start -3.78968 -2.51968) (end 3.78968 -2.51968) (layer F.SilkS) (width 0.127))
(fp_line (start 3.78968 -2.51968) (end 3.78968 2.51968) (layer F.SilkS) (width 0.127))
(fp_line (start 3.78968 2.51968) (end -3.78968 2.51968) (layer F.SilkS) (width 0.127))
(fp_line (start -3.78968 2.51968) (end -3.78968 -2.51968) (layer F.SilkS) (width 0.127))
(fp_line (start -4.445 3.175) (end -3.81 3.175) (layer F.SilkS) (width 0.127))
(fp_line (start -3.81 3.175) (end -3.175 2.54) (layer F.SilkS) (width 0.127))
(fp_line (start -3.175 2.54) (end -3.81 1.905) (layer F.SilkS) (width 0.127))
(fp_line (start -3.81 1.905) (end -4.445 2.54) (layer F.SilkS) (width 0.127))
(fp_line (start -4.445 2.54) (end -4.445 3.175) (layer F.SilkS) (width 0.127))
(pad P$1 thru_hole circle (at -2.54 1.27) (size 1.50622 1.50622) (drill 0.99822) (layers *.Cu *.Mask)
(net 53 /MISO))
(pad P$2 thru_hole circle (at -2.54 -1.27) (size 1.50622 1.50622) (drill 0.99822) (layers *.Cu *.Mask)
(net 167 “Net-(R53-PadP$2)”))
(pad P$3 thru_hole circle (at 0 1.27) (size 1.50622 1.50622) (drill 0.99822) (layers *.Cu *.Mask)
(net 51 /SCK))
(pad P$4 thru_hole circle (at 0 -1.27) (size 1.50622 1.50622) (drill 0.99822) (layers *.Cu *.Mask)
(net 52 /MOSI))
(pad P$5 thru_hole circle (at 2.54 1.27) (size 1.50622 1.50622) (drill 0.99822) (layers *.Cu *.Mask)
(net 3 /RESET))
(pad P$6 thru_hole circle (at 2.54 -1.27) (size 1.50622 1.50622) (drill 0.99822) (layers *.Cu *.Mask)
(net 166 “Net-(R52-PadP$1)”))
)

TC2 (no clearance):

(module MF_Connectors:MF_Connectors-PTH_2.54MM_02X03 (layer F.Cu) (tedit 58649689) (tstamp 5875D940)
(at 220.1672 132.842 270)
(descr “DESCRIPTION: PACKAGE FOR 2.54MM PITCH HEADER 2 ROW 6 POSITION. BASED ON 4UCON 00989.”)
(tags “DESCRIPTION: PACKAGE FOR 2.54MM PITCH HEADER 2 ROW 6 POSITION. BASED ON 4UCON 00989.”)
(path /58642F3D)
(attr virtual)
(fp_text reference TC2 (at 1.3462 4.191 360) (layer F.SilkS)
(effects (font (size 1.016 1.016) (thickness 0.1524)))
)
(fp_text value CON_02X03_PTH_2.54MM (at -7.0866 -0.01778 360) (layer F.SilkS)
(effects (font (size 1.016 1.016) (thickness 0.1524)))
)
(fp_line (start -3.78968 -2.51968) (end 3.78968 -2.51968) (layer F.SilkS) (width 0.127))
(fp_line (start 3.78968 -2.51968) (end 3.78968 2.51968) (layer F.SilkS) (width 0.127))
(fp_line (start 3.78968 2.51968) (end -3.78968 2.51968) (layer F.SilkS) (width 0.127))
(fp_line (start -3.78968 2.51968) (end -3.78968 -2.51968) (layer F.SilkS) (width 0.127))
(fp_line (start -4.445 3.175) (end -3.81 3.175) (layer F.SilkS) (width 0.127))
(fp_line (start -3.81 3.175) (end -3.175 2.54) (layer F.SilkS) (width 0.127))
(fp_line (start -3.175 2.54) (end -3.81 1.905) (layer F.SilkS) (width 0.127))
(fp_line (start -3.81 1.905) (end -4.445 2.54) (layer F.SilkS) (width 0.127))
(fp_line (start -4.445 2.54) (end -4.445 3.175) (layer F.SilkS) (width 0.127))
(pad P$1 thru_hole circle (at -2.54 1.27 270) (size 1.50622 1.50622) (drill 0.99822) (layers F&B.Cu *.Mask)
(net 202 “Net-(R61-PadP$1)”))
(pad P$2 thru_hole circle (at -2.54 -1.27 270) (size 1.50622 1.50622) (drill 0.99822) (layers F&B.Cu *.Mask)
(net 200 “Net-(R14-PadP$2)”))
(pad P$3 thru_hole circle (at 0 1.27 270) (size 1.50622 1.50622) (drill 0.99822) (layers F&B.Cu *.Mask)
(net 203 “Net-(R62-PadP$1)”))
(pad P$4 thru_hole circle (at 0 -1.27 270) (size 1.50622 1.50622) (drill 0.99822) (layers F&B.Cu *.Mask)
(net 205 “Net-(R64-PadP$2)”))
(pad P$5 thru_hole circle (at 2.54 1.27 270) (size 1.50622 1.50622) (drill 0.99822) (layers F&B.Cu *.Mask)
(net 204 “Net-(R63-PadP$1)”))
(pad P$6 thru_hole circle (at 2.54 -1.27 270) (size 1.50622 1.50622) (drill 0.99822) (layers F&B.Cu *.Mask)
(net 201 “Net-(R60-PadP$1)”))
)


#14

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?


#15

I think that’s a rotation angle (check orientation in the pad properties).


#16

Yes, I think you are right. I had just came to that same conclusion myself and was about to post.


#17

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.

Does this make sense to anybody??

Here is an example of what the pin names are like in their libraries:


#18

I’m not quite following this reasoning.
Looking at your good/bad examples, they both use (pad P$1 tags, so that seems unlikely as a cause.

The difference that is present is
Good:
(layers *.Cu *.Mask)
Bad:
(layers F&B.Cu *.Mask)

If you try manual file edit to swap a couple of *.Cu to F&B.Cu and F&B.Cu to *.Cu, does the pour change to follow ?


#19

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.


#20

When you wrote

TC1 (correct clearance):

TC2 (no clearance):

I assumed that meant TC1 was good and TC2 was bad.

‘trying a ton of different things’ may work for you, but readers on here are not clairvoyant. We cannot tell what you wrote, was not what you meant.

If you have a reproducible case, I’d suggest you raise a bug report, with a small example file.
Include the build info for your KiCad.


#21

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.


#22

Bugs are reported here : https://bugs.launchpad.net/kicad

To get the best response, include a simplest test case & the KiCad version info & OS of your test build.

  • in your case I’d suggest a footprint with alternating Good/Bad pin names could be a good test.

This reported behaviour seems almost deliberate - hard to see how clearance would otherwise care about a pin name.

I would also suggest you test/confirm on a nightly build http://kicad-pcb.org/download/
in case it is already fixed.


#23

Stick to A-Z and 0-9, almost anything else risks being interpreted as a special character at some point


#24

Exactly. Anybody who writes software has seen cases like this before. Thanks.


#25

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 :wink:

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…


#26

Don’t worry… I am not going to delete them. That was tongue-in-cheek.


#27

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.