KiCad PCB fails thermals on complex pad stacks

I don't know the design goals of KiCad, but it seems for me that stacking pads are now forbidden. It's a hint getting a DRC error on "hole of TH pad is too close to pad of associated SMT pad".

It was a nice feature, but not "stacking" two or more pads on one another, rather having different shapes/sizes on different layers when defining pads of footprint.

 Other CAD programs allow independent control of PAD Size/Shape on all layers.
KiCad already allows Mask and Paste to be separate now, with no issues or errors, so is _almost_ there, but there are many cases where you need different size/shape PADS on Top from Bottom Copper, and here, KiCad needs fixing.

a) The stunted thermals is a clear bug, as they fail to make electrical connection in many cases.

 There must be some unexpected extra code in there, that _deliberately_ shortens them, for some reason ?

Q: Does anyone know why that 'special' Thermal code is there, or what triggers it ?

b) The false-DRC message, I think simply needs a check for 'same pin number = ok' added.

With those steps, KiCad can attain the same flexibility as other CAD programs.

More tests & results :

a) Stunted Thermals

The trigger item for the stunted thermals, seems to be the hole.
The Thermal-pull-back is significant from the hole, enough to NOT CONNECT to PADS, in some cases!!
Not sure WHY that is even there ? Who cares how many 'layers of copper' plot over a hole ?
The hole always wins

Even when the Thermal DOES overlap the PAD, this error below persists on ONE side only
(ie DRC does not consider the thermal connecting)

ErrType(2): Unconnected pads
    @ (39.370 mm,4.920 mm): Pad 15 on F.Cu, Non-copper of U1_r0M

Here F.Cu and B.Cu have identical fill.stacks, & both visually connect, but one side reports OK, the other side is tagged NC ?!

I can see that general pour items could want to avoid holes with no annular ring, but a thermal should certainly NOT be averse to its own PADS drill information.

b) I get this message UNLESS the F.Cu and B.Cu holes-defines are IDENTICAL.
ErrType(25): Hole near pad
    @ (56.640 mm,-7.780 mm): Pad 15 on F.Cu, Non-copper of U1_r0
    @ (56.640 mm,-7.780 mm): Pad 15 on B.Cu, Non-copper of U1_r0

ie, it can be avoided, but requires carefully user clone of Drill Params in TWO places.

With this dual defined, now BOTH mounted and unmounted sides have stunted thermals, I guess triggered by the 'other' PADS hole.

 The main concern with DUAL editing, is the user does not expect to have to enter the same information in two places.
 I think preferable is to instead have same-pad tolerance of Drill, (related to thermal above) as that allows cleaner single define, and is less restrictive on Top/Bot Stack variations.

I think both bugs/undesirable effects can be fixed, with tolerance (ie ignore) of own-pad drill ?

Attached is a test example.
All PAD Stacks should be legal, and can come in on Translation from other CAD programs, and it is common to need Top Copper NOT the same as Bottom Copper.

KiCad fails on the more complex PAD Stacks in various ways, from Flood-over incorrect, to short or not connecting thermals, to false messages on connect.
I consider all of these serious, as they either fail to connect, or have false errors, or generate bad-copper details.

In all cases, the drill of one stack, seems to affect action on the same pin, of other stacks.
ie that looks to be the pivotal trigger.

Ideally, there should be just one define needed for drill per pin, to avoid having to edit duplicates.
Maybe this can be F.Cu, or any <> 0 if F.Cu is 0 ?

@PCB Wiz
If KiCad features pad stacking, then it's a confirmed bug. If it doesn't then it's a wish. Some headman, please decide..

Anyway the wish is rather "allowing to create different pad shapes on different layers" than allowing pad stacking. I think pad stacking would bring more headaches: how to handle overlapping holes of TH footprints, how to handle stacked components connecting to different nets etc...

Le 31/07/2016 à 12:06, Novak Tamas a écrit :
> @PCB Wiz
> If KiCad features pad stacking, then it's a confirmed bug. If it doesn't then it's a wish. Some headman, please decide..
>
> Anyway the wish is rather "allowing to create different pad shapes on
> different layers" than allowing pad stacking. I think pad stacking would
> bring more headaches: how to handle overlapping holes of TH footprints,
> how to handle stacked components connecting to different nets etc...
>

Pcbnew does not yet support pad stacking.

--
Jean-Pierre CHARRAS

@Novak
> If KiCad features pad stacking, then it's a confirmed bug.

