DRC issue or 3D render issue

[shoka]

I think I’ve found a minor bug in the DRC. At least I think the DRC is the item at fault.

Background

I have a custom footprint pad definition made up of two pads, a through hole pad on both copper sides, and a through hole pad defined with a custom circular anchor, and some custom shape primitives to make an asymmetrical pad on the B side, for easy soldering.

The set up works practically, and plots as expected, I’ve used it extensively.

Problem

If I define the B side as an SMD type, the 3D viewer renders the back of the board without the hole. If I define it as a through hole pad, unsurprisingly it renders the through hole correctly.
This may be considered a limitation of the 3D viewer, as I guess the through hole pad should take priority over the SMD pad.

However set up like this the DRC reports errors as the graphic. (How do you/can you cut and past DRM error reports as text?)

I can switch those errors on and off by changing the definition of the B side pad to SMD and restore the DRC error by switching it to through hole.

However the error is only present when a front side track is attached to the pin. Moving the connection to the B side also removes the error report.

And restores it when the track is returned to the front side.

This is clearly not a fatal error, I can live with the incorrect 3d Render, or ignore the DRC error.

It’s sufficiently subtle though, that it may be of interest.

Harry

Version and host info

Application: KiCad
Version: 5.1.6-c6e7f7d~86~ubuntu18.04.1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-109-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
Boost: 1.65.1
OpenCASCADE Community Edition: 6.9.1
Curl: 7.58.0
Compiler: GCC 7.5.0 with C++ ABI 1011

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

Host: Thinkpad Kernel: 4.15.0-109-generic x86_64 bits: 64 compiler: gcc v: 7.5.0
Desktop: Cinnamon 4.4.8 wm: muffin dm: LightDM Distro: Linux Mint 19.3 Tricia
base: Ubuntu 18.04 bionic

[nickoe]

Could you please attach a test board?

[eelik]

Do both pads, the SMD and the through hole, have the same pad number?

[halachal]

This sounds pretty reasonable. You have a through hole pad that’s technically not connected to your trace, so DRC complains.

[halachal]

Similarly, the 3D renderer sounds like it’s working properly to me. When you force an SMD pad on top of the through hole, your gerbers have copper over that hole and it’s either cleaned up by your manufacturers software or they just drill through it…

[shoka]

Yes. They should be seen as one pad. That’s the puzzle.

[Rene_Poschl]

Easiest option would be to just share the footprint

[shoka]

Demo board that shows the issue.
demo.zip (4.3 KB)

Harry

[Seth_h]

What happens when you uncheck “Show solder paste layers” in the 3d viewer?

Usually, you do not want solderpaste on a through hole.

[shoka]

That improves the render issue. When you switch from through hole to SMD, the pad defaults to front side copper, front side mask and front side paste. I failed to notice the added paste layer when I moved the pad back to the backside of the board :(. Thanks. Removing that paste layer in the pad definition corrects the render. Still have the DRO issue though.

[eelik]

You have two THT pads. Make the one with the custom shaped copper SMD. The THT pad should have copper in “All layers”.

[nickoe]

@shoka, what verison of kicad are you using?

I tested with Version: (5.99.0-2260-g7201e9d7e), release build and there is no DRC errors.

[Rene_Poschl]

I see an error in 5.1.6. Strangely however only on Conn3

[Rene_Poschl]

Found the issue. Con3 and Con2 define the bottom only pad as THT. Con1 does not do that (it is defined as SMD as it should be). Which is why only Con1 is OK if one connects a trace on the top layer.

[shoka]

“As it should be” was not immediately obvious to me. I agree that is what is triggering the issue, but why is it an issue? I want a THT pad with different copper at both ends. Why does the DRO have a problem if its specified as exactly that? Anyway its a “feature” of the DRO, its not hard to live with if you know its going to happen.

Harry

[Rene_Poschl]

The real short answer is: what you want is not directly supported by KiCad (it would require a full pad stackup management that is planned for some future release).

Until this comes we need to use workarounds. A workaround always comes with restrictions.
In this case the restriction simply is that through hole pads placed on only a single layer result in strange behaviour. To be honest i would say this can be expected as a through hole pad does not make sense to be placed on only a single layer. The fact that kicad does not prevent you from doing this could be considered a bug. Or one could say DRC must support anything that can be defined which would mean the bug is in DRC not the footprint editor.

[shoka]

Thank you Rene. I started this thread because I thought that I’d come across a case that the DRO did not cope with, and where the error generated was far from clear. That it is a known limitation is now clear. I’ve been following the plans for V6 and have seen discussion of pad stack management among those discussions, so I’m aware that there are limitations. I do not need more from Kicad than its presently capable of, when I understand the limitations. Kicad has improved by leaps and bounds in the time I’ve been using it, it is already incredibly effective.

Showing off what you can achieve even with the present version of Kicad. (Heatsink/pad for a SMB FET.

Harry

demo2.zip (6.3 KB)