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=date:from:to:subject:message-id:in-reply-to:references:mime-version
         :content-type:content-transfer-encoding;
        bh=0Jkq/szry7lhXyvVE+/msAx23L0weTC3BNR5abNHMDY=;
        b=gpR0UqRh5UxnWomsuo/K5Xy1opGo5CCF883gmhZPGiU6UYLIKWYlnu+jVE6xejBdla
         XYk2zQfB/IZBEK1vT/mxvqahopoCX1e0P2im2dsEjx0yxVjtQNHk6isoihcyfn2PP2v6
         tUOvRRI5wZHWDXd4APE3sGXPDhKNqOEhFcKkEEPEzLqug6x5pIzmDW1j+SKhRLtEf7fm
         Dorz3z/N9i8EjwbUn6qjC8tKCfaU5mjglKSyG/60iBznst6KsTLiD2wjZzjQhOLgtHzC
         G/qkld5ueP3zhuARqPSi9AOgcOqj7wNfo3mGDTDh2PDchexUIjqNON4Sx5jUgs0HVIe+
         WAqA==
X-Received: by 10.28.91.83 with SMTP id p80mr34033191wmb.87.1450862928883;
        Wed, 23 Dec 2015 01:28:48 -0800 (PST)
Date: Wed, 23 Dec 2015 10:28:47 +0100
From: "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Prop ... Structure? (Clearance calculation)
Message-Id: <20151223102847.f3c44cabc40180fa4e85e2d7@gmail.com>
In-Reply-To: <CAC4O8c-oEf1n-EphBHqwARkEyLAeOF-3gYCrmQOXA55dMKh-TQ@mail.gmail.com>
References: <CAOFvGD6OiYxcGkOiQRVnvXW3TLs42bt7PE5Ot9s09hsukYicKA 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>
	<CAC4O8c-oEf1n-EphBHqwARkEyLAeOF-3gYCrmQOXA55dMKh-TQ AT mail DOT gmail DOT com>
X-Mailer: Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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

> 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.