Thermal connections unpredictable with overlapping pads

[Nick Østergaard]

When filling the zone with the thermal releif connection type to a multipad it can happen that the zone copper does not actually connect!

See the attached image and minimal example board.

Solid connection type works ok.

Application: pcbnew
Version: (2017-12-30 revision e062780e9)-master, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.28.0
Platform: Linux 4.14.8-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.65.1
    Curl: 7.57.0
    Compiler: GCC 7.2.1 with C++ ABI 1011

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=ON
    KICAD_SPICE=ON

[José I. Romero (jose-cyborg)]

Confirmed on:

Application: pcbnew
Version: (2017-12-24 revision 570866557)-master, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.57.0 OpenSSL/1.0.2n zlib/1.2.8 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.28.0 librtmp/2.3
Platform: Linux 4.13.0-1-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    Curl: 7.57.0
    Compiler: GCC 7.2.0 with C++ ABI 1011

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

[Chris Pavlina (pavlina-chris)]

I can confirm this too, and furthermore can confirm that this bad zone fill behavior started no earlier than 8b68a1736.

[Chris Pavlina (pavlina-chris)]

Okay, so I confirmed that reverting to 8b68a1736 fixed a similar zone fill issue for me --- but I should update now that it does NOT fix it on nickoe's board, so something else is going on.

[Nick Østergaard (nickoe)]

It looks the same in 4.0.7.

[Nick Østergaard (nickoe)]

It seems that the issue stems from the fact that the smaller holes in the big pads annular ring also has the pad connection typ thermal. If they are set to sold in the footprint the overall connection looks good. It is strange that thermal releif for the big pad is obstructed by the smaller pads clearance rules in this way.

Since this is not a regression since 4.0.7, I guess we could mark this as an invalid bug.

[Chris Pavlina (pavlina-chris)]

It's definitely not high priority in any case, I see how it comes about from the overlap between the different thermal relief zones.

If we ever get thermal reliefs working for arbitrary pad shapes, then I think the way to solve this is to have the zone fill algo merge overlapping pads into one big "custom" pad for the sake of calculating the fill. Until then, I guess just don't set the smaller holes to have thermal reliefs.

[Jeff Young (jeyjey)]

I'm not sure I agree with the Low priority (whether in 4.0.7 or not).

Imagine the guy that didn't discover this until his boards came back from the fab house....

[Chris Pavlina (pavlina-chris)]

It appears to be detected properly by the connectivity check, so this shouldn't pass DRC.

[Jeff Young (jeyjey)]

I'm OK with Low then.

[Tomasz Wlostowski (twlostow)]

I wouldn't call this a bug, it's just how Kicad's zone calculation algorithm works. It can't detect that a pad lies within another pad, so if both the outer pad and the inner ones have thermal connections enabled, the result is quite unpredictable. For the moment, make sure the inner pads have thermals disabled or use vias.

Tom

[Rene Poeschl (poeschlr)]

Saying this is not a bug leaves a bit of a bad taste. It sounds awfully similar to the unliked "Its not a bug. Its a feature" sentiment.

You might be justified in stating this has low priority as there are workarounds in place. Or alternatively declare it as wishlist but then you need to somehow communicate to users that pad stacks are intentionally unsupported. (At least in combination with thermal connection for zones.) This might then need a DRC check to be honest.

Overlapping pads are done for many reasons not just to get arbitrary shapes. The most common one is to get thermal vias into the exposed pad of an IC package. (There you typically have one large pad with many small tht pads. The tht pads replace vias in such a case. See any footprint ending with _ThermalVias in the official lib.)
Using real vias would only be an option if kicad supports adding vias inside of footprints. (The placement of such thermal vias is critical. Especially when combined with solder paste stencil design to avoid solder wicking.)

[Rene Poeschl (poeschlr)]

This might be either a duplicate or at least connected to https://bugs.launchpad.net/kicad/+bug/602176

[jean-pierre charras (jp-charras)]

Inside a large pad, a thermal via and a through hole pad can be very similar.
Just set the TH pad property "connection to zone" to "solid" and it will be exactly similar to a via.
With the advantage you activate the solder mask layer to open the mask layer (not possible with a via).