www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2014/07/08/21:33:44

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Message-ID: <1404869573.3730.30.camel@pcjc2lap>
Subject: Re: [geda-user] pour clearing around pads
From: Peter Clifton <pcjc2 AT cam DOT ac DOT uk>
To: geda-user AT delorie DOT com
Date: Wed, 09 Jul 2014 02:32:53 +0100
In-Reply-To: <1404719914.750.49@zotlet.(none)>
References: <1404719914 DOT 750 DOT 49 AT zotlet.(none)>
X-Mailer: Evolution 3.10.4-0ubuntu1
Mime-Version: 1.0
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Mon, 2014-07-07 at 19:58 +1200, Lilith Bryant wrote:
> > 
> > Not exactly, and it may not work when multiple different objects combine to
> > create a thin feature.
> 
> Can you describe such a case.  I can't see how this could be?

For mask cutouts, what I meant was that it would only work for global
application to the entire board at one time. I don't think it would work
nicely with our usual incremental approach to polygon management.

For application to general polygons - there are some fundamental
problems. One, in particular, is if the outer contour is explicitly
defined such that it violates a min-width rule in a necked-down region.

If you shrink this polygon (by subtracting a line for each edge of its
contour), it will breaks into two pieces either side of the necked
region. PCB's connectivity checking code would not cope with that, the
only way it would cope with the current code-base if you deliberately
threw away one of the pieces.

Bloating a convex part of the polygon (after shrinking) will also
introduce rounded corners, not necessarily an issue - but also not
necessarily what people might want, or expect. Certainly it would be a
break from what we currently expect.


The method could be used to remove sharp corners from spikes on
polygons, but something "feels" wrong with insisting on radiusing say, a
90 degree corner of a power plane, just because it happened to go
through this code-path. This is one of the reasons I never did anything
with that idea when we looked at it before.


A long ago, I had a git branch which addressed this "one piece kept"
issue, allowing one "pour" once disected by tracking, to contribute to
connectivity of any number of different nets. The branch had code to
allow keeping every piece of a poured polygon, and optionally -
introduced island removal logic to only keep those pieces which were
electrically connected to something. I'll perhaps revive the branch one
day.

For reference, I used the word "pour" in the branch to indicate the
"correct", non-piece-throwing-away behaviour, in contrast to PCB's
current "polygons".


-- 
Peter Clifton <peter DOT clifton AT clifton-electronics DOT co DOT uk>

Clifton Electronics

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019