X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc;
	bh=uF32p0y1GkgY1d0EFvWnyQOSusl9TVkwrMWrxU+zQXg=;
	b=IlMrujdNIyyQeFhEJedbML/lEnMY9B7bcWMFEasp1pAI1LGBvXSdoxSbIODLZKTC2e
	5fKGkE0Ys4O9YmZH5ajzO0hUcrPuEOZ5PoeXI9v4HpYxfsGkMiUA1RqAiR+u4+xo0leI
	UnN9XpnDZs2vOMiWahE3aFpkQqz/lpmTGnXK7njCPtYtvLLdERW4kC8RR0Ku/LvoCAQB
	Up0T5bI2fkgWWtC9+id51gOEnBwJ/YkFkw7xvEqVk6MlVVMYY73PSEDuVgLhsIY/daX7
	At8HDY8jIK/bP8N0ciwJEvIF1alm6WaCzJYPYGyX6lqSgfi0C8kSt0DzQcVpr43zrvsu
	yj8A==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=uF32p0y1GkgY1d0EFvWnyQOSusl9TVkwrMWrxU+zQXg=;
	b=rfofz/eHVJppnzNo1Gf0ICftC1xiEbI5Bbjca0I39eu3a3E0b099q4U8ySF88WjrKG
	jk3A9JN4sT7AaInHi1GxsdoJA+yBZTurb1PPKUCBfF0wF5gB68CRQiNIn/QEa3zoB+CD
	dWb2S3fM1ttsySt4yLV33+6/jTDzROMUxeQWuEtm5HsvDfbMMcBl48G41snJhaJEXMVf
	uZL/lp8u82BkHADsJYrk/vTVSWGhJbtFS9qjP3cLl503gCwnxumoW/yvRHyf3c78uJHT
	tC8tqqTjbl38tphU+fY0Dc3XQeYIr3QGofGYWdE1Mb5FXYzkiQ9moP4qYrlzxGAhS6wm
	aHew==
X-Gm-Message-State:	AOUpUlEzy+h8K1EJPTo2XFyNB2Ls2qPtK3SNOx9rMxTQ1zu8Wtb85BLF
	nwbulc85ABYDCEWq7F0MGWEwIMkaNz7+7E2C+ww=
X-Google-Smtp-Source:	AAOMgpdHD6BP+4YvcbgROpNzBWt7gARcRNai4/Ur7Pcs2L3k5LGk17lkDCkmhoBxEG6EFw6heBEniHXt/QLpEesjV+w=
X-Received:	by 2002:a63:7454:: with SMTP id e20-v6mr10670121pgn.410.1531597563956;
	Sat, 14 Jul 2018 12:46:03 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<CAGqyy=b0L49LYm_gfpJ_m9agJjtjSVPq50Ofvff-unSXkxmkyA@mail.gmail.com>
References:	<CAGqyy=b0L49LYm_gfpJ_m9agJjtjSVPq50Ofvff-unSXkxmkyA AT mail DOT gmail DOT com>
From:	"Chad Parker (parker DOT charles AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date:	Sat, 14 Jul 2018 15:46:03 -0400
Message-ID:	<CAJZxidD8pp95ZiS7aWkxBbT7NuJDviJ2NNsYGdvbnw-4xzHqtw@mail.gmail.com>
Subject:	[geda-user] Re: DRC clearance bugs
To:	Luis de Arquer <ldearquer AT gmail DOT com>
Cc:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

--000000000000bd116a0570fad833
Content-Type: text/plain; charset="UTF-8"

Hi Luis-

Thanks a lot for your 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 you've been following:

First, report the bug on LaunchPad or to the mailing list. It's best to
include a pcb file that 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 helpful in getting the senior devs to review the issue, so,
thanks a lot for providing 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 it in the git repo. We don't always
get notified by LaunchPad, so, it's a good idea to also ping the mailing
list.

Third, it will be reviewed by the devs. Depending on the complexity of the
issue/patch and the severity of the bug, it could take a while to review.
We have pretty limited manpower these days (applications welcome!), so, the
easier you can make it for us to review, the better, and the faster it is
likely to get solved.

Fourth, once the patches are good and have been tested and accepted, they
will get pushed into the master 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 com> wrote:

> Chad -and everyone,
>
> 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:
>  - A line may belong to the same net than the polygon, even though it
> has the "clearline" set (e.g. a third line connects each other)
>  - 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 there 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:
>  - Any help confirming these issues is welcome (even just confirming
> the bug on the three attached files)
>  - Any thoughts/discussion about the proposed solutions would be very
> healthy too.
>  - What is the normal workflow to publish the patches, so they are
> included asap in mainline?
>
> Regards,
> Luis
>

