I found another related problem with oval pads: tracks intersecting with oval pads are sometimes *not* detected as DRC violations.
Looking at the below screenshot or PCB, the narrow track should *but does not* trigger a DRC violation in its current position, while it does generate a violation if dragged 2mm down to intersect with the center of the large oval pad. I've linked a patch that fixes the issue. Board: http://u.forre.st/kicad_bug2/track_x_oval_pad_failure.kicad_pcb Board screenshot: http://u.forre.st/kicad_bug2/track_x_oval_pad_failure.png Patch (also below): http://u.forre.st/kicad_bug2/0001-Fix-track-rotated-oval-pad-collision-detection.patch As a related question, how hard is it to get committer access? I have several more minor fixes that I'd like to bring in. From ec6adcfb0d6b5583e132264cb84a3ba897a5da2b Mon Sep 17 00:00:00 2001 From: Forrest Voight <[email protected]> Date: Mon, 22 Jan 2018 13:50:33 -0500 Subject: [PATCH] Fix track/rotated oval pad collision detection --- pcbnew/drc_clearance_test_functions.cpp | 3 +++ 1 file changed, 3 insertions(+) diff --git a/pcbnew/drc_clearance_test_functions.cpp b/pcbnew/drc_clearance_test_functions.cpp index e395e7d..1ab6af0 100644 --- a/pcbnew/drc_clearance_test_functions.cpp +++ b/pcbnew/drc_clearance_test_functions.cpp @@ -1052,6 +1052,9 @@ bool DRC::checkClearanceSegmToPad( const D_PAD* aPad, int aSegmentWidth, int aMi { std::swap( padHalfsize.x, padHalfsize.y ); orient = AddAngles( orient, 900 ); + // recompute start/endPoint since they depend on orient + RotatePoint( &startPoint, m_padToTestPos, -900 ); + RotatePoint( &endPoint, m_padToTestPos, -900 ); } // here, padHalfsize.x is the radius of rounded ends. -- 2.7.4 On Sun, May 17, 2015 at 7:00 AM, jp charras <[email protected]> wrote: > Le 15/05/2015 23:12, Forrest Voight a écrit : >> (This is also at https://bugs.launchpad.net/kicad/+bug/1455345) >> >> Minimal example screenshot: http://u.forre.st/u/fiyaqxjg/drc.png >> Minimal example board file: http://u.forre.st/u/kjzegyao/drc.kicad_pcb >> >> Two pads (one a circle and one an oval) cause a false DRC violation in >> certain arrangements. >> >> I am reasonably certain that this is due to the rectangle part of the >> segment-oval test in DRC::checkClearanceSegmToPad. This function is >> called by DRC::checkClearancePadToPad with the circle pad having been >> transformed to a zero-length segment and the oval pad remaining as is. >> Then, DRC::checkClearanceSegmToPad looks at the oval pad as two >> circles and a rectangle, testing the segment against each, grown >> according to the segment's width and the clearance. The rectangle is >> grown at each end of its short axis by half the width of the segment >> (the radius of the circular pad in this case) plus the clearance >> (which makes sense) and grown at each end of its long axis by half the >> width of the segment (!!!). >> >> Growing the rectangular part of the pad along its long axis by >> anything is wrong because the dilation of a rectangle is a rounded >> rectangle, but by growing it along both axes, we form a shape that is >> bigger than what it should be (it has corners that shouldn't be >> there). We don't need to grow it along its long axis at all, because >> intersections near the ends of the pad are taken care of by the circle >> tests. >> >> A patch that fixes this issue, as I see it, is here: > > Good catch! > > I fixed that (using your patch) with a minor code cleaning in rev 5656. > > Thanks. > > > -- > Jean-Pierre CHARRAS > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
