| Thread Previous • Date Previous • Date Next • Thread Next |
On Mon, 30 Aug 2010, Alex G wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1The .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?
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 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 :). AlexHaving 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 ...
Alex
Øyvind.
| Thread Previous • Date Previous • Date Next • Thread Next |
