Mail Archives: geda-user/2015/12/31/19:59:31
--001a1145a83ad2af5d05283b47d7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Dec 29, 2015 at 3:57 PM, =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=94=D1=
=83=D0=B1=D0=BD=D1=8F=D0=BA <twister AT tfsoft DOT org DOT ua> wrote:
> Spent several days trying to fix this bug:
> https://bugs.launchpad.net/pcb/+bug/1013358
>
> I was convinced that it is due to rounding errors somewhere in
> find.c/search.c,
> when DRC clearance and grid spacing are the same. But turns out, it is no=
t.
> Please, see the trivial patch in attachment. Looks like it solves the
> described problem.
>
> I'm suspicious if the bug is fixed _that_ simple (taking into account my
> shallow knowledge of codebase).
>
> It would be great if someone explain what was the intention of "PCB->Bloa=
t
> +
> 1" in that place? Maybe it is vital for some other actions, not related t=
o
> this bug?
>
It looks like it's meant to be conservative. Bloat ends up set such that
lines have to be thickened by twice that amount to cause a new intersection
when a DRC violation exists. But bloat may itself already have been
subject to rounding, so throwing the extra 1 in makes it "safer" in the
sense that it will fire a violation in the marginal conditions that I think
that bug report is describing.
By removing the -1 you may "fix" this particular case, but unfortunately
the underlying problem still exists and will likely manifest elsewhere as
well (for non-axis-aligned lines for example). The only real solution is
to use a DRC clearance requirement smaller than your actual spacing by some
reasonable epsilon. That done, you're version may still be better, as
there would then be no need for half-assed efforts to dodge the issue with
things like that extra +1. Using a DRC value equal to your grid and line
sizes is asking for trouble. IMO we should change pcb to somehow make this
clear to users, rather than trying to paper over the problem in the
calculations themselves.
Britton
--001a1145a83ad2af5d05283b47d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Dec 29, 2015 at 3:57 PM, =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=94=
=D1=83=D0=B1=D0=BD=D1=8F=D0=BA <span dir=3D"ltr"><<a href=3D"mailto:twis=
ter AT tfsoft DOT org DOT ua" target=3D"_blank">twister AT tfsoft DOT org DOT ua</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">Spent several days trying to fix th=
is bug:<br>
<a href=3D"https://bugs.launchpad.net/pcb/+bug/1013358" rel=3D"noreferrer" =
target=3D"_blank">https://bugs.launchpad.net/pcb/+bug/1013358</a><br>
<br>
I was convinced that it is due to rounding errors somewhere in find.c/searc=
h.c,<br>
when DRC clearance and grid spacing are the same. But turns out, it is not.=
<br>
Please, see the trivial patch in attachment. Looks like it solves the<br>
described problem.<br>
<br>
I'm suspicious if the bug is fixed _that_ simple (taking into account m=
y<br>
shallow knowledge of codebase).<br>
<br>
It would be great if someone explain what was the intention of "PCB-&g=
t;Bloat +<br>
1" in that place? Maybe it is vital for some other actions, not relate=
d to<br>
this bug?<br></blockquote><div><br></div><div style=3D"">It looks like it&#=
39;s meant to be conservative.=C2=A0 Bloat ends up set such that lines have=
to be thickened by twice that amount to cause a new intersection when a DR=
C violation exists.=C2=A0 But bloat may itself already have been subject to=
rounding, so throwing the extra 1 in makes it "safer" in the sen=
se that it will fire a violation in the marginal conditions that I think th=
at bug report is describing.</div><div style=3D""><br></div><div style=3D""=
>By removing the -1 you may "fix" this particular case, but unfor=
tunately the underlying problem still exists and will likely manifest elsew=
here as well (for non-axis-aligned lines for example).=C2=A0 The only real =
solution is to use a DRC clearance requirement smaller than your actual spa=
cing by some reasonable epsilon.=C2=A0 That done, you're version may st=
ill be better, as there would then be no need for half-assed efforts to dod=
ge the issue with things like that extra +1.=C2=A0 Using a DRC value equal =
to your grid and line sizes is asking for trouble.=C2=A0 IMO we should chan=
ge pcb to somehow make this clear to users, rather than trying to paper ove=
r the problem in the calculations themselves.</div><div style=3D""><br></di=
v><div style=3D"">Britton</div><div style=3D""><br></div></div></div></div>
--001a1145a83ad2af5d05283b47d7--
- Raw text -