On Thu, 26 Aug 2010, Alex G wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1Hi, 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: http://www.molex.com/pdm_docs/sd/010879805_sd.pdf 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. http://www.qsl.net/n/n4xy/PDFs/SOT54-TO92.pdf 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 few headaches. 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 ...
Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMdtMVAAoJEOYeVCFxnjTc3qEH/2IDgJm3pLo2SgjvViaCJZkT cx/f6EJgjgpNRQuJaD8klpFx2cLjQTHbnK0oTMMlYRanR97f56Q0irbvrLnJQiGU PUnazCiCYZDwqwP/7fHKORG10Z/PuKGhfL+/sjFz0VplZNSXcpNhxHeIRTNC2Z5q 5VYI2j67JC40kmHPLJTK2hSb6PAmYJ3LlpuCHIirH/ymGk6o/NH6mh03EgWfcrI7 RQjgj9epExFKM3AiZVARjx3yzbS0x0HkJlQOZp9oCTCUuBO69EPbyAspmKqPim5h 9AhVwI2poQj1/4ltB8B/LWReTyVW6rjEEzrUC3IDjDcR6LQbdF6foDUmOZnp8hE= =+MJh -----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). Øyvind.
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
