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=slOHyj64cLW8CfOof5kQGS9F4rPINyed/Xfv/MRRUcY=; b=GwvQQVQpGC1uHi50wVVfjACA5Qkngu+Al1JibNMcbApjYrgcNCzE30tE0WHSO7tIqO pPnx0NubtkQ1mvwO/MiAtRAtzGcG87zIp+GmN4f2xHz1CdQHfHdiMeWoJEPsvfVwn9fW GsiCkHc0CDrOM8QHbQQ2o0mW+BNRFHPCmduIl8vY0Y929k2vNeYNhurIIpDBwJd+tjCf lV8gtkkhx4Z0C21TbnoaM08AOEpHmO3z3Y0x7EcrCyvxG81mHZaC+vCK6Z6wpDe4V8SG ZQuY1/JuTvT88kkv7eaCGiWcDJGOBS6em1zRGGDXySrPCO4Px2/f6IbUQr3A+jquhQyt 3Mzg== MIME-Version: 1.0 X-Received: by 10.194.173.233 with SMTP id bn9mr40992978wjc.1.1450984603658; Thu, 24 Dec 2015 11:16:43 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Dec 2015 10:16:43 -0900 Message-ID: Subject: Re: [geda-user] Algorithm (DRC clearance net<--> net) 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=089e0122f088e0310d0527a9adfd 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 --089e0122f088e0310d0527a9adfd Content-Type: text/plain; charset=UTF-8 On Thu, Dec 24, 2015 at 4:51 AM, Nicklas Karlsson ( nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] < geda-user AT delorie DOT com> wrote: > There have been some discussion about DRC clearance calculation. As I > understand it now clearance i calculated by growing objects on copper layer > and check if netlist changed. Someone suggested calculate distance is > better but to know there is no copper from other object withing clearance > distance is actually good enough. There is however a need for distance then > flooding copper within polygon areas. > > Algorithm clearance: > 1. A function to check if there are other copper objects within clearance > distance from a net, currently implemented may be good enough. > 1. Assign a net name to all copper objects/"drawing primitives", probably > all drawing primitives on copper layer. > 1. For each net. > 2. For each clerance value of this net. > 3. For the nets this clearance value should be used. > 3. Check if this net are within clearance distance of nets this clearance > value should be used for. > > The first question is if current algorithm make drawing primitives of net > which should be checked larger and check if netlist changed is good enough? > I expect lines and arcs would be no problem and I actually also expect text > will also work if there is a line width although text is usually > I think text (on copper) is not handled at all in DRC at the moment. > less important but outer corners of square objects? Or outer corners with > any angle? > I'm not sure what you mean here. > With this algorithm net different clearance between different nets should > work although it must also be decided how the clearance values should be > attached to the nets. Even though current method to calculate distance may > not be perfect it would not stop other parts from being > This is the hardest part. My understanding is that at the moment pcb has a few basic types, and a boatload of flags, only a some of which apply to each type. There's a lot of talk about adding attributes but I'm not certain it's a great idea. Attributes are a form of duck-typing, and if you've been lucky enough to spend time with JavaScript you know how that can go. gschem has all sorts of problems with the wonky, barely-known interpretations of attribute sets. Classes and inheritance feel harder up front but you often end up with a much more maintainable system. > implemented while the distance check algorithm may or may not be improved > in the mean time. > > Do anybody have any comments on the algorithm? > If you haven't already I'd take a look through find.c to get a feeling for how the existing DRC stuff works. I think it would work without much change to do other clearances. You probably just need to start at the high-clearance part of the net first. Alternately, a filter could be added to only throw a violation if one of the involved parts had a special clearance (I'm a little hazy on the exact order in which DRC finds new connections, but I think the start points happen first). Britton > > > Nicklas Karlsson > > > --089e0122f088e0310d0527a9adfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 24, 2015 at 4:51 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:
There have been some discussion about DRC clearance calculation= . As I understand it now clearance i calculated by growing objects on coppe= r layer and check if netlist changed. Someone suggested calculate distance = is better but to know there is no copper from other object withing clearanc= e distance is actually good enough. There is however a need for distance th= en flooding copper within polygon areas.

Algorithm clear= ance:
1. A function to check if there are other copper object= s within clearance distance from a net, currently implemented may be good e= nough.
1. Assign a net name to all copper objects/"drawing p= rimitives", probably all drawing primitives on copper layer.
1. For each net.
2. For each clerance value of this net.
3. For the nets this clearance value should be used.
3. Check = if this net are within clearance distance of nets this clearance value shou= ld be used for.

The first question is if current a= lgorithm make drawing primitives of net which should be checked larger and = check if netlist changed is good enough? I expect lines and arcs would be n= o problem and I actually also expect text will also work if there is a line= width although text is usually

I think text (on copper) is not handled at all in DRC at the mo= ment.
=C2=A0
less important but outer corners of square objects? Or outer corners= with any angle?

I&#= 39;m not sure what you mean here.
=C2=A0
With this algorithm net different clear= ance between different nets should work although it must also be decided ho= w the clearance values should be attached to the nets. Even though current = method to calculate distance may not be perfect it would not stop other par= ts from being

This i= s the hardest part.=C2=A0 My understanding is that at the moment pcb has a = few basic types, and a boatload of flags, only a some of which apply to eac= h type.=C2=A0 There's a lot of talk about adding attributes but I'm= not certain it's a great idea.=C2=A0 Attributes are a form of duck-typ= ing, and if you've been lucky enough to spend time with JavaScript you = know how that can go. =C2=A0gschem has all sorts of problems with the wonky= , barely-known interpretations of attribute sets.=C2=A0 Classes and inherit= ance feel harder up front but you often end up with a much more maintainabl= e system.
=C2=A0
implemented while the distance check algorithm may or may not be= improved in the mean time.

Do anybody have any co= mments on the algorithm?

If you haven't already I'd take a look through find.c to get = a feeling for how the existing DRC stuff works.=C2=A0 I think it would work= without much change
to do other clearances.=C2=A0 You= probably just need to start at the high-clearance part of the net first.= =C2=A0 Alternately, a filter could be added to only throw
a violation if one of the involved parts had a special clearance (I&#= 39;m a little hazy on the exact order in which DRC finds new connections, b= ut I think the start points happen first).=C2=A0

<= /div>
Britton

=C2=A0


Nicklas Karlsson
=


--089e0122f088e0310d0527a9adfd--