kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #05369
Re: Potential issues with oaa_ lib
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/09/2010 12:34 AM, Lorenzo Marcantonio wrote:
> On Wed, 8 Sep 2010, Alex G wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Oyvind,
>>
>> I believe it would make sense, for the D-SUB connectors, to only place
>> the pad on the back side, so as to free up space for tracks on the front
>> side. I'm not sure if this is necessarily wise (problems with
>> through-hole plating?), but I'm throwing it as an idea. What do you
>> think?
>
> Usually PTH components should have pads on both faces for 3 reasons:
> 1) A pad on a single layer is prone to delamination (especially if you
> need to rework it; the plating barrel and the opposite pad have great
> effect on mechanical strength;
> 2) If there is a plating barrel and hole clearance is correct the whole
> hole would be filled with solder (better electrical and mechanical
> performance);
> 3) You would forfait access to *all* the other layers (for example
> supply planes); also is almost impossible to route all the pins from an
> HD connector on one layer keeping solder pads big enough for good
> joints.
>
> Since at the moment kicad hasn't a padstack facility (i.e. for reducing
> pads on the inner/components layers) it should be user that, only when
> needed, would remove the pad.
>
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?
Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMiALJAAoJEL0kPHNPXJJKxB4P/1CWy3DUCvU7sV1Zu49Xc427
URgBNGD+BScYMSRpElfn/xAz7A0XIQas7nDRgISud2AoAfMuMOlGGMph55ZT4SS0
Ogw5u7V6ZROvBEx5fCidcU+u1iqEa3ZylYlLEsv7DX9Tp9cxhCZIjMeGy/NiFy2D
uf2BBobL2QWLadzIx0v3IDryzMO5R0E4OYisJo01b+oUxmaJHeDYGWNyRcykzgWQ
8hQjHyAbPVwyhUjxJPwnOrspv/q+niciuCrO4fPA9wMpoEeoMI64Q5D+el33ylBP
YUoFcR/Klr31GB1EloiBTOc/KvRJSSZF+FIJGG031xeonFxtysX1cev1J1c/53HB
z5vEq7yE6QkHWFawn8JgzCKlxb3lzQgA9e6QSbxw04eyUrrWIY4IwYBqadRNs9zZ
xxARrhBx+MeSeJzS5otSUmrQOMZTMpKl3bKp4u/l84HUMw5PMwGA3SneJhzLvPvu
utKQiYIlX8WarrGX2OE78MpWeEPZhiMXD4lKZk2hBcmtIW4JfmW8eOta92UBqVHb
XGQqCJ9koS020+d0zZaQtt53ZQ19Nes5jMjpCvSr6DxAXyTUCNklakv7DwWXN948
4vXKBj57CBPdOgK9v1fdHwez+C3iZKRfVGd6LMjeSfaoNKPJQqWwY4OcLp4NuIHZ
B46/onunFse2vibhHVjx
=+QXF
-----END PGP SIGNATURE-----
Follow ups
References
-
Re: Potential issues with oaa_ lib
From: �vind Aabling, 2010-08-28
-
Re: Potential issues with oaa_ lib
From: Alex G, 2010-08-28
-
Re: Potential issues with oaa_ lib
From: Lorenzo Marcantonio, 2010-08-29
-
Re: Potential issues with oaa_ lib
From: Alex G, 2010-08-29
-
Re: Potential issues with oaa_ lib
From: Lorenzo Marcantonio, 2010-08-30
-
Re: Potential issues with oaa_ lib
From: Alex G, 2010-08-30
-
Re: Potential issues with oaa_ lib
From: Lorenzo Marcantonio, 2010-08-30
-
Re: Potential issues with oaa_ lib
From: Alex G, 2010-08-30
-
Re: Potential issues with oaa_ lib
From: Lorenzo Marcantonio, 2010-08-30
-
Re: Potential issues with oaa_ lib
From: Alex G, 2010-08-30
-
Re: Potential issues with oaa_ lib
From: Lorenzo Marcantonio, 2010-08-30
-
Re: Potential issues with oaa_ lib
From: Alex G, 2010-08-30
-
Re: Potential issues with oaa_ lib
From: Lorenzo Marcantonio, 2010-08-31
-
Re: Potential issues with oaa_ lib
From: �vind Aabling, 2010-09-05
-
Re: Potential issues with oaa_ lib
From: Alex G, 2010-09-08
-
Re: Potential issues with oaa_ lib
From: Lorenzo Marcantonio, 2010-09-08