Users must have some means now in KiCad to have differing size PADS on Top & Bottom ?

What is the suggested method now, to create differing Size Top/Bottom PADS ?
There may be some workaround/hack that can use this feature ?
I'll run some tests.

@jean-pierre
> Pcbnew does not yet support pad stacking.

@Novak
> Anyway the wish is rather "allowing to create different pad shapes on
> different layers" than allowing pad stacking. I think pad stacking would
> bring more headaches: how to handle overlapping holes of TH footprints,
> how to handle stacked components connecting to different nets etc...

Wow, Pcbnew is quite close to actually working, for a feature that seems to have not been intended/tested.
Based on this comment, I created a more hybrid/hack stackup, which is what users may used who need differing Size PADS top/Bottom now.

This Pin 7 stack, which first creates a Drill-slug, then adds F/B, seems to pass all DRC, but has one bug, which is the thermal-aversion effect.

    (pad 7 thru_hole circle (at -3.81 6.35) (size 1.35 1.35) (drill 1.25) (layers *.Cu *.Mask)
      (net 1 +5V))
    (pad 7 smd rect (at -3.81 6.35) (size 2.5 1.5) (layers F.Cu F.Mask)
      (net 1 +5V))
    (pad 7 smd roundrect (at -3.81 6.35) (size 3.5 1.7) (layers B.Cu B.Mask)(roundrect_rratio 0.25)
      (net 1 +5V))

Testing some more, I find that this works, (size approaches 0) and improves the thermal-aversion effect.

    (pad 7 thru_hole circle (at -3.81 6.35) (size 0.001 0.001) (drill 1.25) (layers *.Cu *.Mask)
      (net 1 +5V))
    (pad 7 smd rect (at -3.81 6.35) (size 2.5 1.5) (layers F.Cu F.Mask)
      (net 1 +5V))
    (pad 7 smd roundrect (at -3.81 6.35) (size 3.5 1.7) (layers B.Cu B.Mask)(roundrect_rratio 0.25)
      (net 1 +5V))

and then even this seems ok (size=0) - gives no DRC failures & floods/routes OK

    (pad 7 thru_hole circle (at -3.81 6.35) (size 0.000 0.000) (drill 1.25) (layers *.Cu *.Mask)
      (net 1 +5V))
    (pad 7 smd rect (at -3.81 6.35) (size 2.5 1.5) (layers F.Cu F.Mask)
      (net 1 +5V))
    (pad 7 smd roundrect (at -3.81 6.35) (size 3.5 1.7) (layers B.Cu B.Mask)(roundrect_rratio 0.25)
      (net 1 +5V))

It may 'look' a little strange/counter-intuitive, it DOES seem to pass the DRC, and flood connect ok, and route ok !!.

The Thermal aversion effect is still there, and if you look carefully you can see Pin7.F.Cu has thermals that pull-up-short inside the drill.
(aversion effect here, seems to not be to the Drill, but the 0 size pad on *.Cu, which is needed to pass the DRCs)

I think if Cu clearance is always < PAD/2 this will be ok ? Should be true in most cases, leaving only rare thermal failures.

See attached test case, with attention to Pin7, that seems a workable hack ?

Even with this level of PADS stack support, KiCad looks usable, but I would describe that Thermal-aversion as a bug, as Thermals/Fill really should NOT be averse to the SAME NET entities.
ie Fill floods over traces fine now, & it should work equally _inside_ any PAD footprint.

That is probably simple to fix, as what it does now is superset-complex.
'Same Net' trumps entity found should fix it ?

Maybe this can change to a Thermal-aversion bug ? (given the stack workaround looks ok ?)

Hehe, this looks even stranger, but actually works better... (?!)

    (pad 7 thru_hole circle (at -3.81 6.35) (size -0.3 -0.3) (drill 1.25) (layers *.Cu *.Mask)
      (net 1 +5V))
    (pad 7 smd rect (at -3.81 6.35) (size 2.5 1.5) (layers F.Cu F.Mask)
      (net 1 +5V))
    (pad 7 smd roundrect (at -3.81 6.35) (size 3.5 1.7) (layers B.Cu B.Mask)(roundrect_rratio 0.25)
      (net 1 +5V))

That negative size seems to load/save ok and it subtracts from the thermal aversion.
I'm not sure using a negative size is a 'good idea', as it rather looks like an error.

Om the translator I work on, I may settle on a small, non zero pad, as that looks valid and deliberate.
Once the thermal aversion bug is fixed, this would not matter.

