pad-to-poly DRC

[Ineiev]

First reported at http://archives.seul.org/geda/user/Feb-2011/msg00335.html:

DRC misses pad-to-polygon minimum spacing errors due to buggy find.c:IsLineInPolygon().

[Ineiev (ineiev)]

This is a suggested fix. To be comfirmed by anybody and reviewed by a senior PCB developer.

[Peter Clifton (pcjc2)]

Looks ok in principle to me, my main concern was clarity of the existing code:

 SquarePadPoly (PadType * pad, BDimension clear)
...
+ /* the pad is shrunk rather than bloated */
+ if (halfclear < halfthick)
+ halfthick = halfclear;

Obviously "clear" was used, because this function was originally responsible for making the polygon shape of a pad clearance. -ve clear is not the most obvious concept here - but "bloat" doesn't necessarily seem clearer either.

I guess the DRC sometimes calls with a -ve clear value to test for disconnection due to shrink - IE.. checking component overlap is sufficient?

I'm not 100% sure about this code:
+ if (halfthick < halfclear)
+ frac_circle (contour, (t->Point1.X - tx), (t->Point1.Y - ty), v, 4);

Presumably it is the radius of the curve which is the ultimate yes / no for adding a radiused corner here. I think that for clear=0, that should be zero, and the radius not drawn - which I'm not sure is caught here).

Would it be possible to test the radius? That might be clearer.

[Peter Clifton (pcjc2)]

Am I correct in thinking "SquarePadPoly" will create a polygon with rounded corners for "clear" > 0, and with square corners with clear <= 0 ? I'm a tiny bit uneasy about this, but I can't put my finger on why.

Perhaps we should make the primitive function more explicit - a box (or square?) of a particular size, with a particular corner radius. The various places which need such a shape could then call this more explicit function without it looking too strange.

Obviously the function would have radius=0 as the lower limit (-ve radiuses would be illegal). Would this help to clarify the existing code?

[Ineiev (ineiev)]

Now "clear" in SquarePadPoly has the same meaning as "thick"
in LinePoly(); it is the "width" of the resulting "rounded rectangle".

The pad is "shrunk" when its halfclear is less than halfthick.

Of course, this argument can be replaced with "radius"; it is called
from single place in LinePoly(); the argument and the function itself
could be possibly renamed, but I don't think that prohibiting negative
values would be the right thing: in this case the code would be
(unnecessarily IMO) duplicated.

[DJ Delorie (djdelorie)]

What does it mean to have a pad with negative clearance to a polygon?

Note on copper vs mask clearance:

Clearance to copper uses rounded edges because of the types of
inaccuracies in copper etching; absolute distance is the key factor in
determining yield, not direction. See also:
http://www.delorie.com/pcb/notches.html

Mask clearance uses square edges because the inaccuracies are caused
by registration issues, where X and Y errors are independent.

Yes, I asked one of the fab techs that question :-)

[Ineiev (ineiev)]

To have a pad with negative clearance to a polygon means that we check for minimum connection width
rather than minimum distance (the call comes from find.c);
I'm not sure it would be absolutely correct to check minimum connection
width with this method, but this is how it is implemented now.