by adom
0402 MLCC · 1 nF ±5% X7R · 50 V
Five of your component .lbr files are incomplete for Fusion 360 (one has no footprint at all) - corrected files ready
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.