Copper fill clearance around through hole pins

Layout
1

Hello,

I have a 4 layer board with traces and components (mostly SMD) on front and back, and ground and power planes on the inner two layers. I noticed today that on some of my through-hole headers, the copper fills are not respecting zone clearances correctly around the through hole pins. In the same zone, I have a 1x3 header that gets zero clearance from the fill around its pads and a 2x3 that gets the correct zone clearance. I tried adjusting the zone clearance, and with some experimentation I determined that on the 1x3 header, kicad is using the hole as the boundary that it is clearing from, whereas on the 2x3 header it is using the pad. My clearance is set to 0.254mm for this zone, and the 1x3 pad is about that same thickness, which explains why the planes are butted right up against the pad. It makes no sense, though, that it would do that for the 1x3 but then on the 2x3 header it would measure from the edge of the pad. The 2x3 header was added to the board before the zone was created and filled and the 1x3 header was added after. Maybe this has something to do with it??

Has anyone seen this behavior before? To get around this, I had to create a keepout area around the 1x3 header, but I’d rather not do this. Plus, I don’t have confidence the zones are not shorting something else out on the board that I haven’t noticed.

I am running the following:
Application: kicad
Version: 4.0.4-stable release build
wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8)
Platform: Mac OS X (Darwin 16.1.0 x86_64), 64 bit, Little endian, wxMac
Boost version: 1.57.0
USE_WX_GRAPHICS_CONTEXT=ON
USE_WX_OVERLAY=ON
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
USE_FP_LIB_TABLE=HARD_CODED_ON
BUILD_GITHUB_PLUGIN=ON

2

Here’s a pic of the issue. Note TC1, which has clearance around it’s pads, versus J4, which does not.
This is before I added the keepout area, obviously.
https://s3-us-west-2.amazonaws.com/kicad-post/kicad_problem.png

3

Check the pad and footprint properties for clearance settings for both connectors.
I guess the 1x3 has got some values in either the footprint or pad settings for clearance that override the global values that come to be if the zone is being filled…

4

Check the local clearance settings for pads in footptint used for J4.
Do you have a separate class for power nets in desing rules?

5

Thanks for the reply, but no, neither footprint has nonzero settings. Both
are using the zone settings.

6

No, no special classes in design rules.

7

OK, that is weird - can’t think of anything else at the moment.

If it’s an option for you I’m sure either I or @keruseykaryu can have a look at your project if you want to (or someone else). Just drop us a PM for mail contacts to exchange files in that case.

On the other hand, some more screenshots with just one or the other power plane layers active, so we can see easier what’s going on) might be in order.

8

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

806×646 64.1 KB

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:
https://s3-us-west-2.amazonaws.com/kicad-post/macrofab_footprint.png

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 ?

1 Like
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.

1 Like