Open general

Five of your component .lbr files are incomplete for Fusion 360 (one has no footprint at all) - corrected files ready

John Lauer · 2mo ago

Six of your component pages ship a .lbr that Fusion 360 cannot use - corrected files generated, happy to hand them over

I have been ralph-testing Adom Bridge's web-control Fusion library creation across the Adom demo components. Six of the affected parts are on your pages:

0402B102J500CT, CL21B104KBCNFNC, CR0603-FX-5601ELF, IN-S42ATR, WS2812B-2020

The problem

CR0603-FX-5601ELF.lbr is the worst case - it has a symbol and a deviceset but an empty <packages> section, so there is no footprint at all:

published CR0603-FX-5601ELF.lbr :  symbols 1   packages 0   connects 0

Fusion then fails honestly and confusingly:

fusion_show_footprint  -> "No footprint named 'CR0603-FX-5601ELF' in the open library."
fusion_bind_library_3d -> "Create3DPackage failed: Footprint XML does not contain any
                           footprint information."

The 3D failure is downstream of the missing package - Fusion mounts a 3D body onto a footprint, so with no package there is nothing to attach the STEP to.

Your KiCad files are fine. CR0603-FX-5601ELF.kicad_mod has two real SMD roundrect pads and opens correctly in KiCad. This is a .lbr generation that dropped its footprint, not missing source data.

Corrected files

I regenerated a .lbr for each from your own .kicad_sym + .kicad_mod using adom-lbr 2.7.1 generate (the canonical EDA translator), and validated every one:

0402B102J500CT     symbols 1  packages 1  connects 2   valid deviceset
CL21B104KBCNFNC    symbols 1  packages 1  connects 2   valid deviceset
CR0603-FX-5601ELF  symbols 1  packages 1  connects 2   valid deviceset
IN-S42ATR          symbols 1  packages 1  connects 2   valid deviceset
WS2812B-2020       symbols 1  packages 1  connects 4   valid deviceset

Each was additionally checked so that every <connect> references a pin that exists in the symbol and a pad that exists in the package - adom-lbr validate does NOT check that, and it matters (see below).

Deliberately no <package3d> / wip_urn. A Fusion 3D binding is a pointer into the minting user's Autodesk cloud storage (urn:adsk.wipprod:...), not embedded geometry, so it is not portable and must never ship in a published library. The correct pattern is: publish symbol + footprint, ship the .step alongside (your pages already do), and let each user's Fusion mint its own 3D from the STEP.

Want me to push them?

I did not want to overwrite published parts on your pages without asking. Say the word and I will push all five (six including any others you want checked), or I can attach the files here for you to review first.

For context, the equivalent adom-org-owned parts have already been updated this way, and the same regeneration is what a component linter should enforce going forward.

0 Replies

Log in to reply.