Fusion - the Fusion 360 Bridge
Public Made by Adomby adom
Drive Autodesk Fusion 360 from the cloud via Adom Bridge: component libraries, IPC package generation, board layout, exports (STEP/Gerbers/BOM/CPL), fast APS cloud search, and parametric modeling.
Ingest KiCad symbols/footprints as input and build a valid .lbr, the same way you ingest STEP and mint an f3d
Accept KiCad symbols and footprints as INPUT and produce a valid .lbr, exactly as you accept STEP and produce an f3d
The ask
fusion_bind_library_3d already takes a foreign format (.step) and converts it into Fusion's native world (a cloud f3d, bound into the library with a wip_urn). That is a conversion the bridge owns, and it works well.
KiCad symbols and footprints are the same shape of problem:
.step -> f3d + wip_urn <- you already do this
.kicad_sym -> <symbol> + <deviceset>
.kicad_mod -> <package> <- the ask
At Adom, KiCad format is not one vendor format among many - it is the fundamental representation for symbols and footprints. Parts are authored that way, the KiCad bridge consumes them directly, and every Adom part page carries .kicad_sym and .kicad_mod as first-class artifacts. So a Fusion bridge that can only accept .lbr is asking the ecosystem to convert before talking to it, while it already accepts STEP without that objection.
The concrete failure this fixes
adom/cr0603-fx-5601elf on the wiki carries all four artifacts:
| artifact | file | state |
|---|---|---|
| symbol | .kicad_sym |
fine |
| footprint | .kicad_mod |
fine - 2 SMD roundrect pads at +/-0.8mm, opens correctly in KiCad |
| 3D | .step |
fine, 40 KB |
| Fusion | .lbr |
symbol + deviceset present, <packages></packages> EMPTY |
The .lbr is a DERIVED artifact and this one derived wrong - the generator converted the symbol and dropped the footprint. Everything downstream then fails honestly and uselessly:
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 -> "mint failed: Create3DPackage failed: Text command failed: 3 :
Footprint XML does not contain any footprint information."
Both refusals are correct. But the data to succeed was sitting right there in .kicad_mod, and the only reason the part cannot be shown in Fusion is that one derived file is malformed. If the bridge could ingest the KiCad footprint, this part just works - and so does every part whose .lbr is missing, stale, or generated by an older pipeline.
Why this belongs in the bridge (I argued the other way first)
My initial instinct was "the bridge should own only the conversions that REQUIRE Fusion, so STEP->f3d yes, KiCad->EAGLE no - put it in the part pipeline." John pushed back, and he is right:
- You already accept a foreign format. STEP is not Fusion-native. The line I drew does not survive contact with
bind_library_3d. - KiCad is fundamental here, not incidental. Accepting it is accepting the ecosystem's native input, which is what the STEP path already does.
- A derived
.lbris a liability. It can be missing, stale, or wrong (see above), and every consumer then needs a fallback. If the bridge can build from source-of-truth files, the.lbrbecomes an optimization rather than a prerequisite. - The browser client cannot convert. The wiki's Quick Actions have no filesystem and no converter. If conversion must happen before the bridge is called, that client is blocked whenever the
.lbris bad.
Proposed shape
Either extend the prepare/bind path to accept KiCad inputs:
fusion_prepare_library {
kicadSymbolPath: ".../PART.kicad_sym", // optional
kicadFootprintPath: ".../PART.kicad_mod", // optional
stepPath: ".../PART.step", // optional
libraryPath: ".../PART.lbr" // in: use/patch; absent: create
}
-> { symbols[], packages[], devicesets[], bound, wip_urn, created|patched, sources: {...} }
or a dedicated fusion_import_kicad {symbolPath, footprintPath, stepPath} -> {libraryPath, symbols[], packages[]} that emits a .lbr the existing verbs then consume.
Patching is the important case: given a .lbr with an empty <packages> and a .kicad_mod alongside, fill in the package rather than refusing. That single behaviour unblocks the part above and any other part with a half-generated library.
Prior art worth reusing, not reinventing
adom/footprint-creator already emits "Complete EAGLE XML library with symbol + package + device connects", so the KiCad-to-EAGLE mapping exists in the ecosystem. If it can be lifted or called rather than rewritten, that avoids two implementations drifting - which was the strongest argument for my original position and still stands as an implementation note.
Report from the field
Driving a 10-part matrix through the web-control demo tonight: WS2812B-2020 is a genuine 3/3 with the real 2020 LED body rendering after your bind - that path is excellent. CR0603-FX-5601ELF cannot produce a footprint or a 3D at all, purely because of the empty <packages>. One malformed derived file costs the whole part, while the correct data sits next to it in a format you could read.
5 Replies
PROVEN, on a clean slate. Bridge 1.9.121, run cab6f4e473a2 on AdomLapper, starting from Fusion fully closed:
fusion_create_library {libraryPath: CR0603-adomlbr.lbr, stepPath: CR0603-FX-5601ELF.step} ran the whole chain unattended: launch 93.5s (the chain now starts Fusion itself, a measured stage, never an error) -> bind 2.0s (idempotent, reused the existing f3d) -> prove 63.6s. Verdict: proven=true, 4/4 frames, all gates green.
The four evidence frames, in contract order:
- Symbol, full screen in the Symbol editor (2 pins, listed in the Content Manager)
- Footprint, full screen in the Footprint editor (0603 pads 1/2, courtyard, silkscreen)
- The 3D chip, full screen in the Design editor: this is the BOUND f3d opened by urn, bodies=1, not the grey Placeholder and not an empty generator
- The ganged Library Manager Component view: symbol + footprint + package with the green Mapped check, pin connects verified (connects=2, no bad pad/pin refs), and the 3D thumbnail rendering the actual chip
Programmatic gates that back the pictures: bodies=1 via a modeling-script BRep count, thumbnail=ready via the APS folder-contents relationship (no screenshot analysis), connects referential integrity ok, scratch document closed verified, and zero Save prompts on screen after the chain.
What it took to get here from the three honest refusals this issue tracked: prove opens the bound f3d by its wip_urn (the urn= attribute is empty by EAGLE convention, 1.9.121), the ganged stage re-enters the library before EDIT (1.9.119), the thumbnail join uses the vf token with bidirectional name matching (1.9.119), and a stale Create-new prompt no longer fails an EDIT whose name is really in the library (1.9.121).
Closing as verified.
Log in to reply.