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=9CMqF7SgEahFpNbE/JUVVOcE5/F3e8k5XVr3OC2yoh4=;
	b=UH6oILgAypGzitHCsJ6+8EVXiJsLujHWBw3ZNDuwtOSlUpe1VjOmCNQ/29dQ/79X8r
	OYiRRQ1SKLOv65QNFnHuA3waDrjL5OAmHVnA0tZxMXR+6MgCttg3W9jMQiBj5qJCmv+B
	Q5xBS5aKpQJ/myMkYSQJoilUwHGUJImBOLpBlHINDJvWoKUsNF32TD83x8Z1GZ+j0kgj
	tFUeBn5cA9ISy5H6VgHza0q4nWD+J2qaHYFIttUfzCW8Skdbe0bRIH7vcf1VvBgoSW5V
	z9C9FJ/yUjtAxFdAp8iMZ3+43doX48pPAWk8ODpg7+oZxGtxep3TrY/0hv4L48xe92YF
	pOFg==
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=9CMqF7SgEahFpNbE/JUVVOcE5/F3e8k5XVr3OC2yoh4=;
	b=j4/QdIUUIyeUx22NsROvuDnBrEODijP+TlEvIkNifq3cm1MK/wiAr4yjuxqOndtxna
	6RSXymaRwYgBsX9JrGA9ALGuoH/DMHSXmwRpWlY4fgj9r3MNrKB+nintn4b9PaOKPJjG
	4/khFfjsTU2FhAKwEIwXR3AbaxxASBLRm7Md0imrN1PheuHDbUuqJUbhGvIN6Jj8Tl2T
	nu8ijBhYrA44kO9InSKVKrCAdgSAX40JzaguvWt7/0VeJfer6IwAHtvMHPuDE/Mr7Li1
	aE44L9nQOpRNgwXQXLREfH5y6EFcv4VYWJyWGF34pBkyqDXmKJBlkijTby1RE2h5dDMf
	75Fw==
X-Gm-Message-State:	AOUpUlEoyObi43ObkTlQ6EF0UeehNG3NZYTjLTAcgfPcpFb9zpuZfI7s
	4N5hS71mMR+1Qi7Gvun9QzWJfubpzAv6Zhs66uU=
X-Google-Smtp-Source:	AAOMgpe5KJeAB7zAdU+86tDS/jdVgyAq35rpruKhCQ7dZzmBQe43qlkZFbbhWbskEhpB+mH82caAY85IJO834bf9lIY=
X-Received:	by 2002:aca:3a03:: with SMTP id h3-v6mr13132268oia.270.1531641827077;
	Sun, 15 Jul 2018 01:03:47 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<CAJZxidDfkOyf5pbbuS5nj2RCN9hdWjoNKm=PFWMSJRb5PP1p6w@mail.gmail.com>
References:	<CAGqyy=b0L49LYm_gfpJ_m9agJjtjSVPq50Ofvff-unSXkxmkyA AT mail DOT gmail DOT com>
	<CAJZxidDfkOyf5pbbuS5nj2RCN9hdWjoNKm=PFWMSJRb5PP1p6w AT mail DOT gmail DOT com>
From:	"Luis de Arquer (ldearquer AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date:	Sun, 15 Jul 2018 10:03:46 +0200
Message-ID:	<CAGqyy=beSDq0pKJzV5x+5idycvHRkh2ATX6YvQDoXjj3DoAp3w@mail.gmail.com>
Subject:	[geda-user] Re: DRC clearance bugs
To:	Chad Parker <parker DOT charles AT gmail DOT com>
Cc:	geda-user <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

Hi Chad

2018-07-15 1:04 GMT+02:00, Chad Parker <parker DOT charles AT gmail DOT com>:
> Luis-
>
> I'm looking at your examples, and I want to restate what's happening to
> make sure that I understand the issues.
>
> clearance1.pcb: I see a clearance of 10.5 mils. Minimum copper spacing is
> set to 20 mils, so, this should be flagged and isn't. This is happening
> because the polygon clearance of the line is set to 10 mils. When the DRC
> tests for overlaps, the bounding boxes of these two objects don't overlap
> because the effective bounding box for the line is computed using the line
> width + the polygon clearance. Since the polygon clearance is less than the
> DRC clearance, the line can be within the DRC clearance and overlooked by
> the DRC.

