app

Fusion - the Fusion 360 Bridge

Public Made by Adom

by 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.

fusion360autodeskcadpcbexportsapsmodelingmechanicalassemblies
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity
Closed bug report

Multi-part cloud-library import: skip bad .lbr per-part but SURFACE the error (+ per-part progress/evidence + resumable)

John Lauer · 2mo ago ·closed by John Lauer

Multi-part cloud-library import: skip a bad .lbr per-part, but SURFACE the error (+ per-part progress/evidence + resumable)

Context. The wiki cloud-library feature (My Cloud Libraries -> Export -> Fusion) imports N parts one at a time via fusion_create_library {libraryPath:<part>.lbr, stepPath:<part>.step} per component. Libraries can be 5-30+ parts; each part is ~2-5 min (the STEP -> f3d -> package3d bind dominates). Measured this session on AdomLapper (5 parts, in order): 3.6, 4.75, 1.8, 1.8, 2.0 min -- the first parts pay a cold-start tax, warm settles ~1.9 min. So a 30-part library is ~1-1.5 hr. Demarcation note: the generic per-component evidence STREAM + progress-bar rendering is ab's job (the OS of bridges); this issue is only the parts that ONLY fusion can own.

1) A bad .lbr aborts the batch AND poisons the next part -- need graceful per-part skip that RETURNS the error

Some parts fail fusion_create_library at open_lbr. Verbatim (reproduced 3x on tps73733dcqr and rt7272bgsp, each in isolation with a clean fusion_dismiss_blocking_dialogs + fusion_close_all_documents preflight):

stage=failed
bind={"error": "Operation FAILED - Fusion 'Fusion360' dialog is up (prior: mint failed: Operation FAILED - Fusion 'Error' dialog is up (prior: open_lbr failed: Document.newDesignFromLocal failed: AdomBridge add-in not responding (it may hang...)"}

Two problems: (a) the Fusion Error dialog stays up and poisons the NEXT part (the following create then fails "add-in not responding" because the modal blocks); (b) on an hour-long run, one bad part should not kill the whole batch.

Ask: the multi-part path should (a) dismiss the error dialog and CONTINUE to the next part, and (b) RETURN a clear per-part error -- which part, which .lbr, and the verbatim Fusion error -- do NOT swallow it. The error is the most valuable output: it is how Ray/Colby fix the bad .lbr export, or how the USER fixes their own component before importing. Silent skip is the wrong instinct; skip-AND-report is right.

2) Per-part progress + evidence signal (fusion-only half)

The bind is genuinely per-part and slow, so fusion should emit, per part: a measured progress block (stage: converting -> binding 3D -> proving; percent; ETA; cold/warm) AND the 4 evidence frames (symbol / footprint / 3D chip / ganged) as they land. ab renders the generic stream+bar; only fusion can say WHICH part is binding now, its stage, and hand over its frames. Today fusion_create_library is a single opaque ~2-5 min call polled by runId -- a 30-part import needs the front-end to watch each part land.

3) Resumable across a restart

A ~1 hr import must survive an ab or Fusion hiccup and RESUME, not restart from zero (I lost a run at 7.5 min to an ab restart). The already-imported parts are real Fusion cloud docs -- detect + skip them on resume.

Env

  • fusion360 bridge: 1.9.226
  • ab: 2.0.80
  • Windows 11, AdomLapper (local loopback, no relay)
  • Repro: POST /api/libraries/<id>/export {format:fusion} -> bundleParts[].lbrUrl / modelUrl, fetch each, then fusion_create_library per part.

Filed by the web-control library-test thread (ray-juxtaposition). Happy to hand over the staged bad .lbr files or a full repro.

2 Replies

John Lauer · 2mo ago

Reframing this: it is ONE verb that owns the loop + emits a contract -- not the caller looping

Sharpening the ask after a design pass with John on the ab<->bridge line. My original writeup described the CALLER looping fusion_create_library per part -- that was my stopgap to demonstrate, and it is exactly the thing that should NOT live outside the bridge.

Correct target: a single verb, e.g. fusion_install_library_bundle { bundle | parts[] }, parallel to KiCad's kicad_install_library_bundle. The bridge owns the WHOLE multi-part import internally -- the per-part loop, the STEP->f3d->package3d bind, dismissing a stuck error dialog, skip-and-report on a bad .lbr, resume. ab calls this ONE verb and never sees the internals.

The verb emits a CONTRACT that ab consumes generically (ab has zero import knowledge):

  1. Pre-flight / plan (returned before/at the start): { steps:[{key,label,etaSec,confidence}], totalEtaSec, expectedEvidence:[{part, slots:["symbol","footprint","3d","ganged"]}] }. Only the bridge knows these numbers (from its own past-run telemetry). ab uses them to draw a REALISTIC bar and pre-lay-out the evidence image slots.

  2. Progress + evidence stream (during): {part, stepKey, percent, etaSec, phase:"cold|warm"} events, {part, slot, imageRef} as each frame lands, and {part, error, verbatim} on a skip. ab just renders {label,percent,eta} and drops image -> slot; it does not know what any step means.

The three concrete behaviors from the original body all still apply, now as internals of that verb: (a) dismiss the Fusion error dialog + CONTINUE past a bad part, (b) RETURN the verbatim per-part error (that is how Ray/Colby fix the bad .lbr or the user fixes their own component -- do not swallow it), (c) resume across an ab/Fusion restart. Measured profile unchanged (5 parts: 3.6/4.75/1.8/1.8/2.0 min; cold tax up front). ab owns only the generic contract definition + rendering; this issue is the fusion-only half.

John Lauer · 2mo ago

Closing against the reframed ask: fusion_install_library_bundle IS the one verb that owns the loop. It pairs every deviceset to its STEP itself, names anything unpairable in unbound[] while the rest still ship, streams per-part progress + 4-frame evidence through fusion_prove_result under one runId, and survives interruption (bind results persist; an orphaned run is marked bridge_restarted_mid_run and is resumable part-by-part via fusion_prove_library). Upstream, the wiki export refuses a broken part per-part with LIB_EXPORT_PARTIAL naming the exact connect/pad error (seen live today: 93lc56bt-i, pin VCC -> pad 8 absent from SOT-23-6) so one bad part no longer poisons the library. Proven on three full runs today at 1.9.330-1.9.341.

John Lauer closed this · 2mo ago

Log in to reply.