Mail Archives: geda-user/2014/01/15/02:52:54
On Tue, Jan 14, 2014 at 07:39:07PM +0100, Stefan Salewski wrote:
> The second file is the simplest test case I could come up with: a
> > single 0603 resistor and a single line segment. It can't get much
> > simpler than that.
>
> Again, after applying the vim macro the bug is gone.
>
> Even more interesting: As we have seen, the bug temporary disappears
> when we delete a line and insert it again by undo operation. Obviously
> next step: generate gerbers after undo. My result: Bug is gone. So my
> guess is, it may really be more something like a rounding bug than a
> wrong (dicer?) algorithm. Other idea: It depends on how elements are
> stored inside pcb program, i.e. undo/redo may move elements to bottom of
> a list.
>
> I still suffer from the GL bug -- after a few times loading pcb files
> PCB program refuses to draw something, even after restarting, and
> glxgears was extremly slow, so that I had to restart my computer. That
> may be a real difficult to detect bug. The polygon bug should be not too
> difficult for someone with some knowledge of internal PCB program, i.e.
> what happens when undo/redo occurs.
>
> Gabriel, please test your gerbers after undo/redo.
They are fine. The problem is that, for seom projects, I have a Makefile
based workflow in which I use pcb -x to generate the Gerber and this
just breaks my workflow. I've only hit this bug on one board, a simple
two layer board but with ground plane for EMI reasons. I've had no problem
on several 6 layer boards, but there are no planes on the external layers,
and the internal layers only have vias, not pads.
Note that it seems that one characteristic of the bug is that the
line width + twice the clearance (i.e., the "antiline width")
is exactly the width of the pad. But the coordinate system in PCB
uses integers (a good idea to avoid floating point pitfalls).
I've tested both 32 bit (not x86, ppc) and 64 bit systems and
the bug shows in both.
Best regards,
Gabriel
- Raw text -