DRC does not connect tracks that pass through pads rather than ending on them

[Strntydog]

Tracks which intersect with pads (but do not terminate at the anchor point of the pad) are listed as unconnected.

This is wrong from a physical model of the board, the Copper features overlap, and so they are "electrically" connected, and DRC should report them as such.

It is also inconsistent with DRC violations, which do obey copper connectivity, a track crossing a pad of another net, at any point will issue a DRC violation when checked.

There is an edge case where a track only slightly touches a pad, and is
electrically connected, but Not connected sufficiently for the design,
but that is not the same thing as being "unconnected" and isn't handled
by DRC now in any event.

There may be a requirement to report tracks which touch pads, but do not terminate on the anchor point of the pad, but that is a different requirement, and not the same as a track being unconnected.

Version:
Application: kicad
Version: no-vcs-found-e2505cb~60~ubuntu17.04.1, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.52.1 OpenSSL/1.0.2g zlib/1.2.11 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) librtmp/2.3
Platform: Linux 4.10.0-33-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    Curl: 7.52.1
    Compiler: GCC 6.3.0 with C++ ABI 1010

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

[Nick Østergaard (nickoe)]

Please provide demo file.

[Strntydog (strntydog)]

Modified version of previous example, showing the DRC error which results when the pad of a different net overlaps the track electrically. (But does not terminate on the track)

[Jeff Young (jeyjey)]

@Seth, there's also the related: https://bugs.launchpad.net/kicad/+bug/1571952

[Seth Hillbrand (sethh)]

Thanks for the heads up, Jeff; That one is actually fixed already -- hooray! :)

[Wayne Stambaugh (stambaughw)]

I just noticed this is in the 5.0 branch and as well and it makes routing really difficult. I'm not sure when this got broken. I'm raising the severity and the changing the milestone to 5.0.1.

[Wayne Stambaugh (stambaughw)]

This is not a bug per se. It appears that the recent options dialog work inadvertently clears or resets the magnetic pads option. To fix this just open the pcbnew options dialog and enable the magnetic pads option. @Jeff, you might want to take a look at the pcbnew options dialog to prevent this from happening or I see a lot more bug reports in our future.

[Wayne Stambaugh (stambaughw)]

I'm going to change the severity and the milestone since technically it only effect the development branch event though can effect previous versions.

[Jeff Young (jeyjey)]

@Wayne, I can’t reproduce the Magnetic Pads option getting reset. Are there steps to cause it to happen?

> On 19 Jul 2018, at 19:04, Wayne Stambaugh <email address hidden> wrote:
>
> This is not a bug per se. It appears that the recent options dialog
> work inadvertently clears or resets the magnetic pads option. To fix
> this just open the pcbnew options dialog and enable the magnetic pads
> option. @Jeff, you might want to take a look at the pcbnew options
> dialog to prevent this from happening or I see a lot more bug reports in
> our future.
>
> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/1718831
>
> Title:
> DRC does not connect tracks that pass through pads rather than ending
> on them
>
> Status in KiCad:
> Triaged
>
> Bug description:
> Tracks which intersect with pads (but do not terminate at the anchor
> point of the pad) are listed as unconnected.
>
> This is wrong from a physical model of the board, the Copper features
> overlap, and so they are "electrically" connected, and DRC should
> report them as such.
>
> It is also inconsistent with DRC violations, which do obey copper
> connectivity, a track crossing a pad of another net, at any point will
> issue a DRC violation when checked.
>
> There is an edge case where a track only slightly touches a pad, and is
> electrically connected, but Not connected sufficiently for the design,
> but that is not the same thing as being "unconnected" and isn't handled
> by DRC now in any event.
>
> There may be a requirement to report tracks which touch pads, but do
> not terminate on the anchor point of the pad, but that is a different
> requirement, and not the same as a track being unconnected.
>
> Version:
> Application: kicad
> Version: no-vcs-found-e2505cb~60~ubuntu17.04.1, release build
> Libraries:
> wxWidgets 3.0.2
> libcurl/7.52.1 OpenSSL/1.0.2g zlib/1.2.11 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) librtmp/2.3
> Platform: Linux 4.10.0-33-generic x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
> Boost: 1.62.0
> Curl: 7.52.1
> Compiler: GCC 6.3.0 with C++ ABI 1010
>
> 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
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1718831/+subscriptions

[Jeff Young (jeyjey)]

In my build the settings get read from and written to:

MagneticPads=2
MagneticTracks=2

in preferences/kicad/pcbnew.

(I suspect that path is somewhat OSX-speific, but the filename is probably the important part.)

The keys don’t appear to have changed from 4.0.7. And I think they’re in the same file, although I don’t have a copy of 4.0.7 to check.

> On 19 Jul 2018, at 21:31, Jeff Young <email address hidden> wrote:
>
> @Wayne, I can’t reproduce the Magnetic Pads option getting reset. Are there steps to cause it to happen?

[Seth Hillbrand (sethh)]

Hmm... Can we split off the magnetic pads issue? This report is about connectivity not seeing collisions between pads and tracks that don't have anchor points overlapping.

[Wayne Stambaugh (stambaughw)]

Sorry about that Seth. I misread the bug report. I'll create a new bug
report for the magnetic pads issue.

On 07/19/2018 04:56 PM, Seth Hillbrand wrote:
> Hmm... Can we split off the magnetic pads issue? This report is about
> connectivity not seeing collisions between pads and tracks that don't
> have anchor points overlapping.
>

[Seth Hillbrand (sethh)]

I'm going to move this issue to 6 as the quick-ish fix causes massive slowdown in routing and the fixes I can think of for faster routing are not simple.

[Nathael Pajani (nathael-pajani)]

Hi !

Thanks for your work on this :)

Having these kind of tracks is not common (I only have two designs concerned in about one
hundred), so it may be acceptable to have it as an option, with a comment stating that by
activating the option the routing will be slower.
It will also allow the user to activate it for checks, and de-activate it during the
design process.
This is only a proposal, I don't know how much work this would be, so maybe it's not a
good idea.

Thanks a lot to all of you :)

On 18/12/2018 05:08, Seth Hillbrand wrote:
> I'm going to move this issue to 6 as the quick-ish fix causes massive
> slowdown in routing and the fixes I can think of for faster routing are
> not simple.
>
> ** Changed in: kicad
> Milestone: 5.1.0 => 6.0.0-rc1
>

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/1769