BOM Forge built on this bridge: request native mechanical BOM and physical-properties verbs

Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests2 Activity

Closed feature request

Oliver · 18d ago ·closed by John Lauer

What I built on this bridge

I published BOM Forge (/adom/bom-forge, public), a costed bill-of-materials generator for mechanical Fusion designs. It leans entirely on this bridge:

fusion_get_app_state to resolve the active design.
fusion_run_modeling_script for two things: (1) a recursive, kit-aware occurrence walk that reproduces Fusion's structured Manage -> BOM (recurse organizational subassemblies, stop at physical parts and purchased kits/units), and (2) reading per-component physicalProperties.volume (cm3) to price 3D-printed parts.

Real result: run on "Wire Bender v8" and a base-scaffold assembly, the structured walk fixed screw/drop-in-nut overcounting that a flat allOccurrences walk produced (for example T Nut Drop In 2020 M5 28 -> 14, hardware bundled inside "with fasteners" bracket kits no longer double-counted). Output is written to a Google Sheet in the team working-BOM format.

Two gaps that forced custom scripting

No mechanical/assembly BOM export. fusion_export_bom is electronics-only: on a Design-workspace mechanical assembly it returns No board open (current workspace: Design). Open a .brd file first. There is no verb that returns the assembly parts list, so I had to replicate Fusion's structured BOM inside a modeling script.
No physical-properties verb. To get volume/mass I call getPhysicalProperties inside fusion_run_modeling_script, which runs on Fusion's main thread under the ~60s HTTP cap, so large assemblies need batching.

Requests

A mechanical BOM verb (for example fusion_export_assembly_bom): structured + kit-aware, returning component name, quantity, material, and optionally part number/description, as JSON or CSV. That would let tools drop the hand-written occurrence walk.
A physical-properties verb (for example fusion_physical_properties {names?}): per-component or per-body volume (cm3), mass, and density, so tools do not have to run getPhysicalProperties in a modeling script.

Happy to share the exact walk script if useful. Thanks for the bridge, it made this possible.

3 Replies

Oliver · 18d ago

Proposed plan to close the two gaps

Gap 1: native mechanical / assembly BOM

Add a Design-workspace BOM path so callers stop hand-writing an occurrence walk.

Verb: fusion_assembly_bom (or branch the existing fusion_export_bom on workspace: PCB board open gives the electronics BOM, a Design assembly gives this one).
Args: structured (hierarchical with a Level column) vs flat (parts-only), treatAsUnit (name patterns whose subassemblies are counted once and not exploded, default ["with fasteners"]), outputPath (optional CSV), and an exclude list.
Logic: recurse rootComponent.occurrences, stop at a physical part (bRepBodies.count > 0) or a treatAsUnit subassembly, recurse organizational subassemblies. This is the kit-aware walk BOM Forge already runs, so the counts match Fusion's Manage to BOM (for example a "with fasteners" bracket kit is counted once, its internal screws and drop-in nuts are not double-counted).
Return per row: level, componentName, partNumber (from component.partNumber when set), description, quantity, material, optional volume_cm3 / mass_kg.
Output: JSON by default, CSV to outputPath to match the existing export pattern.

Gap 2: physical-properties verb

Verb: fusion_physical_properties.
Args: names (optional list of component names; default all), accuracy (low | medium | high, default low), scope (component | body).
Return per entry: volume_cm3, mass_kg, density, area_cm2, bbox, center_of_mass.
Logic: iterate the requested components, call getPhysicalProperties(accuracy). Since this is main-thread and the HTTP call is ~60s-capped, batch internally and, for large sets, return a job token and let callers poll (the same async pattern the APS verbs use).

Rollout

New verbs, backward compatible; existing fusion_export_bom unchanged (or gains the workspace branch).
Register both in fusion_describe, update the bridge docs and skill.
Once shipped, BOM Forge drops its embedded walk and calls fusion_assembly_bom + fusion_physical_properties directly.

I can prototype the assembly-BOM walk as a reference implementation if that helps.

Oliver · 18d ago

Implemented in PR #22 on this page (adds fusion_assembly_bom and fusion_physical_properties), validated live against an open assembly (kit-aware counts match Manage -> BOM). Ready for review/merge.

John Lauer · 18d ago

Merged and shipped in v1.7.14. Both verbs are live: fusion_assembly_bom and fusion_physical_properties.

Thanks for doing this the way you did, discussion with a concrete plan first, then a PR validated against a real assembly. The counts are what made it reviewable: 28 -> 14 on T Nut Drop In 2020 M5, 44 -> 18, 46 -> 20, and fully-bundled hardware correctly dropping to 0. That shows the double-count being fixed rather than relocated.

One thing I fixed on merge

Your handlers were registered in the add-in dispatch (commands/__init__.py) and described in describe.py, but not added to the bridge's ADDIN_COMMANDS proxy set in server.py. Without that, the bridge never forwards the command to the add-in, so fusion_assembly_bom would have failed from the CLI no matter how well the handler worked. Easy one to miss, since it is a third registration point in a different file from the other two, and your live validation would have passed if you exercised the add-in directly.

Added both, with 300s timeouts, since getPhysicalProperties runs per component on Fusion's main thread and a large assembly with includePhysicalProperties: true can be slow.

Notes for BOM Forge

includePhysicalProperties defaults to false, which is right. When you only need a few parts, prefer fusion_physical_properties {names: [...]} over pulling properties through the whole BOM walk.
The merged BOM aggregates to a flat parts list with quantities rather than carrying the Level column from your plan. That matches Manage -> BOM counts, which is what a purchasing BOM needs. If BOM Forge wants the hierarchy later, open a follow-up and we can add level without breaking the current response shape.
Your treatAsUnit default covers both "with fasteners" and "with fastener". Worth knowing it is a case-insensitive substring match, so kit naming conventions beyond that need to be passed explicitly.

You can drop the hand-written occurrence walk now. If the kit-aware rule mismatches Fusion's own BOM on some assembly shape, that is a bug on this page and I want to hear about it.