kicad-developers team mailing list archive

["�vind Aabling" <Oyvind.Aabling@xxxxxxxx>]

On Thu, 26 Aug 2010, Alex G wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> 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.