Zones make connection to the pad but still shows net unconnected

[Art]

Happens quite often. You pour zone it makes thermal relief connection to a pad and still shows the pad net unconnected. You have to go and physically draw a track to another pad of the same net for the ratsnest line to go away. Seem to exist in all canvases.

See files attached.

Application: kicad
Version: 4.0.1-stable release build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1009,GCC 5.2.0,wx containers,compatible with 2.8)
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Boost version: 1.57.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

[Wayne Stambaugh (stambaughw)]

It looks to me like U3 (or P5 I can't tell) pin 2 is orphaned. If you look closely at your F.Cu plane on the left hand side, you should see that the plane does not make connect (broken pour path) to the GND pin on P2. This may also explain why none of the GND pins on U1 on the B.Cu layer are connected either. The vias you have added through to the front plane have no connection to GND.

[Art (diametrix)]

I get a distinct feeling that one of us have no idea what he is talking about. Did you actually open the pcb file? Did you actually look at the file I provided?

First of all two areas that I highlighted had nothing to do with P2. P2 is located in the opposite corner of the board and incidentally it is connected to the GND pin.

Second, U1 wasn't a problem either and I have no idea what you are talking about when you say that "non of the GND pins on U1 on the B.Cu layer are connected. They all have thermal relief connection and connected to the ground plane

If you had time to type up the answer I guess at the very least you could study the subject matter of your answer at least a little bit. Do you mind actually commenting on the problem areas rather than elsewhere on the board?

See pictures attached to illustrate my point

[Wayne Stambaugh (stambaughw)]

On 1/25/2016 8:24 AM, Art wrote:
> I get a distinct feeling that one of us have no idea what he is talking
> about. Did you actually open the pcb file? Did you actually look at
> the file I provided?

In the future if want me to help you, please refrain from comments like
this. They serve no purpose helping me understand your problem but
since it appears to me you think I am incompetent please look at the
revisions I made to your board file that resolved the issues.

>
> First of all two areas that I highlighted had nothing to do with P2. P2
> is located in the opposite corner of the board and incidentally it is
> connected to the GND pin.

I'm assuming you want every GND pad on your board to connect to the GND
pin on J2. The problem was that your top plane (GND) copper poor was
broken so you had isolated copper areas. I merely decreased the
clearance from 0.015" to 0.010" of the top GND zone to allow the copper
pour to make connections so that solved the R3 pin 1 connection issue
(Board_1.jpg image).

To solve the issue other issue. I added a trace to the bottom copper
layer from the via you pointed to in Board_2.jpg to one of the GND pads
on U1. This resolves your other missing connection. The reason you
have to add the trace is the the DRC currently doesn't recognize vias
that terminate into zones. In other words the bottom layer GND zone was
not actually connect to GND until the trace was added. This is a known
and I believe documented issue with Pcbnew which will be fixed
(hopefully) during this development cycle.

These changes may not be acceptable to you but they resolve your
connection issues.

>
> Second, U1 wasn't a problem either and I have no idea what you are
> talking about when you say that "non of the GND pins on U1 on the B.Cu
> layer are connected. They all have thermal relief connection and
> connected to the ground plane
>
> If you had time to type up the answer I guess at the very least you
> could study the subject matter of your answer at least a little bit. Do
> you mind actually commenting on the problem areas rather than elsewhere
> on the board?
>
> See pictures attached to illustrate my point
>
> ** Attachment added: "Board_1.jpg"
> https://bugs.launchpad.net/kicad/+bug/1537120/+attachment/4556241/+files/Board_1.jpg
>

[Art (diametrix)]

Wayne,

You misunderstand the purpose of this post. I didn't come here to have you to do me favor. I took time to submit a legitimate bug report. Instead of addressing the issue you came up with explanations why it is not an issue and not in so many words conveyed the idea that I'm incompetent to distinguish a bug from a bad hardware design. Which caused me to take more time to explain the post that seemed to me pretty self-explanatory in the first place. I might've responded in kind, which I shouldn't have, for which I'm sorry. However nobody likes their time wasted. I did my part in reporting it though. It is entirely up to you to decide if this particular issue needs to be fixed.

Now to the matter at hand. I didn't need you to circumvent the issue for me. I can and have done it myself. As I mentioned before I run into this all the time, thus the reason for posting it.

I created several screen captions for you to show that pads with "unconnected" pads are clearly connected to the power ground pin (which is P3). There is no J2 in my design. If you are referring to P2 then it is just another connector which also has a clear ground path to the GND pin of P3, which I showed on the picture as well.

You mentioned that
> "The problem was that your top plane (GND) copper poor was broken so you had isolated copper areas."

Technically it is not the problem. 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.

[Artsiom Shchatsko (cioma)]

This issue still exists in r7255 and confuses the hell out of me on a complex board with multiple zones on multiple layers. Could developers please look into it?

Application: kicad
Version: 201609280951+7255~55~ubuntu16.04.1-, release build
Libraries: wxWidgets 3.0.2
           libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-38-generic x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.58.0
Curl: 7.47.0
KiCad - Compiler: GCC 5.4.0 with C++ ABI 1009
        Settings: USE_WX_GRAPHICS_CONTEXT=OFF
                  USE_WX_OVERLAY=OFF
                  KICAD_SCRIPTING=ON
                  KICAD_SCRIPTING_MODULES=ON
                  KICAD_SCRIPTING_WXPYTHON=ON
                  BUILD_GITHUB_PLUGIN=ON
                  KICAD_USE_SCH_IO_MANAGER=OFF
                  KICAD_USE_OCE=ON

[Artsiom Shchatsko (cioma)]

It seems it's the zone (re-)filling logic at fault as if I reload board with filled zones those bogus ratsnests are gone. But they reappear if I unfill and refill zones.

[Artsiom Shchatsko (cioma)]

Here is a sample project that shows the problem. There is an unfilled zone and if you fill it the ratsnest connection doesn't disappear automatically.

[Julius Schmidt (aiju0)]

The following patch fixes the problem for me. It's just a workaround, though.

diff --git a/pcbnew/zones_by_polygon_fill_functions.cpp b/pcbnew/zones_by_polygon_fill_functions.cpp
index ebe2964..a6fbb99 100644
--- a/pcbnew/zones_by_polygon_fill_functions.cpp
+++ b/pcbnew/zones_by_polygon_fill_functions.cpp
@@ -119,6 +119,7 @@ int PCB_EDIT_FRAME::Fill_Zone( ZONE_CONTAINER* aZone )
     aZone->BuildFilledSolidAreasPolygons( GetBoard() );
     GetGalCanvas()->GetView()->Update( aZone, KIGFX::ALL );
     GetBoard()->GetRatsnest()->Update( aZone );
+ TestNetConnection( NULL, aZone->GetNetCode() );

     OnModify();

[Julius Schmidt (aiju0)]

Apologies, I was mistaken.

[Nick Østergaard (nickoe)]

cioma, thank you for providing a minimal example. I do see the problem in latest development version, 92c61e02.

I note that this issue is only present in the GAL canvas. If one fill in legacy and switches back to GAL it will no redraw the rastnestline.

[Julius Schmidt (aiju0)]

I narrowed it down now. One problem is that calling RN_DATA::Update() on an unfilled zone will successfully remove the zone, but then don't add it again, because there are no polygons in it.
The fix is to add an empty ZONE_DATA object in this case.
The other problem is that Fill_Zone is called in tools/point_editor.cpp without calling RN_DATA::Recalculate().

[KiCad Janitor (kicad-janitor)]

Fixed in revision 877a65dcc794ba9bf8ae3cab729cea24a5a7eed7
https://git.launchpad.net/kicad/patch/?id=877a65dcc794ba9bf8ae3cab729cea24a5a7eed7