← Back to team overview

kicad-developers team mailing list archive

Re: A few extra component footprins


On Sun, 29 Aug 2010, Alex G wrote:

Hash: SHA1

Yes, although I would place the size first, I think:
TDFN8-3X3-M065, as the pitch is given (not always,
but mainly) by package size and pin count.

Agreed. I only suggested the size after the pitch,, so that it would
look nice in a list




Not much of an issue.

They do have a package, igesgump, that can be downloaded,
and it contains an IGES file peeker and a viewer (2D only),
but it was last changed in 2004, and they want USD5000 (!)
for the source code, so nothing interesting there ...

One of the torro-fecal things in life. I assumed that they must have the
*cough* Lite *cough* version

No such luck - I also looked at the C code they have for download -
it's useless, requires their lib, and contains no useful information.

I'll have a go at deciphering the IGES format - if we can
extract as a minimum a point cloud from IGES, we can use the
coords to get the correct dimensions of a package, including
details like mounting/guide pins, locking tabs and other such
stuff that's usually not specified in detail in the datasheets.

So then we could simply use the IGES files provided by molex instead of
creating .dim files. I like where this is going. The yellow circles at
the bottom represent the necessary holes in the footprint. I'll have a
try at identifying those bits (proably by trial and error with Inventor).

The .dim files are not input, but output created by the perl code.

Some dimensions are defined in (hierarchical) tables, or defined as
attributes on the part name, while others are calculated, so the .dim
files are for double-checking that the math and table logic is OK :-)

Here is how the definition of resistors looks:

%ATTR = ('' => 'unit=mm dims=OUTER(1,$e,$DS) Q=3.5 s=0.5 lw=120 '.
  RA => 'silk=AXIAL($L,$D,$e,0) body=AXIAL($L,$D,$s,"R","R") '.
  RV => 'silk=AXIALV($L,$DS,$e) body=AXIALV(-$e/2,$L,$D,$s,"R","R") '.
 'R1.6' => 'L=3.7  DS=2.3 D=1.6 Pad=1.6 Dr=0.6 d=0.5',
 'R2.3' => 'L=6.5      DS=D=2.3 Pad=1.6 Dr=0.7 d=0.6',
 'R3.5' => 'L=9.5      DS=D=3.5 Pad=1.6 Dr=0.9 d=0.8',
 'R4.5' => 'L=14.2     DS=D=4.5 Pad=2.0 Dr=1.1 d=1.0',
 'R6.0' => 'L=17.8     DS=D=6.0 Pad=2.5 Dr=1.3 d=1.2');

@PART = qw(
  R-M2.5V:D=1.6  R-I100V::D=1.6
  R-M3V:::D=2.3  R-I150V::D=2.3
  R-M5V:::D=3.5  R-I200V::D=3.5
  R-M7.5::D=1.6  R-I300:::D=1.6
  R-M10:::D=2.3  R-I400:::D=2.3
  R-M12.5:D=2.3  R-I500:::D=2.3
  R-M15:::D=3.5  R-I600:::D=3.5
  R-M20:::D=4.5  R-I800:::D=4.5
  R-M25:::D=6.0  R-I1000::D=6.0);

Also, there's a function that parses the part name,
and determines which entries in %ATTR should be
included (the null key '' gets included for all parts).

As you can se, adding the two extra resistors (R-M12.5 and
R-I500) that you suggested, required only one extra line ;-)

I don't know which will be easiest, as that depends on the
available info on the file formats - probably not much :-(

I thought that converting some faces from an *existing* model would be
the easiest route. If we end up generating the models from Perl, we
could include the metal piece in the middle of the hole, which, for some
reasom, Molex seems to have overlooked.

I say let's keep the focus on generating the footprints, those are the
heart of the matter. The 3D packages can be added after the footprints
are done. That is of course, if you have no preference on getting both
ready at the same time :).


Having looked a bit more at the IGES files, I think the DIY approach is
the easiest, at least unless we can get hold of the full IGES specs :-(

STEP is also a no-go - it's an ISO standard, and thus not free.
Even if we _did_ manage to write a STEP to VRML converter, we
probably couldn't release the source because of license issues :-(

Just when I was begining to think software patents can never possibly
affect me. If we somehow did manage to write a Molex3DtoVRML, it
wouldn't technically be a STEP to VRML converter; still troublesome, and
then STEP is binary (I think).

What I meant was, that if we somehow got hold of the
ISO standard, we probably couldn't release the source
of a STEP-to-whatever converter based on that info.

If we reverse engineered STEP, it's another matter, but doing
that is a hard task that I wouldn't even begin considering ...

The igespeek program (igesgump package from wiz-worx) lists these
entities in the IGES file for the two-pin, right angle Molex Microfit:

count   type   description
  30  100:0000 Circular Arc
   5  102:0000 Composite Curve
 373  110:0000 Line
   9  120:0000 Surface of Revolution
  30  124:0000 Transformation Matrix:Right-handed (default)
 130  128:0000 Rational B-Spline Surface - <computationally derived>
   1  186:0000 Manifold Solid B-Rep Object
   3  314:0000 Color Definition
   2  402:0007 Associativity Instance:Unordered Group Without Back Pointers
   4  406:0015 Property:Name
   1  502:0001 Vertex:MSBO Vertex List
   1  504:0001 Edge:MSBO Edge List
 144  508:0001 Loop:MSBO Loop
 139  510:0001 Face:MSBO Face
   1  514:0001 Shell:MSBO Shell - Closed

So, I'm pretty sure, that the missing package bits you (don't)
see are simply stuff that freecad can't do, and thus ignores ...

BTW, what do you run freecad on? Did you compile it, or got a built
pakage? It won't compile on my Fedora machine, so I have to use a "that
other OS" binary in a VM.

64-bit Debian Linux, freecad 0.10.3247.dfsg-1
installed from Debian repository.

Colors in IGES are not RGB values, only indices - the standard colors are:
  0 = black
  1 = black
  2 = red
  3 = green
  4 = blue
  5 = yellow
  6 = magenta
  7 = cyan
  8 = white
In addition, there's a type 314 (Color
Definition), for redefinition of a color.

You are way ahead of me at understanding IGES.

Now that we have the specs, we can move even further :-)



Follow ups