Through hole pads aren't connected to inner layer

I’ve got a micro usb connector with through hole connections for the ground shield:

And I’ve got the same symptom as here Zone fill fails to connect to some through hole pin pads, not others - #2 by mf_ibfeew but I don’t have tight tolerances

My GND inner layer (green) is not connected to the GND pins of the through hole part. You can see the purple (red and blue) thermal reliefs of the pad on the top and bottom layers.

The fill has the GND net assigned, and the same zone property settings as the GND plane as the blue/red outer layers. My GND vias are properly connected to the green inner layer, so I’m pretty sure its not a net problem…

What haven’t I set up properly?

Thanks

Andrew

Firstly . . . .

Can you paste your full version info here please, you can get it from KiCad > Help > About KiCad > Copy Version Info
image

Secondly,

did you press B to refill the zones after you set the zone to the GND net ?

1 Like

Thirdly - what is your inner layer zone fill net?

Yes, refilling the zones has no effect

The inner layer, which is set as a Power Plane, and called GND.Cu, has a fill zone associated with the GND net.

If i manually add traces from the through-holes to the GND fill, DRC doesn’t comlain (as in, it doesnt complain there are nets connected that shouldnt be). Similarly the GND vias are properly connected to the GND fill/inner layer.

Application: KiCad PCB Editor x86_64 on x86_64

Version: 9.0.3, release build

Libraries:
	wxWidgets 3.2.8
	FreeType 2.13.3
	HarfBuzz 9.0.0
	FontConfig 2.15.0
	libcurl/8.14.1 OpenSSL/3.3.3 zlib/1.3.1 libidn2/2.3.7 libpsl/0.21.5 nghttp2/1.65.0

Platform: Freedesktop SDK 24.08 (Flatpak runtime), 64 bit, Little endian, wxGTK, X11, zorin, wayland
OpenGL: AMD, AMD Radeon Graphics (radeonsi, raphael_mendocino, LLVM 19.1.7, DRM 3.57, 6.8.0-59-generic), 4.6 (Compatibility Profile) Mesa 25.1.3 (git-ba95e694fe)

Build Info:
	Date: Nov 11 2011 11:11:11
	wxWidgets: 3.2.8 (wchar_t,wx containers) GTK+ 3.24
	Boost: 1.88.0
	OCC: 7.9.1
	Curl: 8.14.1
	ngspice: 44.2
	Compiler: GCC 14.3.0 with C++ ABI 1019
	KICAD_IPC_API=ON

Locale: 
	Lang: en_GB
	Enc: UTF-8
	Num: 1,234.5
	Encoded кΩ丈: D0BACEA9E4B888 (sys), D0BACEA9E4B888 (utf8)

Can you share the project?

What layer is selected in your first screenshot?

Double check the net names. For example, KiCad accepts (trailing) spaces in net names, and this effectively turns it into a different net.

1 Like

How extremely odd

I cloned my project files in order to create a minimal repro to share here, and the problem had gone!

I switched back to my original copy and it works there now too…

I’ve made no changes. Literally been for dinner and put the kids to bed since my first post, not touched the PC!

I’m sure the internet won’t believe me :frowning:

Anyway, thanks all for your time.

2 Likes

:wink: your secret is safe with us. Glad to hear it’s fixed, that is the main thing.

1 Like

Well, I’m nervous now.

I only happened to notice by chance just as I was about to send it to the manufacturer.

Scared this is some bug that will recurr.

Can’t repro it now though obviously

I always check the Gerbers.

And, I can’t imagine ever, under any circumstance, sending my design to a manufacturer. If they can’t handle Gerber files, I’ll go somewhere else.

My (very small) contract manufacturer had some problems with my gerbers when in 2017 I moved from Protel to KiCad.
Since ‘always’ I was using ‘Solder paste clearance’ = 0 and never even thought that this has to be modified before ordering the stencil (it was simply ‘not my problem’).
When he got from me gerbers with rounded rectangle pads he found he have no tool to shrink it.
I got from him information what is really needed and learned how to get correct stencil gerbers from KiCad. When next day I have send him corrected files he said that in meantime he got tool to do it so need not my new files.
But since then I am generating stencil gerber that he can use without any corrections.

For years I just thought that openings in stencil are the same as pads and didn’t know that smal (1 mil) overlap is needed to ensure tight adhesion of the stencil to the pads so that the paste does not stain the stencil from the other side.

I don’t quite understand what overlap means?) I can say that the aperture of the stencil by default is usually 15 percent smaller than the size of the platform. But there is one thing, but everything depends on the thickness of the stencil and in this case, the manufacturer or assembly contractor usually makes it himself (edits). There are many more nuances such as jumpers on large platforms, dividing polygons into several parts to prevent rupture and deformation of the stencil when stretching, etc.

At first I used word margin but replaced it with overlap.
I’m not a technologist, I only know a little
Copper pad is higher then the surroundings. Stencil positioning is not perfect. As I understand the task is to not get a hole when stencil little shifted to not push the paste under it to avoid need of cleaning stencil before next use.

I use the same set of footprints so most parameters are equal for all my PCBs.
KiCad footprints have paste opening divided into smaller holes and I am doing the same.

1 Like

Looks like someone else is seeing the same problem / bug.

The problem appearing only after the layer count is increased may be an important hint, but I’m still on KiCad V8 and can’t verify it myself.

So OP from this thread added to the other thread:

It seems plausible this is a bug that only shows itself just after layer count is increased, but does not persist after a restart of KiCad. Can this be verified / reproduced?

Ill test it later tonight

1 Like