Mail Archives: geda-user/2015/12/24/18:00:49
--001a113aca4ed5a3480527acced4
Content-Type: text/plain; charset=UTF-8
Btw - in case the English wasn't clear, when we say "bloated", we mean an
object is grown.
The code might also be bloated.... it isn't the prettiest corner of pcb's
internals.
I'd suggest reading through the existing find.c code and seeing how you get
on understanding that.
Peter
On 24 Dec 2015 22:03, "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via
geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> wrote:
> Clearance for outer corners: A corner is formed at an intersection of two
> lines, if you move them outwards and measure distance between new and old
> intersection you would know the problem. It would be possible to add a
> circle segment with zero radius at the intersection and now if lines are
> moved outwards radius is increased and clearance would be correct.
>
> If looking at a net. Their would probably be one default global clearance
> value and if needed more clearance values from this net to other nets with
> larger values.
>
> I did not have time to look at existing code yet, just got explanation how
> it works and a suggestion it is bloated but I actually think a grown copy
> is a simple good method for clearance. Lifetime of copy could be created
> then objected created or created then needed. It could also cut a holes in
> polygons and should be simple to visualize for debug purposes.
>
> Nicklas Karlsson
>
> 2015-12-24 20:16 GMT+01:00 Britton Kerin (britton DOT kerin AT gmail DOT com) [via
> geda-user AT delorie DOT com] <geda-user AT delorie DOT com>:
>
>>
>>
>> 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
>>>
>>>
>>>
>>
>
--001a113aca4ed5a3480527acced4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Btw - in case the English wasn't clear,=C2=A0 when we sa=
y "bloated", we mean an object is grown.</p>
<p dir=3D"ltr">The code might also be bloated.... it isn't the pretties=
t corner of pcb's internals.</p>
<p dir=3D"ltr">I'd suggest reading through the existing find.c code and=
seeing how you get on understanding that.</p>
<p dir=3D"ltr">Peter</p>
<div class=3D"gmail_quote">On 24 Dec 2015 22:03, "Nicklas Karlsson (<a=
href=3D"mailto:nicklas DOT karlsson17 AT gmail DOT com">nicklas DOT karlsson17 AT gmail DOT com<=
/a>) [via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a=
>]" <<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com=
</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr">Clearance for outer corners: A corner is formed at an intersec=
tion of two lines, if you move them outwards and measure distance between n=
ew and old intersection you would know the problem. It would be possible to=
add a circle segment with zero radius at the intersection and now if lines=
are moved outwards radius is increased and clearance would be correct.<div=
><br></div><div>If looking at a net. Their would probably be one default gl=
obal clearance value and if needed more clearance values from this net to o=
ther nets with larger values.</div><div><br></div><div>I did not have time =
to look at existing code yet, just got explanation how it works and a sugge=
stion it is bloated but I actually think a grown copy is a simple good meth=
od for clearance. Lifetime of copy could be created then objected created o=
r created then needed. It could also cut a holes in polygons and should be =
simple to visualize for debug purposes.</div><div><br></div><div>Nicklas Ka=
rlsson</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>2015-12-24 20:16 GMT+01:00 Britton Kerin (<a href=3D"mailto:britton.kerin@=
gmail.com" target=3D"_blank">britton DOT kerin AT gmail DOT com</a>) [via <a href=3D"m=
ailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>] <=
span dir=3D"ltr"><<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_bl=
ank">geda-user AT delorie DOT com</a>></span>:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote"><span>On Thu, Dec 24, 2015 at 4:51 AM, Nicklas Karlsson (<a href=3D"m=
ailto:nicklas DOT karlsson17 AT gmail DOT com" target=3D"_blank">nicklas DOT karlsson17 AT gm=
ail.com</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank=
">geda-user AT delorie DOT com</a>] <span dir=3D"ltr"><<a href=3D"mailto:geda-u=
ser AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">There have been some=
discussion about DRC clearance calculation. As I understand it now clearan=
ce i calculated by growing objects on copper layer and check if netlist cha=
nged. Someone suggested calculate distance is better but to know there is n=
o copper from other object withing clearance distance is actually good enou=
gh. There is however a need for distance then flooding copper within polygo=
n areas.<div><br></div><div>Algorithm clearance:<br></div><div>1. A functio=
n to check if there are other copper objects within clearance distance from=
a net, currently implemented may be good enough.</div><div>1. Assign a net=
name to all copper objects/"drawing primitives", probably all dr=
awing primitives on copper layer.</div><div>1. For each net.</div><div>2. F=
or each clerance value of this net.</div><div>3. For the nets this clearanc=
e value should be used.</div><div>3. Check if this net are within clearance=
distance of nets this clearance value should be used for.</div><div><br></=
div><div>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 ex=
pect text will also work if there is a line width although text is usually<=
/div></div></blockquote><div><br></div></span><div>I think text (on copper)=
is not handled at all in DRC at the moment.</div><span><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div> less important but oute=
r corners of square objects? Or outer corners with any angle?</div></div></=
blockquote><div><br></div></span><div>I'm not sure what you mean here.<=
/div><span><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>With this algorithm net different clearance between different nets sh=
ould work although it must also be decided how the clearance values should =
be attached to the nets. Even though current method to calculate distance m=
ay not be perfect it would not stop other parts from being</div></div></blo=
ckquote><div><br></div></span><div>This is the hardest part.=C2=A0 My under=
standing 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.=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-typing, 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 inheritance feel harder up front but you =
often end up with a much more maintainable system.</div><span><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div> implemented while=
the distance check algorithm may or may not be improved in the mean time.<=
/div><div><br></div><div>Do anybody have any comments on the algorithm?</di=
v></div></blockquote><div><br></div></span><div>If you haven't already =
I'd take a look through find.c to get a feeling for how the existing DR=
C stuff works.=C2=A0 I think it would work without much change</div><div>to=
do other clearances.=C2=A0 You probably just need to start at the high-cle=
arance part of the net first.=C2=A0 Alternately, a filter could be added to=
only throw</div><div>a violation if one of the involved parts had a specia=
l clearance (I'm a little hazy on the exact order in which DRC finds ne=
w connections, but I think the start points happen first).=C2=A0</div><div>=
<br></div><div>Britton</div><div><br></div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><span><font color=3D"#888888"><div><br></d=
iv><div><br></div><div>Nicklas Karlsson</div><div><br></div><div><br></div>=
</font></span></div>
</blockquote></div><br></div></div>
</blockquote></div><br></div>
</blockquote></div>
--001a113aca4ed5a3480527acced4--
- Raw text -