I can add a note to try negative sizes, if rare thermal non-connects show up.

More tests, and I can create PAD Stacks up to 5 deep, now with NET import passes, & DRC ok.

The PAD layering seems to work fine.

In most cases, the small size for the slug is enough, to connect, but there are some combinations of aspect ratio.geometry, that look to require a short (sub 1mm) Pad-Internal trace as a Patch for the Thermal-Aversion bug.

With that fix, the attached file passes DRC and NET import. (look for the very short traces)

Connect test seems to be NOT copper-correct, but is more Pad-internal than that.
That may be done for speed ?

@Wiz, thanks for the input. How did you do it? I tried to add a pin in Footprint Editor, and unticked Layers affacted (eg.
one pin for Copper= F.Cu only,
other pin for Copper B.Cu,
next pin is SMD Copper=none, and F.Mask on etc.

It is a bit tricky but workable way of creating different shape layers for a single pin.
May have a "default size pads on layers" checkbox (default on), and if unticked, tabular format should be better.

One more thing I have already done: creating complex shapes (e.g. on F.Cu) by drawing Graphics Lines, and move graphics lines to F.Cu layer. (see attached picture of the carbon paste keyboard connector image)

Now it seems this function is not "very far" from being workable..maybe worth working on it as it would be a huge advance!!

"How did you do it?"
I am writing a translator, so the PAD layering info comes from the other CAD tool (Mentor PADS), via SW.
I test for simplest stacks and those convert ok, but some do have differing Top/Bot Cu and also differing Mask and Paste.

Mask and Paste look ok, and even Top/Bottom I can get to have no DRC errors, except for the Connect Errors, caused by the shorter-thermals effects.
Those can be hacked, with a quite short trace (enough to jump the inner thermal gap, often inside the Drill). See last added image in thread https://forum.kicad.info/t/stunted-thermals/3510/5

I guess there are a couple of choices :
a) Fix Thermals, to remove unwanted inner gap, so Connect Check passes.
or
b) Modify Check, so any copper overlap is correctly identified as connected.
I guess that may be slower, present seems to check for something like direct-copper-path-to-PAD-centre

Possible Idea : A variant on b), that may not be too much slower, would be to treat inside-drill-radius, as 'pad reached', for Connect checks. (Drill geometry is simpler than Pad shapes.)

This may fix other mentions I've seen of false-no-connect reports ?

"Now it seems this function is not "very far" from being workable..maybe worth working on it as it would be a huge advance!!"

Yes, I think it is quite close. Maybe one line of code even...

I've run more tests, and there is a jump in action when Size moves from .001 to 0
At .001, there is what I've call correct Thermal on a layer, and because Thermals are more of a negative-operation, it is simpler if a size of 0 gives no thermal/fill action.
ie if you have two PADS trying to generate thermals, it gets tricky with who wins...

At size=0, the thermal spokes do go away, which is good, _but_ there is an unexpected cavity left behind.
I think that (unwanted) cavity is 'OR'-ing graphically as a void, as Thermals seem to generate by 'add-void' approach.

Given the jump in outcome, there _must_ be code now that tests for =0, but the decision is not quite right - it should _not_ generate the cavity around a 0 size Pad.

The fix is to do less, not more, in this special case.

Do you know which code handles thermal spokes, and (almost) manages the Size=0 case ?
I've done a quick search, and find some close code, but no bingo yet ?

I've added another test case to the Thread.
This shows that Connect-Test for _traces_, does seem smart enough to detect just PAD-Overlap (at least to trace centre / co-ord basis, which is ok ).

However, the copper that makes up the thermals, apparently does not use the same connect test ?
Thermals can well-overlap a PAD, and yet still fail-DRC-connect ?

This gives another possible short-term solution option, which is to fix Thermal-Connect, to be the same test as Trace-connect.
I think the unwanted/unexpected void on a Zero Size pad also needs fixing, but it comes down to what is easiest to do.

Pad stacks are on the v6 road map which should remove the need for hacky workarounds.

This will be fixed by lp:1827233.

Leaving as a non-duplicate for now as it refers to current behavior and might be fixed indepedently but should be closed when the linked bug is fixed.

The thermals issue has been fixed.

The DRC issue should be gotten around by giving each pad the same hole.

Fixed in revision 6da11de5e030509f4dfa3ff4d956099e67ce0f61
https://git.launchpad.net/kicad/patch/?id=6da11de5e030509f4dfa3ff4d956099e67ce0f61