X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <53B9A998.8050803@sonic.net>
Date: Sun, 06 Jul 2014 12:55:04 -0700
From: Dave Curtis <davecurtis AT sonic DOT net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] pour clearing around pads
References: <53B8CC66 DOT 2080909 AT sonic DOT net> <201407060516 DOT s665GVb3027395 AT envy DOT delorie DOT com> <53B965BE DOT 6040303 AT sonic DOT net> <201407061708 DOT s66H86a8022645 AT envy DOT delorie DOT com>
In-Reply-To: <201407061708.s66H86a8022645@envy.delorie.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;PqwXbEcF5BGLi02zUc16mQ== M;OqBPbEcF5BGLi02zUc16mQ==
X-Spam-Flag: No
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Reply-To: geda-user AT delorie DOT com

On 07/06/2014 10:08 AM, DJ Delorie wrote:
>> Is there a reliable way to validate that zero-width pads are usable?
> Code review.
Where is the canonical git repo these day?  It's been a while since I've 
looked at it.
>> 1. Draw a Pad[] with zero width, but with clearance/mask set create
>> desired relief.
>> 2. Give the Pad[] a pin number that is *not* used in the part, that way
>> it will not show up in the netlist and cause rat/routing/connectivity
>> confusion.
> I suspect that a zero-width pad is still "a pad" according to parts of
> the code, so it will still block traces and cause shorts despite being
> zero-width.
Shouldn't it block traces?  Isn't that the point of clearance? Although 
I guess if you set thickness to zero to try to create a gang mask it 
would be annoying if it blocked traces.

Conceptually, it seems like a "zero width pad" solves a couple of 
long-standing annoyances. It could be used to clean up the kind of 
clearance issue I'm having here, and it could also create gang masks.  
If people agreed, I could see a couple of approaches...

1. Declare that a zero width pad is a valid primitive that does not 
impact connectivity in any way, is guaranteed not to render on a copper 
layer, but allows either or both of thickness and mask-relief to be 
non-zero.  The current code might do the right thing in a lot of places, 
but long term I suspect this would create a lot of special-case checks 
in the code and of course becomes burdensome legacy in the spec.  It 
does not require any new footprint parsing code.

2. Create new primitive(s) for footprint files, perhaps Clear[]  and 
Mask[], that can attack the problems directly.   It also strikes me that 
a Keepout[] primitive might share some behavior of Clear[]... it blocks 
routing but doesn't draw anti-copper.