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

Bug #1718831 reported by Strntydog on 2017-09-22
46
This bug affects 7 people
Affects Status Importance Assigned to Milestone
KiCad
Medium
Seth Hillbrand

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

Jeff Young (jeyjey) on 2018-02-20
summary: - DRC does not properly check connectivity of tracks and pads
+ DRC does not connect tracks that terminate on pads but not at their
+ centre.
Changed in kicad:
status: New → Triaged
importance: Undecided → Medium
Strntydog (strntydog) wrote :

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)

Seth Hillbrand (sethh) on 2018-06-23
Changed in kicad:
assignee: nobody → Seth Hillbrand (sethh)
milestone: none → 5.1.0
Jeff Young (jeyjey) wrote :

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

Seth Hillbrand (sethh) wrote :

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

Seth Hillbrand (sethh) on 2018-07-19
summary: - DRC does not connect tracks that terminate on pads but not at their
- centre.
+ DRC does not connect tracks that pass through pads rather than ending on
+ them
Wayne Stambaugh (stambaughw) wrote :

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.

Changed in kicad:
importance: Medium → High
milestone: 5.1.0 → 5.0.1
Wayne Stambaugh (stambaughw) 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.

Wayne Stambaugh (stambaughw) wrote :

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

Changed in kicad:
importance: High → Medium
milestone: 5.0.1 → 5.1.0

@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

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) 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.

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) 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

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
>

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers