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=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=FVl62Lir2NpLLe2KWIPsbBgmlnRk7iRiYS0ss+LHknA=;
        b=INAmAmrsV1ZzWUHkKSuE+Pma59LOChmRCa5YnbGFUZiuc/qk02vU6r8xqYVRaGopY7
         O/kod/IOZhojyceboS3DzxAPbRpzdYX/hHV56Tlkuvxia1eVM85RdZrZ16lq/Srx0WmO
         V4bgdCyXlo1XE2nKOljVp9Kkz/Dsf4yqRmMIp3rNvusZ65W6vnsbAoGVSv8AGuCLIzWz
         OTVRfwpQEQdRKZ2fdzBA2xm5+wmMzOw7E3QRuzUKyAA4vr2vAUnLS/jEROHFGGwfGgey
         m4YAo+OCKkKQiQ0kHOaiouv7r5wdu3e/wSayWu6eDvnmZxsE708InX9QVnorUluMKZTm
         OvHA==
MIME-Version: 1.0
X-Received: by 10.28.3.133 with SMTP id 127mr32774579wmd.101.1450836301516;
 Tue, 22 Dec 2015 18:05:01 -0800 (PST)
In-Reply-To: <CAJXU7q8pAStTq6yTq6wOP4=MWBGfURP_KvdEYv-npLmRBmPufA@mail.gmail.com>
References: <CAOFvGD6OiYxcGkOiQRVnvXW3TLs42bt7PE5Ot9s09hsukYicKA AT mail DOT gmail DOT com>
	<20151221030451 DOT 02399163eb3e40f21c622c41 AT gmail DOT com>
	<CAOP4iL1PTdeCZdT+SthHwQtaxC4x06MbBQmxRcK3DZyQ-jfw=Q AT mail DOT gmail DOT com>
	<20151221203331 DOT 20837 DOT qmail AT stuge DOT se>
	<CAJXU7q_XOJStJXhD547xW-+XROkBhctmMAWB-jm0cez5UvgZ7w AT mail DOT gmail DOT com>
	<CAOP4iL1ri4UMeYr01Af-AH005DkLboKO72nGao+ByGmqA51W-A AT mail DOT gmail DOT com>
	<20151222002012 DOT a88d7fe32a9336855eccd1d0 AT gmail DOT com>
	<CAJXU7q9dU=z5KZmgsh+Vau4zZNfEh4Awr5xdzL=6xhimLYVNLw AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1512220421160 DOT 9035 AT igor2priv>
	<201512220412 DOT tBM4CJxb018546 AT envy DOT delorie DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1512220528100 DOT 9035 AT igor2priv>
	<CAJXU7q89cBkSZZfaS5p2CSDeJRTGCzNs+bNBjL8_KYQ=o7gi=Q AT mail DOT gmail DOT com>
	<20151222153828 DOT 28d3996c10f3182c5efc780a AT gmail DOT com>
	<CAJXU7q826wCc69qaQ71Y=Yqrnxg-044GD4ZSViCYSmf1SMiNNw AT mail DOT gmail DOT com>
	<20151222204233 DOT 0ccc392762ac3ee53ed6bad0 AT gmail DOT com>
	<CAJXU7q8kTP6NqozYJm+MC_j7GqVXWJctznZx-VzmJiB4z6A4dw AT mail DOT gmail DOT com>
	<20151222224041 DOT 45deaf70fe414a8c4cc3888f AT gmail DOT com>
	<CAJXU7q8pAStTq6yTq6wOP4=MWBGfURP_KvdEYv-npLmRBmPufA AT mail DOT gmail DOT com>
Date: Tue, 22 Dec 2015 17:05:01 -0900
Message-ID: <CAC4O8c-oEf1n-EphBHqwARkEyLAeOF-3gYCrmQOXA55dMKh-TQ@mail.gmail.com>
Subject: Re: [geda-user] Prop ... Structure? (Clearance calculation)
From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Content-Type: multipart/alternative; boundary=001a114527826119ba0527872688
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
Precedence: bulk

