[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: pcb, how to remove mm garbage (very short lines)?



On Wed, 2008-11-19 at 14:54 +0200, Duncan Drennan wrote:
> > After using pcb 20080202 (GTK) for more than hundred hours for the
> > current layout know, I think the mm issues are really the most important
> > bugs of this program. (If most of the footprints have mm grid, then it
> > is nearly impossible to use mil grid.) Fixing these mm rounding issues
> > may be difficult and a lot of work -- my guess is that pcb program was
> > designed for mil grid, and mm units are added later as a "fix". So
> > complete redesign of position storage and calculation may be needed.
> 
> Stefan, I haven't really had problems using the mm grid, but maybe I
> don't understand what your issue is exactly. Is the problem the small
> trace that appears underneath a copper pad when you complete a line to
> a pad snap point?

If you use the snap points properly, I've found no problems. (Sometimes
you do end up with a short segment getting from one grid to the other.
Sometimes you need to make the last two line segments leading to the
track off the grid you're working on. Always try to make those last two
pieces by landing directly on your pad/pin's snap point (press shift if
necessary to change the line direction).

What I have found (and drove me nuts, so I removed it locally), was the
key-bindings on my "=" key, which links to one of the "optimisations":

diff --git a/src/gpcb-menu.res b/src/gpcb-menu.res
index b09d948..93b6073 100644
--- a/src/gpcb-menu.res
+++ b/src/gpcb-menu.res
@@ -310,13 +310,11 @@ MainMenu =
    {"Rip up all auto-routed tracks" RipUp(All)}
    -
    {"Optimize routed tracks"
-    {"Auto-Optimize" djopt(auto)  a={"Shift-=" "Shift<Key>="}}
     {"Debumpify" djopt(debumpify) }
     {"Unjaggy" djopt(unjaggy) }
     {"Vianudge" djopt(vianudge) }
     {"Viatrim" djopt(viatrim) }
     {"Ortho pull" djopt(orthopull) }
-    {"Simple optimization" djopt(simple)  a={"=" "<Key>="}}
     {"Miter" djopt(miter) }
     {"Puller" a={"Y" "<Key>y"} Puller() }
     {"Global Puller"

(As a side note, "Shift<Key>=" as a binding is a bad idea, since on some
keyboard layouts, the "=" its-self might be a shifted key-press. On my
keyboard, the correct binding for this "Shift<Key>=" would be "+".

I often end up hitting that key by mistake (not sure why, but I do -
perhaps because its near my laptop's "Delete" key), the "optimiser" then
spends a good deal of CPU cycles wrecking my board in very subtle ways,
such as adding those short stubby pieces of lines where I had ended on a
pad, but not exactly where it wanted.

The optimiser also sometimes ended up moving / deleting nodes in
line-segments, in such a way as to change the line segment's angle,
producing a new line which violated DRC, or in the occasional case,
shorted the track to another.

Those are very dangerous bugs / side-effects, and are very difficult to
spot at the time you cause them. I've lost many hours pouring over
boards to identify and fix this kind of breakage.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user