--000000000000bd116a0570fad833
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Luis-</div><div><br></div><div>Thanks a lot for yo=
ur work on this! The work you&#39;ve done in identifying the source of the =
problem is very helpful, and will help us review the issue/patch much more =
quickly.<br></div><div><br></div><div>The process is generally that which y=
ou&#39;ve been following:</div><div><br></div><div> First, report the bug o=
n LaunchPad or to the mailing list. It&#39;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&#39;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.</div><div><br></div><div>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&#39;t always get notified by LaunchPad, so, it&#3=
9;s a good idea to also ping the mailing list.</div><div><br></div><div>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. <br></div><div><br></div><div>Fourth, once the patches ar=
e good and have been tested and accepted, they will get pushed into the mas=
ter branch.</div><div><br></div><div>Again, thanks for your work on this. I=
&#39;ll try to review your patches this weekend. If you have any other info=
 about this bug, please post it to LaunchPad.<br></div><div>--Chad<br></div=
><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Sat, Jul 14, 2018 at 3:14 PM, Luis de Arquer <span dir=3D"ltr">&lt;=
<a href=3D"mailto:ldearquer AT gmail DOT com" target=3D"_blank">ldearquer AT gmail DOT co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Chad -and everyon=
e,<br>
<br>
I have been diving a bit more into the DRC clearance issues on<br>
launchpad, and I found that the problem is bigger than I thought. The<br>
same problem is present in pcb-rnd.<br>
<br>
The DRC clearance-check works in three steps (this is line to polygon,<br>
but arc and pad to polygon is probably the same)<br>
<br>
1. Check whether bounding box of the line overlaps the polygon<br>
2. If so, check if they are joined or separated.<br>
3. If they are separated, check the clearance between them.<br>
<br>
This scheme looks fine to me, except on how it is executed:<br>
<br>
1. The bounding box used for checking the overlap is the line&#39;s<br>
regular bounding box. This bounding box is built with [line thickness<br>
+ line clearance]. This is wrong. It should be made with [line<br>
thickness + *DRC clearance*]. The consequence is missed errors in DRC.<br>
<br>
2. In order to check whether the line and polygon are joined or<br>
separated, the &quot;clearline&quot; [J] flag on the line is checked. This =
is<br>
wrong too, because false positives and negatives exist:<br>
=C2=A0- A line may belong to the same net than the polygon, even though it<=
br>
has the &quot;clearline&quot; set (e.g. a third line connects each other)<b=
r>
=C2=A0- A line may not join the polygon, even with the clearline unset. For=
<br>
example, when other elements (vias, etc) clear the polygon around.<br>
<br>
3. Once the line is considered to plow the polygon, the DRC checks the<br>
clearance setting on the line (line-&gt;Clearance). This may create false<b=
r>
positives, because there may be other elements clearing the polygon,<br>
or the line may be at a corner of the polygon. This is the bug i fixed<br>
in <a href=3D"https://bugs.launchpad.net/pcb/+bug/746178" rel=3D"noreferrer=
" target=3D"_blank">https://bugs.launchpad.net/<wbr>pcb/+bug/746178</a><br>
<br>
I have attached three PCB examples, showing the three bugs separately.<br>
Most, if not all, the polygon to line/arc/pad bugs in launchpad are<br>
variants of these three.<br>
<br>
I think the solution is:<br>
<br>
1. Use the DRC setting to build the line bounding box, not its own<br>
clearance setting.<br>
<br>
2. Forget about the &quot;clearline&quot; flag. Instead, check whether ther=
e is<br>
electrical connection between the line and the polygon. Only if they<br>
are (directly or indirectly) connected, skip it. If there is an<br>
accidental, small connection betwen them though, it won&#39;t show up in<br=
>
DRC, but updating the rat nest will do (this is consistent with the<br>
overall behaviour of how DRC/rats work).<br>
<br>
3. Once the line is considered to plow the polygon, bloat the line<br>
with DRC clearance, and use IsLineInPolygon() for an exhaustive test.<br>
This uses the real shape of the line and the polygon, and should not<br>
throw any false positives.<br>
<br>
I have corrected 1 and 3 in my local tree, as I need it for our PCB<br>
production (and verified 2 does not affect me). I will try to fix 2<br>
asap.<br>
<br>
Couple of requests/questions:<br>
=C2=A0- Any help confirming these issues is welcome (even just confirming<b=
r>
the bug on the three attached files)<br>
=C2=A0- Any thoughts/discussion about the proposed solutions would be very<=
br>
healthy too.<br>
=C2=A0- What is the normal workflow to publish the patches, so they are<br>
included asap in mainline?<br>
<br>
Regards,<br>
Luis<br>
</blockquote></div><br></div>

--000000000000bd116a0570fad833--

- Raw text -