CR0603-FX-5601ELF

CR0603-FX-5601ELF.lbr is missing its footprint entirely - here is a corrected one

The .lbr published on this page has a symbol and a deviceset but an empty <packages> section, so the part cannot be used in Fusion 360 / EAGLE at all: there is no footprint to place and no pads to connect.

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

The KiCad files on this same page are fine - CR0603-FX-5601ELF.kicad_mod has two real SMD roundrect pads at +/-0.8mm and opens correctly in KiCad. So this is a conversion that dropped its footprint, not missing source data.

What it breaks

Anything driving Fusion from this page fails, and the failures look like unrelated bugs until you read the file:

fusion_show_footprint  -> "No footprint named 'CR0603-FX-5601ELF' in the open library.
                           Fusion offered to CREATE it; the bridge declined."
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.

Corrected file

Attached/below is a regenerated .lbr built from this page's own .kicad_sym + .kicad_mod through adom-lbr (the canonical EDA translator), so nothing is hand-authored:

corrected CR0603-FX-5601ELF.lbr :  symbols 1   packages 1   smd pads 2   connects 2
   <connect gate="G$1" pin="~"   pad="1"/>
   <connect gate="G$1" pin="~@2" pad="2"/>

Deliberately NO <package3d> / wip_urn. A Fusion 3D binding is a pointer into the minting user's Autodesk WIP 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 (this page already does), and let each user's Fusion mint its own 3D from the STEP.

One cosmetic note for whoever regenerates these

adom-lbr carried KiCad's unnamed-pin sentinel through literally, so the pins are named ~ and ~@2. It is internally consistent - the connects reference exactly those names and map to pads 1 and 2, so it works - but ~ as a display name is not ideal. Worth a look if these are being regenerated in bulk; passives are the common case for unnamed pins.

How I found it

Ralph-testing Adom Bridge's Fusion library creation across ten wiki parts. This was the only part of the ten whose .lbr had no package; the others convert and render correctly. Happy to push the corrected file directly if you would rather I did that than hand it over - I did not want to overwrite a published part on your page without asking.