Mail Archives: geda-user/2015/12/25/03:15:57
--001a113cf2f8cc4b5c0527b48c33
Content-Type: text/plain; charset=UTF-8
I already got a perfect visual understanding in my mind, objects part of
the net on copper layer is grown one by one and checked for intersection of
objects not part of the net but I should read code also.
2015-12-25 0:00 GMT+01:00 Peter Clifton (petercjclifton AT googlemail DOT com)
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com>:
> 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
>>>>
>>>>
>>>>
>>>
>>
--001a113cf2f8cc4b5c0527b48c33
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I already got a perfect visual understanding in my mind, o=
bjects part of the net on copper layer is grown one by one and checked for =
intersection of objects not part of the net but I should read code also.</d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-12-25 0:0=
0 GMT+01:00 Peter Clifton (<a href=3D"mailto:petercjclifton AT googlemail DOT com"=
>petercjclifton AT googlemail DOT com</a>) [via <a href=3D"mailto:geda-user AT delori=
e.com">geda-user AT delorie DOT com</a>] <span dir=3D"ltr"><<a href=3D"mailto:g=
eda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>></span=
>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Btw - in case the Engli=
sh wasn't clear,=C2=A0 when we say "bloated", we mean an obje=
ct 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"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_quote">On 24 Dec 2015 22:03, "Nicklas Karlsson (<a=
href=3D"mailto:nicklas DOT karlsson17 AT gmail DOT com" target=3D"_blank">nicklas.kar=
lsson17 AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com" target=
=3D"_blank">geda-user AT delorie DOT com</a>]" <<a href=3D"mailto:geda-use=
r AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>> wrote:<br ty=
pe=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Clearanc=
e 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 intersecti=
on 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 r=
adius is increased and clearance would be correct.<div><br></div><div>If lo=
oking 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.</div><div><br></div><div>I did not have time to look at existing c=
ode yet, just got explanation how it works and a suggestion it is bloated b=
ut I actually think a grown copy is a simple good method for clearance. Lif=
etime 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 f=
or debug purposes.</div><div><br></div><div>Nicklas Karlsson</div></div><di=
v 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 DOT kerin AT gmail DOT com" target=3D"=
_blank">britton DOT kerin AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delor=
ie.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"_blank">geda-user AT delori=
e.com</a>></span>:<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"><b=
r><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span>On Thu, D=
ec 24, 2015 at 4:51 AM, Nicklas Karlsson (<a href=3D"mailto:nicklas.karlsso=
n17 AT gmail DOT com" target=3D"_blank">nicklas DOT karlsson17 AT gmail DOT com</a>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT c=
om</a>] <span dir=3D"ltr"><<a href=3D"mailto:geda-user AT delorie DOT com" targ=
et=3D"_blank">geda-user AT delorie DOT com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">There have been some discussion about DRC=
clearance calculation. As I understand it now clearance i calculated by gr=
owing objects on copper layer and check if netlist changed. Someone suggest=
ed calculate distance is better but to know there is no copper from other o=
bject withing clearance distance is actually good enough. There is however =
a need for distance then flooding copper within polygon areas.<div><br></di=
v><div>Algorithm clearance:<br></div><div>1. A function to check if there a=
re other copper objects within clearance distance from a net, currently imp=
lemented may be good enough.</div><div>1. Assign a net name to all copper o=
bjects/"drawing primitives", probably all drawing primitives on c=
opper layer.</div><div>1. For each net.</div><div>2. For each clerance valu=
e of this net.</div><div>3. For the nets this clearance value should be use=
d.</div><div>3. Check if this net are within clearance distance of nets thi=
s clearance value should be used for.</div><div><br></div><div>The first qu=
estion is if current algorithm make drawing primitives of net which should =
be checked larger and check if netlist changed is good enough? I expect lin=
es and arcs would be no problem and I actually also expect text will also w=
ork if there is a line width although text is usually</div></div></blockquo=
te><div><br></div></span><div>I think text (on copper) is not handled at al=
l in DRC at the moment.</div><span><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div> less important but outer corners of square o=
bjects? 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"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>With this alg=
orithm 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 i=
t would not stop other parts from being</div></div></blockquote><div><br></=
div></span><div>This is 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 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 tim=
e with JavaScript you know how that can go. =C2=A0gschem has all sorts of p=
roblems 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 cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div> implemented while the distance chec=
k algorithm may or may not be improved in the mean time.</div><div><br></di=
v><div>Do anybody have any comments on the algorithm?</div></div></blockquo=
te><div><br></div></span><div>If you haven't already I'd take a loo=
k through find.c to get a feeling for how the existing DRC stuff works.=C2=
=A0 I think it would work without much change</div><div>to do other clearan=
ces.=C2=A0 You probably just need to start at the high-clearance part of th=
e 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 special clearance (I=
9;m a little hazy on the exact order in which DRC finds new connections, bu=
t I think the start points happen first).=C2=A0</div><div><br></div><div>Br=
itton</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><span><font color=3D"#888888"><div><br></div><div><br></div=
><div>Nicklas Karlsson</div><div><br></div><div><br></div></font></span></d=
iv>
</blockquote></div><br></div></div>
</blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
--001a113cf2f8cc4b5c0527b48c33--
- Raw text -