← Back to team overview

kicad-developers team mailing list archive

Re: A few extra component footprins


On Mon, 30 Aug 2010, Alex G wrote:

Hash: SHA1

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 ;-)

WOW! Learning Perl will have a very steep curve. But it's something I'll
have to do if I want to beof any meaningful help. BTW, how long does it
take for the script to generate all of the components?

After a poweron/reboot: 55-60 seconds on a 2.67GHz Intel Core I7.

Subsequent makes takes only about 45 seconds,
as all relevant files are cached in memory :-)

This time includes building all necessary perl structures
for the 914 parts in memory (including the 3D stuff), and
comparison with the current set of components and libs.

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
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 ...

Now that we have the IGES specs, there's no need to fiddle with STEP.

I've begun looking at IGES, and it's a bit of a
beast, but more on that in my next posting ...



Follow ups