Hi Luis-

Thanks a lot for yo= ur work on this! The work you've done in identifying the source of the = problem is very helpful, and will help us review the issue/patch much more = quickly.

The process is generally that which y= ou've been following:

First, report the bug o= n LaunchPad or to the mailing list. It's best to include a pcb file tha= t can be used to demonstrate the behavior, as well as other things like the= version of pcb you're using, operating system, etc. This is very helpf= ul in getting the senior devs to review the issue, so, thanks a lot for pro= viding the files.

Second, if you have a patch, you= can upload it, again to the mailing list and/or LaunchPad. The senior devs= will check it out and give you some feedback on it, or accept it and put i= t in the git repo. We don't always get notified by LaunchPad, so, it= 9;s a good idea to also ping the mailing list.

Thi= rd, it will be reviewed by the devs. Depending on the complexity of the iss= ue/patch and the severity of the bug, it could take a while to review. We h= ave pretty limited manpower these days (applications welcome!), so, the eas= ier you can make it for us to review, the better, and the faster it is like= ly to get solved.

Fourth, once the patches ar= e good and have been tested and accepted, they will get pushed into the mas= ter branch.

Again, thanks for your work on this. I= 'll try to review your patches this weekend. If you have any other info= about this bug, please post it to LaunchPad.

--Chad

On Sat, Jul 14, 2018 at 3:14 PM, Luis de Arquer <= ldearquer AT gmail DOT co= m> wrote:

Chad -and everyon= e,

I have been diving a bit more into the DRC clearance issues on
launchpad, and I found that the problem is bigger than I thought. The
same problem is present in pcb-rnd.

The DRC clearance-check works in three steps (this is line to polygon,
but arc and pad to polygon is probably the same)

1. Check whether bounding box of the line overlaps the polygon
2. If so, check if they are joined or separated.
3. If they are separated, check the clearance between them.

This scheme looks fine to me, except on how it is executed:

1. The bounding box used for checking the overlap is the line's
regular bounding box. This bounding box is built with [line thickness
+ line clearance]. This is wrong. It should be made with [line
thickness + *DRC clearance*]. The consequence is missed errors in DRC.

2. In order to check whether the line and polygon are joined or
separated, the "clearline" [J] flag on the line is checked. This = is
wrong too, because false positives and negatives exist:
=C2=A0- A line may belong to the same net than the polygon, even though it<= br> has the "clearline" set (e.g. a third line connects each other) =C2=A0- A line may not join the polygon, even with the clearline unset. For=
example, when other elements (vias, etc) clear the polygon around.

3. Once the line is considered to plow the polygon, the DRC checks the
clearance setting on the line (line->Clearance). This may create false positives, because there may be other elements clearing the polygon,
or the line may be at a corner of the polygon. This is the bug i fixed
in https://bugs.launchpad.net/pcb/+bug/746178

I have attached three PCB examples, showing the three bugs separately.
Most, if not all, the polygon to line/arc/pad bugs in launchpad are
variants of these three.

I think the solution is:

1. Use the DRC setting to build the line bounding box, not its own
clearance setting.

2. Forget about the "clearline" flag. Instead, check whether ther= e is
electrical connection between the line and the polygon. Only if they
are (directly or indirectly) connected, skip it. If there is an
accidental, small connection betwen them though, it won't show up in DRC, but updating the rat nest will do (this is consistent with the
overall behaviour of how DRC/rats work).

3. Once the line is considered to plow the polygon, bloat the line
with DRC clearance, and use IsLineInPolygon() for an exhaustive test.
This uses the real shape of the line and the polygon, and should not
throw any false positives.

I have corrected 1 and 3 in my local tree, as I need it for our PCB
production (and verified 2 does not affect me). I will try to fix 2
asap.

Couple of requests/questions:
=C2=A0- Any help confirming these issues is welcome (even just confirming the bug on the three attached files)
=C2=A0- Any thoughts/discussion about the proposed solutions would be very<= br> healthy too.
=C2=A0- What is the normal workflow to publish the patches, so they are
included asap in mainline?

Regards,
Luis

--000000000000bd116a0570fad833--