Right

>
> clearance2.pcb: I see a clearance of 12.9 mils. This should be flagged, but
> isn't. This one isn't flagged because the "clearline" flag is not set.
> Without this flag, PlowsPolygon:polygon.c doesn't test for overlaps In this
> case, the via is clearing the polygon. If the "clearline" flag were to be
> set, it would erase those edges, and not be a problem. The trace doesn't
> actually have to even run into the polygon for this to be an issue. If the
> clearline flag isn't set, the end of the trace can get arbitrarily close
> without triggering the DRC.

Yes

>
> The point of these flags are to tell pcb that the object should or should
> not be connected to the polygon, so, pcb thinks that they are intentionally
> connected, and thus not a violation. Technically, we shouldn't care if
> there's a copper bridge between the two objects, because they are supposed
> to be connected. In a sense, we've lied to the software, and that's why
> this error isn't flagged. I'm not sure what the best way to deal with this
> is.
>
> clearance3.pcb: I see a clearance of 26.5 mils. This should not be flagged,
> but it is. In this case, the polygon is actually cleared by the via,
> preventing the clearance problem, but the DRC isn't considering clearance
> created by other objects when it does its testing.
>

Right too.

> Now, regarding the solutions you propose.
>
> 1. I think we would only want to use the DRC value during the DRC. I don't
> think it's a good idea to change how the bounding boxes are computed. It
> seems to me like that could have a lot of consequences that are not
> immediately apparent. Until the algorithms are better documented and we
> really understand how that would effect the rest of the codebase, I'm
> reluctant to do that.
>
> Given that, the minimum solution I can think of that would solve this this
> particular case is to add a couple of lines in DRCAll to compute a new
> bounding box that uses the DRC clearance, save the old one, install the new
> one in the line structure before calling PlowsPolygon, and then restores
> the original one after the call. This is clearly a hack, but it would do
> the job.
>

That is my fix actually! Change things locally, and restore them right
after the test.

> The REAL solution to this problem would be to actually have the DRC look at
> the distances between copper objects. Right now, it seems that pcb doesn't
> actually check the distances between nearby traces for copper spacing
> violations. Such a routine would need to look at the separation between
> lines, arcs, and polygons. It looks like there is a check for lines and
> vias.

I am not too sure about this, but I think the problem exists only for
elements to polygon clearance. I think line to line, line to pad etc
is done properly.

>
> 2. I think that I like this solution, but I'm not sure how hard it will be
> to implement. The netlist part of pcb is not a part that I've really dug
> into yet, so, my first impression is that it wont be very easy. If you
> think you can make this work, I would love to see the patch.
>

I would love to see such a patch too :) I don't have much idea about
how netlist works either. I had a quick look at the Lookup functions
in find.c, maybe one of them could be used, but ideally we could use
the already calculated connections so the work doesn't need to be
repeated.

> 3. I think this solution is okay. I wonder if we should try to use
> IsLineInPolygon sooner? The patch that you put up on LaunchPad seems to
> work, although I'm not sure I understand why. It looks like IsLineInPolygon
> only considers lines of which the bounding box is completely enclosed by
> the polygon.

I considered that too. However, bug #3 (using line clearance setting
for DRC decision) only throws false positives, so worth doing it to
rule out as much as possible before doing the expensive
IsLineInPolygon test. That is, if clearance is set, and is bigger than
DRC clearance, then we can be sure there is no DRC violation. It is
the converse that is not necessarily true. (Note: as Igor2 pointed
out, we need to make sure that both *line* and *polygon* clearance
flags are set)

>
> The code formatting of your patch is inconsistent with the style of the
> surrounding code. So, we'll at least have to update that before we can pull
> the patch into master.
>
My bad, I'll fix it

Luis

- Raw text -