← Back to team overview

kicad-developers team mailing list archive

Re: A few extra component footprins


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 '.
>         '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 ;-)
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?

>>>>>> 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 ...
Now that we have the IGES specs, there's no need to fiddle with STEP.

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/


Follow ups