Zones make connection to the pad but still shows net unconnected

[cioma]

Please feel free to add your vote to the “Zones make connection to the pad but still shows net unconnected” bug

[Joan_Sparky]

I did read Art’s last famous words in the bug report and was wondering if you did go through the trouble of creating a example file that recreates the bug?

The problem is that DRC doesn’t recognize pads connected through
multiple filled zones and vias and it SHOULD. Here is the quintessence
of the bug report - the pad has physical copper connection to the net
but DRC doesn’t detect it.

I don’t think there is a way around it, as the Dev’s won’t know what to look out for from your ‘update’ on Art’s report, especially as Wayne didn’t seem to get it or was just plain fed up and doesn’t bother.

This:

(It) …confuses the hell out of me on a complex board with multiple zones on multiple layers.

won’t help them nail that bug.

[Rene_Poschl]

Today i had a similar problem with a zone.
I found out that the zone needs to cover the center of the pad to be counted as connected.
Maybe this info can help you.

[PCB_Wiz]

@Rene_Poschl

Today i had a similar problem with a zone.I found out that the zone needs to cover the center of the pad to be counted as connected.Maybe this info can help you.

Yes, I have filed somewhat a more recent bug report on this too. See also other posts.

Presently, Tracks need only their last vertex inside the PAD, to register connected. = Good.

Fills, however, test to the PadCentre, vs Fill-vertex, which means the fill needs to overlap the centre by half the fill line width.

ie you can currently help this issue with smaller fill clearances, and finer line widths.

The proper fix, will be to have the fill-check changed to use the inside-the-pad, not the Pad-Centre test.

I expect this will give a slower DRC, but DRC seems to be quite quick now ?

[cioma]

Fair enough
I’ve attached there a sample project that shows the problem.

[PCB_Wiz]

@PCB_Wiz

Fills, however, test to the PadCentre, vs Fill-vertex, which means the fill needs to overlap the centre by half the fill line width.

The proper fix, will be to have the fill-check changed to use the inside-the-pad, not the Pad-Centre test.

Thinking some more about any possible actual fix…

Any connected test, can be same-net qualified, so that reduces any speed impact.
Thermals look to always have a corner inside the PAD, so they could use the Trace-Connect code.
Code would not know which corners are important,and testing all zone-vertex is likely slow.

However, Solid (flood over) can have no Zone corners anywhere near the pad, and the ‘Pad centre within Zone’ is the test needed in this case.

That still leaves a tangent case, where a zone line passes over a Pad, but not overlapped enough to catch centre.

That leaves a couple of generate choices
a) Where flood intersects a same-net & flood-over pad, add a Zone Corner inside the pad so Trace-connect test can work.
or
b) expand all same-net Pads to an octogon? of points which become new virtual pad centres,
if any one of those is within-zone, then tag as connected.

solution b) generates a new virtual data set for connect, but uses the same rule-check as now.
This will probably also work for Thermals too.
octagon would cover orthogonal and 45’ zone intersects, in many cases all 8 would connect, in corner cases just one would be enough to tag connected.

I’m thinking b) is the easiest to code, with least impact, and likely also fastest.

[jwhitmore]

I’m looking at this thread and the associated bug and it’s marked as a fixed issue. That being the case I’m not sure what I’d doing wrong with a design on github, badly tagged as “fill-question”. I’m using a recent version of KiCad compiled from source so I must be using the wrong method to create my zones? I’ve looked at tutorial but that doesn’t mention anything about nets, which would be cleared by a zone.

Sorry for dragging up old thread again but I’m hoping that’s better then creating a new one.

Application: kicad
Version: (2017-11-03 revision 08a9dc0)-master, debug build
Libraries:
wxWidgets 3.0.2
libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-98-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.58.0
Curl: 7.47.0
Compiler: GCC 5.4.0 with C++ ABI 1009

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=OFF
KICAD_SCRIPTING_MODULES=OFF
KICAD_SCRIPTING_WXPYTHON=OFF
KICAD_SCRIPTING_ACTION_MENU=OFF
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=OFF
KICAD_SPICE=OFF

[Joan_Sparky]

We need more info… a screenshot of the affected area/problem would be nice.

Also, did you see this thread?

Filled Copper Zones not showing up in Gerbers/Printouts/3D view

So this is my first KiCAD project, and I can’t figure what I’m missing when it comes to filled copper zones. I seem to be able to create them just fine, but they don’t end up on Gerbers, or print outs, or in the 3D view. See the screenshot below. [image] The left window is pcbnew in default mode, showing three copper zones, on three different nets. They only show up with the hatched fill, which is necessarily consistent with what I’ve seen in some of the tutorials on the 'net, where the fil…

[jwhitmore]

Thank you that thread solved my problems.

My track names disappeared from the schematic so the fill zones hadn’t filled properly. Once I has corrected that problem all the nets that are connected did disappear. Thanks again.