Allow thermal relief options for custom pads

Bug #1732720 reported by James Jackson
72
This bug affects 14 people
Affects Status Importance Assigned to Milestone
KiCad
Fix Committed
Wishlist
Jeff Young

Bug Description

When creating a footprint with a custom pad shape, copper fills do not recognise the net assigned to the pad, and therefore the copper fill does not reach the pad.

Minimal example attached - one custom footprint with one regular pad and one custom pad, each assigned to the same net. The regular pad receives the copper pour whereas the custom pad does not.

Version is from a recent nightly, details below:

Application: kicad
Version: (2017-10-23 revision a562525)-master, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.43.0 SecureTransport zlib/1.2.5
Platform: Mac OS X (Darwin 15.6.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
    wxWidgets: 3.0.2 (UTF-8,STL containers,compatible with 2.8)
    Boost: 1.61.0
    Curl: 7.43.0
    Compiler: Clang 7.3.0 with C++ ABI 1002

Build settings:
    USE_WX_GRAPHICS_CONTEXT=ON
    USE_WX_OVERLAY=ON
    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

Revision history for this message
James Jackson (james-a-f-jackson-2) wrote :
Revision history for this message
James Jackson (james-a-f-jackson-2) wrote :

Screenshot attached

Revision history for this message
Nick Østergaard (nickoe) wrote :

This still seems to be an issue on (2017-12-18 revision 3c6d17026)-master

Revision history for this message
Christoph Nieß (toffi-mixedstuff) wrote :

Same problem here.

Additionally, connecting traces to custom shaped pads doesn't work, either. I can't finish a trace on the pads (I can click onto the anchor, and the trace will go there, but not finish... Connection is recognized as soon as the trace touches the pad, though), and I can't start a trace on the anchor of the pad.

Version Info:
Application: kicad
Version: (2017-12-16 revision 845ca5f)-master, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Platform: Mac OS X (Darwin 17.3.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
    wxWidgets: 3.0.2 (UTF-8,STL containers,compatible with 2.8)
    Boost: 1.61.0
    Curl: 7.43.0
    Compiler: Clang 7.3.0 with C++ ABI 1002

Build settings:
    USE_WX_GRAPHICS_CONTEXT=ON
    USE_WX_OVERLAY=ON
    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

Revision history for this message
jean-pierre charras (jp-charras) wrote :

For a custom shaped pad, one cannot define a suitable shape for thermal shapes.

Therefore only the designer can connect (by a track) this kind of pad to copper zones.
(this is not specific to Kicad)

Changed in kicad:
status: New → Won't Fix
Revision history for this message
Chris Pavlina (pavlina-chris) wrote :

I think this should be "wishlist", not "won't fix". I don't really agree that you _cannot_ define such a shape, it's just very difficult. I think that if someone were to come up with a reasonable approach for it we would probably be very happy to accept a patch.

Revision history for this message
Christoph Nieß (toffi-mixedstuff) wrote :

Most commercial EDA software just treats those like any other pad, and attaches a spoke to whatever edge is at the angular position the spokes are configured to be. That works fine for a lot of the usual shapes, and has to be manually corrected for some really weird shapes (which are rare).

Revision history for this message
James Jackson (james-a-f-jackson-2) wrote :

I would agree - and in addition, if you select no thermals then the filling is trivial.

Revision history for this message
Nick Østergaard (nickoe) wrote :

Setting status to wishlist for now...

Changed in kicad:
importance: Undecided → Wishlist
status: Won't Fix → New
Revision history for this message
Nicholas Savenlid (nicholas-z) wrote :

for solid planes please ?

Revision history for this message
Andrzej Wolski (awolski) wrote :
Revision history for this message
Nicholas Savenlid (nicholas-z) wrote :

super-thanks

ran into this again today

will update.

Revision history for this message
Seth Hillbrand (sethh) wrote :

Adjusting this wishlist title to reflect work still to do. Thermal relief are not easy for custom pads but we can probably figure out a way to allow the user to specify how they would like the thermal reliefs to exist.

summary: - Custom pads do not recognise net in copper zone
+ Allow thermal relief options for custom pads
Revision history for this message
Evan Shultz (evan-shultz) wrote :

To chip in with the above supporting this request, and showing how this is done in one ECAD tool, making custom pad shapes with thermals can be done in a relatively straightforward way.

See the attached image. The "C"- and backwards "C"-shaped areas with dots are the custom pad outlines (this is a Coilcraft LPS4018 footprint) and the solid red area is the top copper. The left pad has fat orthogonal thermals and the right pad has thin diagonal ones.

You can see that the length of the thermals are longer than usual so they reach outside of the pad extents. The originate from the custom pad center. Otherwise, thermals are handled like usual and have all the typical settings.

Revision history for this message
Evan Shultz (evan-shultz) wrote :

Ooops. Wrong screenshot. Here are custom pads on another ECAD tool with thermals as described above.

Revision history for this message
Wedge (wedge-ageek) wrote :

I have the same issue. Screenshot included. I've ensured that the 3 nets are indeed correct.

Application: kicad
Version: (5.0.1)-3, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.54.1
    Compiler: GCC 7.1.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_USE_OCC=OFF
    KICAD_SPICE=ON

Revision history for this message
Wedge (wedge-ageek) wrote :

Sorry, forgot to mention; If it's not obvious in the screenshot, I'm NOT using thermal relief. Perhaps this can help narrow down where the bug is?

Revision history for this message
Rene Poeschl (poeschlr) wrote :

Adding chamfered pads will solve this for many footprints. See: https://bugs.launchpad.net/kicad/+bug/1777516

Revision history for this message
PCB Wiz (1-pcb-wiz) wrote :

>(jp-charras) wrote For a custom shaped pad, one cannot define a suitable shape for thermal shapes.
>Therefore only the designer can connect (by a track) this kind of pad to copper zones.
>(this is not specific to Kicad)

Actually, Diptrace manages this just fine, see attached screen shot.
I imported a Diptrace design, and found the custom pads did not connect the same.

If you want to avoid the code complexities of doing what Diptrace can already do, a possible workaround would be to allow the Anchor pad info that is already in the custom pad, to spawn the thermal.

The thermal resulting would be very slightly different from diptrace, but there would be 2 spokes on the right hand pad. Instead of the horiz thermal being pad-edge-centre, it is anchor-pad-centre.
That's likely tolerable for most all users.

eg consider this database
(pad 4 smd custom (at 0.54 -0.325 270) (size 0.255 0.255) (layers Top_-_Pwr F.Paste F.Mask)
  (net 1 5V_Common) (zone_connect 1) (thermal_width 0.2) (thermal_gap 0.2)

The size of 0.255 has XYD that can be used to create the thermals

This needs a new menu item of 'Thermal relief to anchor pad' added to the PAD options, and then some decision changes in the code to use thermal code, that already works in KiCad.

This appears to generate thermals fine
    (pad 4 smd rect (at 0 -0.82 270) (size 0.15 0.15) (layers Top_-_Pwr F.Paste F.Mask)
      (net 1 5V_Common) (zone_connect 1) (thermal_width 0.25) (thermal_gap 0.25))
ie a Pad smaller than the spokes is managed ok.

Revision history for this message
Rene Poeschl (poeschlr) wrote :

Maybe a more flexible way would be to be able to manually define thermal connection points already in the footprint editor. The user could place 4 special lines from somewhere inside the pad to the outside. These lines will then be used as the basis for creating the spokes.
If no lines are present then the anchor pad can still be used as a fallback for creating the thermals.

Revision history for this message
Evan Shultz (evan-shultz) wrote :

@Rene
That might be limiting. For example, 8-way thermal spokes are common and would not fit 4 defined locations.

A smart and automatic spoke system which could work for any arbitrary number of thermals, ideally avoiding acute angles in copper created against the pad geometry, might be universal. Easy? Probably not. But working for any pad that could be imagined with no work for users, yes.

Revision history for this message
PCB Wiz (1-pcb-wiz) wrote :

>Evan Shultz (evan-shultz) wrote ...
>A smart and automatic spoke system which could work for any arbitrary number of thermals, ideally avoiding >acute angles in copper created against the pad geometry, might be universal.

Acute angles raises a good point.
The diptrace example I posted above, I see has a 90 degree fill zone intersecting a 45 spun square pad, and it seems to have auto-generated a teardrop, to avoid the acute angle. (which show in Kicad)

That means a universal pass that finds-and-fixes any acutes, with teardrop like packers could be widely useful ?

Revision history for this message
PCB Wiz (1-pcb-wiz) wrote :

I've done some more tests, to uncover the SW decision tree used here.

Pad 4 of the attached image has 2 pads so you can see custom and std algorithms at inter-play

Custom pad has a 'push-away' even to own net, whilst the stand alone pad has a 'come here' for the thermal, _but_ that thermal starts to create, but then bumps into the push away.

A Normal pad has 'both push' away, for corners, and 'come here', for spokes.

All this needs to work, is for 'push away' to come from the graphical OR of the F.Cu items, just as now, and the 'come here' from Anchor Pad to be _allowed_ to trump that, just like a normal pad(s) _allows_ a thermal to reach the pad, even tho it has created some push away info itself.

This fix disables/tweaks an off switch decision, that was too sweeping.

Revision history for this message
Steven Slupsky (sslupsky) wrote :

I like the idea of adding more configurability of the thermal relief in the footprint editor. For instance, the ability to rotate the thermal relief by 45 degrees would be useful. Inner layer clearances versus outer layer clearances would be helpful as well.

Also, some additional granularity to override the default thermal relief clearances would be helpful. For instance, I might want different clearance, spoke, etc. for a particular fine pitch footprint. Presently I can edit the footprint properties and change the pad connection to zones. However, I cannot specify / override the clearances and widths.

Jeff Young (jeyjey)
Changed in kicad:
status: New → In Progress
assignee: nobody → Jeff Young (jeyjey)
milestone: none → 6.0.0-rc1
Revision history for this message
Jeff Young (jeyjey) wrote :

Simple N/S/E/W spokes have been added for custom pad shapes. Even this required a complete re-write of the zone fill algorithm along with a lot of performance tuning.

An adjustable angle on the spokes would be reasonably easy to implement. Adjustable number of spokes would be considerably more difficult (the current algorithm makes use of some shortcuts possible with cartesian coordinates, but they only work for 4 spokes), but might be possible.

Beyond that the user would need to draw the spokes. Automating anything else is going to send the performance into the bit bucket.

I'm going to close this one as "Fix Committed". Feel free to open further bugs for adjustable-angle, adjustable-number, and/or user-drawn.

Changed in kicad:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.