kicad-developers team mailing list archive

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

On Sun, 29 Aug 2010, Alex G wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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
>
> DFN8-M065
> TDFN8-M065-3X3
>
> versus
>
> DFN8-M065
> TDFN8-3X3-M065
>
> 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 '.
        'stdpads=DUAL($e,$Pad,$Dr,"C")',
  RA => 'silk=AXIAL($L,$D,$e,0) body=AXIAL($L,$D,$s,"R","R") '.
        'pins=AXIAL(($e-$L)/2,$D/2+$s,$Q,$d)',
  RV => 'silk=AXIALV($L,$DS,$e) body=AXIALV(-$e/2,$L,$D,$s,"R","R") '.
        'pins=AXIALV($e,$L,$s,$Q,$d)',
 '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 :).
> > >
> > > Alex
> >
> > 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 :-)

> Alex

Øyvind.