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 general

assembly_bom on electronics 3D PCB docs exceeds the relay window and blocks the add-in main thread (found by the daily verb suite)

John Lauer · 3mo ago ·closed by John Lauer

Found by the daily verb test suite (dev-skills/fusion-verb-tests), first full run day.

fusion_assembly_bom on an electronics 3D PCB document (the BQ25792 demo board) runs for minutes and never returns inside the relay window: the 3D PCB's occurrence tree carries an occurrence per pad, so the walk that is instant on mechanical assemblies grinds, the add-in main thread stays busy, and the next several verbs cascade-fail with main_thread_busy / fusion_addin_not_responding until it finishes.

Repro: open Molecules/XRP/Power/BQ25792.fprj, switch to the 3D PCB view, call fusion_assembly_bom {}.

Not a regression from the 1.9.3 transparency fields (per-occurrence work is unchanged); mechanical assemblies (Oliver's 744-instance Wirebening desk) complete fine. The verb was designed for mechanical designs and electronics 3D PCBs are a pathological input.

Fix directions, in preference order:

  1. Async job pattern: return fast with a job token, expose progress via the statusVerb, stash the result (the same shape the old cloud walk should have used).
  2. A maxSeconds budget arg returning partial results plus a continuation cursor.
  3. Cheap immediate guard: detect an electronics 3D PCB (DesignProductType generated from a .brd) and refuse early with a hint pointing at fusion_export_bom (the electronics BOM), which is the right verb for boards anyway.

Option 3 can ship immediately and may be the correct UX regardless: a user asking for a BOM on a BOARD wants the electronics BOM, not a mechanical occurrence walk. Suite-side, the real-board case is demoted to the weekly tier with a known-slow annotation until this lands.

2 Replies

John Lauer · 3mo ago

Shipped the immediate fix in v1.9.7 (add-in 1.0.6): fusion_assembly_bom now carries a walk budget.

  • maxSeconds arg, default 20. A pre-check refuses instantly when the design has more than 3000 occurrences (the occurrence-per-pad 3D PCB signature), and the walk itself raises past the deadline, returning bom_walk_budget_exceeded with occurrences, budgetSeconds, and partialParts instead of blocking the add-in main thread for minutes.
  • The refusal _hint redirects boards to fusion_export_bom and tells genuinely huge mechanical assemblies to re-run with a raised maxSeconds.
  • Verified live on AdomLapper: the restored session document now refuses in-budget instead of timing out the relay, and the daily verb suite passes with either shape (a BOM on a small doc, the fast refusal on a pathological one) counted as working-as-designed.

Still open on this issue: the async redesign (fire the walk off-thread, poll for the result) so a raised maxSeconds on a big mechanical assembly does not tie up the relay either. Leaving this issue open to track that.

John Lauer · 2mo ago

Closing: the reported defect is fixed and has stayed fixed. Being explicit about what did and did not ship, because one of the three fix directions is deliberately not being pursued.

Fixed (v1.9.7, add-in 1.0.6, option 3): fusion_assembly_bom carries a walk budget. A pre-check refuses instantly above 3000 occurrences (the occurrence-per-pad 3D PCB signature), the walk itself raises past maxSeconds (default 20), and the refusal returns bom_walk_budget_exceeded with occurrences, budgetSeconds and partialParts, plus a _hint redirecting boards to fusion_export_bom. The daily verb suite asserts either shape - a BOM on a small doc, or the fast refusal on a pathological one - so a regression fails a test rather than a customer session.

Not implemented: the async job redesign (option 1). The walk runs inside the add-in on Fusion's MAIN thread, so a genuine job pattern needs the walk chunked across main-thread slices - a real piece of add-in work, deployable only with Fusion closed. I am not shipping that untested, and more to the point I no longer think it is the right shape here: option 3 turned out to be the correct UX rather than a stopgap. Someone asking for a BOM on a board wants the electronics BOM, and fusion_export_bom is that verb. The mechanical occurrence walk on a 3D PCB was always the wrong tool, so refusing fast and redirecting beats making the wrong answer available asynchronously.

If a genuinely huge MECHANICAL assembly ever needs longer than the budget, maxSeconds raises it, and that is the case where async would actually earn its complexity. Reopen with that case and I will build it.

John Lauer closed this · 2mo ago

Log in to reply.