Mail Archives: geda-user/2015/12/24/16:41:32
--089e01294d9eff1e980527abb1b9
Content-Type: text/plain; charset=UTF-8
Yes I also think existent clerance calculation could be used and that's the
point, it should not be it to hard to expand clearance calculation for a
net with different clearance value to different nets.
I do not fully agree algorithm is a bloat. To temporary grow the size of
objects in a net and check if they touch any other objects should be good
enough.
For clearance between polygon and net there is however a need to calculate
distance, preferably rounded upwards although the method with grown a grown
copy cutting a hole in the polygon should also work fine.
I believe grown copies of objects may be a good solution for clearance it
is rather simple to understand and dynamic update of the copy should not be
to hard or time consuming to implement. It should also be simple to
visualize the normally invisible grown copy for debugging purpose.
2015-12-24 19:43 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 Wed, Dec 23, 2015 at 12:28 AM, Nicklas Karlsson (
> nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] <
> geda-user AT delorie DOT com> wrote:
>
>> > 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.
>>
>
> I think you can accomplish this with a run of the existing code along only
> the high-clearance wires, and an elevated bloat setting. Then you would be
> using all the same code, admittedly in a slightly tortured way.
>
> Britton
>
>
--089e01294d9eff1e980527abb1b9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes I also think existent clerance calculation could be us=
ed and that's the point, it should not be it to hard to expand clearanc=
e calculation for a net with different clearance value to different nets.<d=
iv><br></div><div>I do not fully agree algorithm is a bloat. To temporary g=
row the size of objects in a net and check if they touch any other objects =
should be good enough.</div><div><br></div><div>For clearance between polyg=
on and net there is however a need to calculate distance, preferably rounde=
d upwards although the method with grown a grown copy cutting a hole in the=
polygon should also work fine.</div><div><br></div><div>I believe grown co=
pies of objects may be a good solution for clearance it is rather simple to=
understand and dynamic update of the copy should not be to hard or time co=
nsuming to implement. It should also be simple to visualize the normally in=
visible grown copy for debugging purpose.</div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">2015-12-24 19:43 GMT+01:00 Britton Keri=
n (<a href=3D"mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) =
[via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <s=
pan dir=3D"ltr"><<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_bla=
nk">geda-user AT delorie DOT com</a>></span>:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div class=3D"h5"><br><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Wed, Dec 23, 2015 at 12:28 AM, Nicklas Karls=
son (<a href=3D"mailto:nicklas DOT karlsson17 AT gmail DOT com" target=3D"_blank">nick=
las 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 com</a>] <span dir=3D"ltr"><<a href=
=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Tue, Dec 22,=
2015 at 1:02 PM, Peter Clifton (<br>
> <a href=3D"mailto:petercjclifton AT googlemail DOT com" target=3D"_blank">pet=
ercjclifton AT googlemail DOT com</a>) [via <a href=3D"mailto:geda-user AT delorie DOT co=
m" target=3D"_blank">geda-user AT delorie DOT com</a>] <<br>
> <a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT d=
elorie.com</a>> wrote:<br>
><br>
> > > Then there is the problem is there is an unconnected object =
within<br>
> > distance but I guess it could worked around if not already done b=
y at least<br>
> > temporary assign all objects to a net.<br>
> ><br>
> > I "think" this works ok, but I'm on a Win7 box with=
no PCB right now<br>
> > to check... OK, no wait - I did install PCB (remember it also por=
ts to<br>
> > Win32 if you like masochism)...<br>
> ><br>
> ><br>
> > So - it "nearly" works.. two tracks violating DRC clear=
ance, on a<br>
> > board with no netlist - no DRC results.<br>
> > Throw down a via, and touch it to one of those tracks - and we se=
e 1x<br>
> > DRC violations - "Copper areas too close".<br>
> ><br>
> > Bug - one I'm sure could be fixed. We're probably just no=
t iterating<br>
> > over all of the non "PV" type objects as potential DRC =
check<br>
> > start-points. (DRC draws a distinction between the in-layer objec=
ts<br>
> > like lines, arcs, polygons etc.. and the "PV" type obje=
cts (pin, via),<br>
> > which can traverse layers..<br>
> ><br>
><br>
> Yes this would be fairly straightforward to fix.=C2=A0 Variable cleara=
nce values<br>
> would be fairly easy to do as well, at least in an inefficient way:=C2=
=A0 find.c<br>
> uses a single global "bloat" value to check for connection c=
hanges at given<br>
> bloats (which can be negative).=C2=A0 To handle a board with variable =
clearance<br>
> requirements, you could just start with the lowest clearance and re-ru=
n the<br>
> entire board for each different clearance value.=C2=A0 If there weren&=
#39;t too<br>
> terribly many it wouldn't be too slow.=C2=A0 Traces with larger cl=
earance<br>
> requirements probably also deserve larger overlap requirements, so you=
'd<br>
> probably actually need two additional passes for each "special&qu=
ot; wire class.<br>
><br>
> Britton<br>
<br>
different net<-->net clearances should not be to hard once every obje=
ct on copper layer have been assigned a net name:<br>
=C2=A0 1. Check global value as is done now.<br>
=C2=A0 2. Check clerance for each other net<-->net combintion, during=
this pass all other nets could be ignored.<br>
The trick is for each net with a particular value you check clearance to th=
e other nets instead of all nets at once.<br>
</blockquote></div><br></div></div></div><div class=3D"gmail_extra">I think=
you can accomplish this with a run of the existing code along only the hig=
h-clearance wires, and an elevated bloat setting.=C2=A0 Then you would be u=
sing all the same code, admittedly in a slightly tortured way.=C2=A0</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Britton</div=
><div class=3D"gmail_extra"><br></div></div>
</blockquote></div><br></div>
--089e01294d9eff1e980527abb1b9--
- Raw text -