← Back to team overview

kicad-developers team mailing list archive

Re: Potential issues with oaa_ lib


Hash: SHA1

On 09/09/2010 10:34 AM, Brian F. G. Bidulock wrote:
> Lorenzo,
> On Thu, 09 Sep 2010, Lorenzo Marcantonio wrote:
>> On Thu, 9 Sep 2010, Alex G wrote:
>>> Wouldn't it then be feasible to create the normal 7.4mm pad on the back,
>>> and leave a smaller pad (say 4mm) on the front (and maybe inner layers),
>>> or is this getting too complicated to be of any practical use?
>> This is what you usually do with padstacks, but kicad has no support for
>> them... how do you specify inner layers?
> I'm working on a couple of things in this regard (removal of
> non-functional pads, for one); however, what Alex describes above can
> pretty much already be done with the module editor:
>   1. Define a pad (standard) that is on both sides of the board that is
>      4mm and has a hole (set to the size you need for the pin).  This
>      will be interpreted by PCBNEW as a 4mm pad on all copper layers.
>   2. Define a pad (virtual) only on the back side of the board that is
>      7.4mm.  Do not give it a hole.  It could also exist on the back
>      mask layer.
A bit of a hack, but still a lovely solution. Do you think it is
worthwhile applying this for the the D-SUB connectors? And in such a
case, is 4mm the best value?

> I think this will give you a 4mm pad on the front and inner layers, and
> a 7.4 mm pad on top of the 4mm pad on the back.  I'm not sure whether
> DRC checks and ratsnests are going to say that one of these pads on the
> back (7.4mm or 4mm) is unconnected, but that's a different matter.
For the D-SUB connectors which I was proposing this, it shouldn't really
matter, as the pad is left unconnected anyway. If we name all the
mounting pads "Shield", then I don't think DRC will have an issue in the
event they are connected to something.

> Even still, the 7.4mm pad could probably be moved 1/10th of mil
> off-center from the 4mm pads to allow the two to be connected with a
> 0.1mil long trace.
Ok, this one is an ugly hack, as it requires work beyond the module
itself. :)

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/


Follow ups