Generate STL files from SparkFun library for "Standard Library"

[follower]

Ideally we'll automate this. Need to investigate how straight-forward automated export is.

[follower]

From my notes:

STL import/export support for SketchUp requires a plug-in to be installed: https://extensions.sketchup.com/en/content/sketchup-stl

While you can download it from there you need a login but if you visit the associated project on GitHub you can download the source directly: https://github.com/SketchUp/sketchup-stl/releases

Once the plugin is installed you can import a .skp and export a .stl via the Ruby console with:

    model = Sketchup.active_model
    status = model.import "/<path>/SSOP20_L.skp", false
    CommunityExtensions::STL::Exporter.export('/<path>/SSOP20_L.stl')

I also found a reference on how to run a Ruby script within SketchUp from the command line: "Is there a command line in Google Sketchup to export in 3ds or fbx format?"

[follower]

Components

The SparkFun Eagle libraries repository is here: https://github.com/sparkfun/SparkFun-Eagle-Libraries

AFAICT there is no explicit mapping within the .lbr files between the component packages and the associated models--it seems to be assumed that the package name will match the model file name (as is the apparent convention with EagleUp).

Models

The SparkFun 3D model repository is here: https://github.com/sparkfun/3D_Models

It seems to have grown somewhat haphazardly (e.g. varied model source formats, export formats and naming conventions) although it looks like there's some attention being paid to tidying it up currently.

There are two categories of models, split between the production_parts and products sub-directories.

Most individual part models (associated with the SF Eagle libraries) are found in production_parts although some (which are also sold as products) are found in products.

[follower]

In order to determine part/model coverage and how many .stl models needed to be generated I wrote a couple of file/directory scanners.

Summary of production_parts scan (via ./scan_model_repo.py ../sparkfun-github/3D_Models/production_parts/):

    Components found: 237
    Valid components: 109
    No sketchup file: 16
         No STL file: 112

A "valid component" in this sense is one for which both a SketchUp source file and exported .stl file exist. These component models should be able to be included in our standard library directly.

"No sketchup file" means that an .stl file exists but no SketchUp source file was found (often this occurs when the exported file doesn't follow the naming convention of the source file).

And the "No STL file" category are the models for which we need to generate STL files.

There were also additional cases where neither .stl nor .skp files existed which seems to occur where another design package was used (e.g. SolidWorks?).

Further analysis of products needs to occur as most models will not be relevant for us as they are not individual components. But it does seem to include EagleUp and Blender-exported .json files (exported via) which might be helpful for determining which models would be useful).

[follower]

With the information from the model scanner it's possible to determine how much model coverage there is of the SparkFun Eagle libraries (via ./scan_library_repo.py ../sparkfun-github/SparkFun-Eagle-Libraries/):

Total libraries found: 20
 Total packages found: 1579

(Note that the package total includes duplicates due to the "same" part (in name, at least) appearing in multiple libraries.)

For a clearer view of the model coverage it's helpful to look at the individual libraries (this is a count of models found (in either .skp or .stl format) versus the number of packages found in the library):

    GeekAmmo 3 / 18
    LilyPad-Wearables 1 / 25
    SparkFun-Aesthetics 0 / 91
    SparkFun-AnalogIC 12 / 38
    SparkFun-Boards 1 / 63
    SparkFun-Capacitors 16 / 88
    SparkFun-Connectors 32 / 388
    SparkFun-DigitalIC 32 / 120
    SparkFun-DiscreteSemi 16 / 47
    SparkFun-Displays 1 / 24
    SparkFun-Electromechanical 12 / 151
    SparkFun-FreqCtrl 4 / 26
    SparkFun-LED 10 / 31
    SparkFun-Passives 16 / 102
    SparkFun-PowerIC 16 / 73
    SparkFun-RF 8 / 93
    SparkFun-Resistors 7 / 28
    SparkFun-Retired 7 / 45
    SparkFun-Sensors 21 / 119
    User-Submitted 4 / 9

Note that some packages (e.g. ones in SparkFun-Aesthetics ) don't need models because they're board features (e.g. logos, solder jumpers) rather than components.

In other cases package names have an suffix (e.g. -KIT) which suggests it's a different footprint but doesn't require a different component model. If so, then the alternate name can be mapped to the existing model.

It doesn't appear at first glance that there is very high model coverage in most cases, although manual mapping of alternate names would presumably help.

(If desired I can attach the output with the complete per-package model coverage.)

[follower]

The third scanner uses the component model information to determine coverage for specific board designs (via ./scan_board_files.py ../omniblox.github.com/Eagle-Loader/examples/brd-files/):

    feather (2/19)
    adafruit_flora_mainboard_2 (1/22)
    gemma (1/14)
    neopixel_ring_12 (0/5)
    trinket (2/14)
    photon (1/9)
    picobuck (4/13)
    sparkfun_redstick (15/24)
    sparkpunk (0/20)
    SparkFun_ESP8266_Thing_v10 (16/35)
    thing (16/35)

Additional details show that in most cases the "missing" models for SparkFun boards tend to be for packages that don't actually require a model.

Summary

This initial analysis seems to confirm the value of providing a standard library with mappings because otherwise the amount of effort required to get useful results is non-trivial (especially given there are many additional sources of models (which vary in quality and comprehensiveness)). Although there are potential concerns around comprehensiveness vs load times which may need to be alleviated.

With these tools and this analysis we can now track progress as we automate the generation of models and create the mappings.

[follower]

Pushed commits with missing batch generated STL files (Note: GitHub will try to render all these files if you click on the commit links):

• 3f88e3ebbd986b622fb2c461d83b236b955a3713 -- Majority of the files (136), which appear correct.
• 8569e0905ea318bd981e2043a2b356a4202bce8c -- Single file (1), possibly upside down.
• dfaa5bd86a8a5358d1b28ad9d3985b4871a27d2d -- Faulty exports, (4) missing faces. Need model edits.

These were generated by automating SketchUp and then baby-sitting the automation. Baby-sitting was required because the exporting seem to fail non-deterministically with either segfaults or Ruby errors. Eventually re-running the automation enough times generated all the files. (This was using SketchUp 2015.)

[follower]

We might want to transfer the branch/fork from my account to Omniblox if we're going to offer to push the generated models back to SparkFun.

[follower]

Script used to automate the generation of the STL files: https://github.com/Omniblox/pcb-component-models/blob/master/tools/generate_missing_stl.rb

(So we can use it again if we decide we want to use a different model format.)

[follower]

With generated STL files in place (via ./scan_model_repo.py ../sparkfun-github/3D_Models/production_parts/):

    Components found: 237
    Valid components: 219
    No sketchup file: 16
         No STL file: 2

The 2 "No STL file" items are due to difference in handling of case insensitive file systems.

Thus 110 more valid components. Note that due to duplicate names this is fewer than the number of generated component models.

[dave5]

when you want to work in the main repo - flick me a pull request from your fork. after that then branch the main repo

[follower]

These are currently located here: https://github.com/Omniblox/pcb-component-models

[follower]

Current status:

• Offered to create PR to merge models into original repo: Request for export of TQFP32-08 model files sparkfun/3D_Models#178 (comment).
• Can close this ticket after that.

[follower]

PR created: sparkfun/3D_Models#238