ftp.delorie.com/archives/browse.cgi | search |
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 |
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 |
> 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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |