kicad-developers team mailing list archive
Mailing list archive
Re: Potential issues with oaa_ lib
On Thu, 26 Aug 2010, Alex G wrote:
-----BEGIN PGP SIGNED MESSAGE-----
I started designing a little adapter for picprog, using exclusively
components from discret, pinarray, and connector. It feels and looks
much better than the standard kicad libraries. I can't even begin to
describe how much I appreciate your work.
I noticed a few glitches:
1) The hole size for a pin in a PINARRAY_X_X package is 0.5mm. The
recommended hole size is 1.02+-.05mm:
I use a 1mm drill with no issues.
Oops, must have forgotten that the pins aren't round but square :-(
2) Same issue for TO-92 (I used TO92-MN). The hole size is 0.5mm.
According to several datasheets, the maximum width/thickness of a TO-92
pin is 0.47-0.48mm. That amounts to a diagonal of 0.665mm to 0.679mm,
With a recommended 10% clearance, the hole could be as big as 7.46mm.
I use a 0.7mm drill bit normally, so I'm not sure if going 0.8mm is
necessary, but at least 0.7.
This probably also means that the pad size should be increased.
I've increased the hole to 0.7mm.
3) R-M25, and R-I1000 have the pad diameter far too small. The pad is
1.6mm, and the hole is 1.3. that leaves a ring 0.15mm thick around the
hole; very easy to strip the copper around the pad when drilling. I
usually feel comfortable with a pad around twice as large as the hole.
For a 1.3 mm hole, I stop loosing sleep at around 2.1mm :)
A cut-n-paste error - forgot to increase the pad size with the drill size :-(
4) I would also add R-M12.5 and R-I500. Physically those would be the
standard 0.5-0.6W (R5 footprint in the standard library). I know R-M10
is adequate for those, but sometimes 12.5 is preferable.
Good idea - I've added them.
5) The D-SUB connectors:
Excellent work (and this is an understatement).
One little issue; The side pads normally accommodate some sort of
mounting mechanism. I've worked with several DB9's, and they all needed
a hole of 3.2mm. I know the pad is 3.2mm, but when generating drill
files, the hole size will be the size of the hole, not that of the
drill. That's not a big problem when drilling manually, but when using a
CNC, especially with auto-tool-change, it can give the engineer quite a
The recommended hole size varies between manufacturers, but all
datasheets that I've consulted "stated" "compatibility" with 3.2mm
holes. (Amphenol: 3.2+- 0.126; Harting: 3.1+-0.1, etc).
You're right - I don't know why I chose those values,
but I've now increased the hole to 3.2mm and the pad to
6.5mm, which is larger than MAX(M3 screw head, M3 nut).
I would also rename the library to dsub, or conn_dsub. Then the Molex
Micro-Fit library I'm dying to work on would be conn_microfit. Anyway,
semantics :) .
Yes, you're right - there are _way_ too many
connectors out there to put them all in one big lib :-)
I've renamed it to conn_db (or maybe it should be conn_db_dsub ?).
Other than these few glitches, I see no reason why it shouldn't be
merged with the standard kicad libraries. Your branch on kicad-newlib
would stay active and in developed, and ocasionally, it would be merged
with the standard libs. This way users can use the library, and
development would stay separate from the main libs. What do you say?
Well, with almost 1000 components, there's bound to be
some minor problems, like the ones you've found, so I think
that some more double-checking first would be a good idea :-)
The pad size and position on the Al SMD Caps (C-AEC-*)
is pure guesswork, as I couldn't find any land pattern
info :-(, so they definitely needs double-checking ...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
I've commited the above corrections as revision 2.
Also, I've restructured some of the code, so that only
.mod/.mdc/.brd/.dim/.wrl files that have changed gets rewritten.
That was a bit tricky, due to the timestamps for each part and the
whole lib inside the .mod and .mdc files, but I found a solution.
Before, everything got rewritten (with new timestamps), but
now, the timestamp for each part (in the Po and Ar fields)
represents the last change time for that part, and the max part
change time is reflected in the lib timestamp (.mod/.mdc line #1).