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=0BhzYFN+O5f4SyxXnAg4/YhS6BR/hfzU9voDmAVgZFA=; b=Tfnnst4RtnTRseTvCsuXDNAQkuCHD/n/qxTgRqn9+OQ5+jm6m4401SI9QiiwFHWQ8m CUv2C5LGuK9s5IGY62u3fwrYNn2jc2PHsxd/YgDtQDsi17/e9FK2okVp0BQZd1ydFSJ/ 1wBOIbYD19WvsWMyp6xmo30ux/0aeSFSWzV0TZgp4Hr3RVe2e5icugx5goNCxiYNXULu Q6B8ENKFm7MSoRsDw1QkWv5h7XUzgYRrMa2odfjFbUMMrt85dARX5LhYvInvqB3Nuh5s S3gotMfZJS7rShZtqC8h6NG1vbnyQDGqiCkzciT3YyWAMkS46FU0MOkDttOZkup/1IVr 6Agg== MIME-Version: 1.0 X-Received: by 10.28.93.195 with SMTP id r186mr39793755wmb.37.1450982603855; Thu, 24 Dec 2015 10:43:23 -0800 (PST) In-Reply-To: <20151223102847.f3c44cabc40180fa4e85e2d7@gmail.com> References: <20151222002012 DOT a88d7fe32a9336855eccd1d0 AT gmail DOT com> <201512220412 DOT tBM4CJxb018546 AT envy DOT delorie DOT com> <20151222153828 DOT 28d3996c10f3182c5efc780a AT gmail DOT com> <20151222204233 DOT 0ccc392762ac3ee53ed6bad0 AT gmail DOT com> <20151222224041 DOT 45deaf70fe414a8c4cc3888f AT gmail DOT com> <20151223102847 DOT f3c44cabc40180fa4e85e2d7 AT gmail DOT com> Date: Thu, 24 Dec 2015 09:43:23 -0900 Message-ID: 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]" To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=001a11469daeada1f80527a93607 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 --001a11469daeada1f80527a93607 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 23, 2015 at 12:28 AM, Nicklas Karlsson ( nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] < geda-user AT delorie DOT com> wrote: > > 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 > > different net<-->net clearances should not be to hard once every object on > copper layer have been assigned a net name: > 1. Check global value as is done now. > 2. Check clerance for each other net<-->net combintion, during this pass > all other nets could be ignored. > The trick is for each net with a particular value you check clearance to > the other nets instead of all nets at once. > I think you can accomplish this with a run of the existing code along only the high-clearance wires, and an elevated bloat setting. Then you would be using all the same code, admittedly in a slightly tortured way. Britton --001a11469daeada1f80527a93607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 23, 2015 at 12:28 AM, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] <geda-use= r AT delorie DOT com> wrote:
> = On Tue, Dec 22, 2015 at 1:02 PM, Peter Clifton (
> petercjclifton AT google= mail.com) [via geda-user AT delor= ie.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 b= y 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 por= ts to
> > Win32 if you like masochism)...
> >
> >
> > So - it "nearly" works.. two tracks violating DRC clear= ance, on a
> > board with no netlist - no DRC results.
> > Throw down a via, and touch it to one of those tracks - and we se= e 1x
> > DRC violations - "Copper areas too close".
> >
> > Bug - one I'm sure could be fixed. We're probably just no= t iterating
> > over all of the non "PV" type objects as potential DRC = check
> > start-points. (DRC draws a distinction between the in-layer objec= ts
> > like lines, arcs, polygons etc.. and the "PV" type obje= cts (pin, via),
> > which can traverse layers..
> >
>
> Yes this would be fairly straightforward to fix.=C2=A0 Variable cleara= nce values
> would be fairly easy to do as well, at least in an inefficient way:=C2= =A0 find.c
> uses a single global "bloat" value to check for connection c= hanges at given
> bloats (which can be negative).=C2=A0 To handle a board with variable = clearance
> requirements, you could just start with the lowest clearance and re-ru= n the
> entire board for each different clearance value.=C2=A0 If there weren&= #39;t too
> terribly many it wouldn't be too slow.=C2=A0 Traces with larger cl= earance
> requirements probably also deserve larger overlap requirements, so you= 'd
> probably actually need two additional passes for each "special&qu= ot; wire class.
>
> Britton

different net<-->net clearances should not be to hard once every obje= ct on copper layer have been assigned a net name:
=C2=A0 1. Check global value as is done now.
=C2=A0 2. Check clerance for each other net<-->net combintion, during= this pass all other nets could be ignored.
The trick is for each net with a particular value you check clearance to th= e other nets instead of all nets at once.

I think = you can accomplish this with a run of the existing code along only the high= -clearance wires, and an elevated bloat setting.=C2=A0 Then you would be us= ing all the same code, admittedly in a slightly tortured way.=C2=A0

Britton

--001a11469daeada1f80527a93607--