--001a114527826119ba0527872688
Content-Type: text/plain; charset=UTF-8

On Tue, Dec 22, 2015 at 1:02 PM, Peter Clifton (
petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com] <
geda-user AT delorie DOT com> wrote:

> > Then there is the problem is there is an unconnected object within
> distance but I guess it could worked around if not already done by at least
> temporary assign all objects to a net.
>
> I "think" this works ok, but I'm on a Win7 box with no PCB right now
> to check... OK, no wait - I did install PCB (remember it also ports to
> Win32 if you like masochism)...
>
>
> So - it "nearly" works.. two tracks violating DRC clearance, on a
> board with no netlist - no DRC results.
> Throw down a via, and touch it to one of those tracks - and we see 1x
> DRC violations - "Copper areas too close".
>
> Bug - one I'm sure could be fixed. We're probably just not iterating
> over all of the non "PV" type objects as potential DRC check
> start-points. (DRC draws a distinction between the in-layer objects
> like lines, arcs, polygons etc.. and the "PV" type objects (pin, via),
> which can traverse layers..
>

Yes this would be fairly straightforward to fix.  Variable clearance values
would be fairly easy to do as well, at least in an inefficient way:  find.c
uses a single global "bloat" value to check for connection changes at given
bloats (which can be negative).  To handle a board with variable clearance
requirements, you could just start with the lowest clearance and re-run the
entire board for each different clearance value.  If there weren't too
terribly many it wouldn't be too slow.  Traces with larger clearance
requirements probably also deserve larger overlap requirements, so you'd
probably actually need two additional passes for each "special" wire class.

Britton

--001a114527826119ba0527872688
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Dec 22, 2015 at 1:02 PM, Peter Clifton (<a href=3D"mailto:peter=
cjclifton AT googlemail DOT com">petercjclifton AT googlemail DOT com</a>) [via <a href=
=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <span dir=3D"l=
tr">&lt;<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-use=
r AT delorie DOT com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D"">&gt; Then there is the problem is there is an unconnected objec=
t within distance but I guess it could worked around if not already done by=
 at least temporary assign all objects to a net.<br>
<br>
</span>I &quot;think&quot; this works ok, but I&#39;m on a Win7 box with no=
 PCB right now<br>
to check... OK, no wait - I did install PCB (remember it also ports to<br>
Win32 if you like masochism)...<br>
<br>
<br>
So - it &quot;nearly&quot; works.. two tracks violating DRC clearance, on a=
<br>
board with no netlist - no DRC results.<br>
Throw down a via, and touch it to one of those tracks - and we see 1x<br>
DRC violations - &quot;Copper areas too close&quot;.<br>
<br>
Bug - one I&#39;m sure could be fixed. We&#39;re probably just not iteratin=
g<br>
over all of the non &quot;PV&quot; type objects as potential DRC check<br>
start-points. (DRC draws a distinction between the in-layer objects<br>
like lines, arcs, polygons etc.. and the &quot;PV&quot; type objects (pin, =
via),<br>
which can traverse layers..<br></blockquote><div><br></div><div style=3D"">=
Yes this would be fairly straightforward to fix.=C2=A0 Variable clearance v=
alues would be fairly easy to do as well, at least in an inefficient way: =
=C2=A0find.c uses a single global &quot;bloat&quot; value to check for conn=
ection changes at given bloats (which can be negative).=C2=A0 To handle a b=
oard with variable clearance requirements, you could just start with the lo=
west clearance and re-run the entire board for each different clearance val=
ue.=C2=A0 If there weren&#39;t too terribly many it wouldn&#39;t be too slo=
w.=C2=A0 Traces with larger clearance requirements probably also deserve la=
rger overlap requirements, so you&#39;d probably actually need two addition=
al passes for each &quot;special&quot; wire class.</div><div style=3D""><br=
></div><div style=3D"">Britton</div><div>=C2=A0</div></div><br></div></div>

--001a114527826119ba0527872688--