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.
master
e936bc3
1mo ago
Live obstacle-aware Fusion routing
The new fusion_plan_route verb calculates an explicit path between two named
pads from a fresh snapshot of the active Fusion board. It runs bounded,
orthogonal two-layer A* using the same conservative clearance model as
fusion_route_net. It does not use Freerouting or another external router.
Planning is read-only and returns the input revision plus plan.route and
plan.items; commits still use the existing revision-guarded mutation verb.
Required inputs: expectDocument, boardId, expectedRevision, net,
fromPad, toPad. Defaults: 0.25 mm trace, 0.6 mm via / 0.3 mm drill,
0.5 mm grid, vias allowed, via cost equivalent to 5 mm of trace, 25,000
expanded nodes and 3,000 ms time limit. Grid ranges from 0.1 to 5 mm; limits
are capped at 100,000 nodes / 5,000 ms. allowVias:false finds a same-layer
route. Returned paths are validated again with the shared geometric preflight.
The isolated test board has three SMD pad pairs and two existing copper barriers on different layers. No routing waypoints are supplied to the planner. The first pair demonstrates a same-layer detour; the second allows vias; the third has a clear direct route. Both original barriers must remain unchanged.
Native insertion regression
The first live take stopped at a read-back mismatch: inserting a nominal 0.6 mm
via at x=21, y=20 beside a 1 mm top-layer barrier at x=22 caused Fusion to push
the barrier. The failure was retained in take-01/; no mutation was replayed.
The corrected build sets CHANGE DRILL before VIA, instead of inserting a
via using the previous drill setting and changing it afterward. It also uses a
conservative via insertion radius of max(diameter/2, drill+0.3 mm) for the
preflight and search. This reserves extra space for native insertion behavior.
The regression test rejects the original tight insertion point. Exact copper
read-back remains essential: nominal exported dimensions alone do not model
every aspect of Fusion's native router or effective design-rule dimensions.
Autodesk documents the shared drill setting and design-rule-dependent via size. This source supports the drill-setting change; the observed shove and extra clearance regression come from the live test evidence.
Scope
This is a bounded two-pad path planner, not a full PCB autorouter. It does not rip up or shove existing copper, optimize routing order across all nets, route differential pairs, tune lengths, or model polygons and arbitrary stackups. It retains the rectangular, two-layer, straight-copper restrictions of the existing preflight. It may reject legal paths conservatively or exhaust its grid/node/time budget. Final acceptance always uses native Autodesk DRC.
The planner's grid search can find different paths at different resolutions; it does not guarantee the globally best manufacturable layout. A failed mutation can leave partial copper or a native shove, so inspect current state before deciding how to recover. Planning failures do not create copper.
Verified live result and videos
take-04/final.json records all three pad pairs connected, 10 total segments
(8 added, 2 original barriers), 2 vias and native Autodesk DRC with zero
errors, warnings and airwires. The calculated lengths were 54, 40 and 40 mm.
take-03 also passed routing; its recorder failed because the Fusion window
was minimized. The runner now checks window and capture dimensions before
creating copper and finalizes both recordings in finally.
fusion-obstacle-live-3x.mp4 is the 19.93-second share cut;
fusion-obstacle-live-1x.mp4 is the 49.83-second version for reading live
results. Both are 1920×1080, 30 fps and fully decoded successfully. Both were
delivered to C:/Users/john/Documents/Adom Routing Demos; the normal-speed
file was opened and visually verified in Windows Media Player.
The existing AdomActivityPalette is reused, including its branding and
close handler. Its shared _shell_html component has optional routing fields
and an SSE feed. ../live_panel.py hosts that page and feed in the container;
Windows Fusion reaches it at the verified http://localhost:8893/ endpoint.
The native message API returned empty acknowledgments on this Fusion instance,
so the demo uses SSE instead of repeated page reloads. Each displayed event
acknowledges DOM application before the next copper edit. A missing acknowledgment
stops the demo. This is presentation evidence, separate from native PCB validation.
AB records the Fusion editor and its owned palette as two native window captures,
then the renderer aligns them using call-start timestamps. Initialization can
introduce a fraction-of-a-second offset; the edit manifest records this limit.
The live text is recorded video, not reconstructed captions. The short take
keeps calculation/check displays, trims part of the completed-state tail and
adds a five-second final hold. take-04/panel-events.jsonl is a polling record
started during this take; future runs log every publish and acknowledgment.
To reproduce after preparing an isolated unrouted board and discovering HWNDs:
python3 demo/routing/live_panel.py
# In another terminal:
python3 demo/routing/prepare_live_panel.py --document YOUR_EXACT_BOARD
python3 demo/routing/obstacles/record_obstacles.py \
--document YOUR_EXACT_BOARD --take YOUR_NEW_TAKE \
--hwnd FUSION_HWND --palette-hwnd ADOM_PALETTE_HWND
Verify both windows visually and fit the palette beside the board before recording.
prepare_live_panel.py changes the existing palette URL once and preserves its
close behavior. Keep the container server alive while that display is in use.
The optional component changes do not require replacing the loaded add-in or
restarting Fusion. The installed native routing runtime remains
1.10.0-dev.routing.4, pinned for development.
# Live obstacle-aware Fusion routing
The new `fusion_plan_route` verb calculates an explicit path between two named
pads from a fresh snapshot of the active Fusion board. It runs bounded,
orthogonal two-layer A* using the same conservative clearance model as
`fusion_route_net`. It does not use Freerouting or another external router.
Planning is read-only and returns the input revision plus `plan.route` and
`plan.items`; commits still use the existing revision-guarded mutation verb.
Required inputs: `expectDocument`, `boardId`, `expectedRevision`, `net`,
`fromPad`, `toPad`. Defaults: 0.25 mm trace, 0.6 mm via / 0.3 mm drill,
0.5 mm grid, vias allowed, via cost equivalent to 5 mm of trace, 25,000
expanded nodes and 3,000 ms time limit. Grid ranges from 0.1 to 5 mm; limits
are capped at 100,000 nodes / 5,000 ms. `allowVias:false` finds a same-layer
route. Returned paths are validated again with the shared geometric preflight.
The isolated test board has three SMD pad pairs and two existing copper
barriers on different layers. No routing waypoints are supplied to the planner.
The first pair demonstrates a same-layer detour; the second allows vias; the
third has a clear direct route. Both original barriers must remain unchanged.
## Native insertion regression
The first live take stopped at a read-back mismatch: inserting a nominal 0.6 mm
via at x=21, y=20 beside a 1 mm top-layer barrier at x=22 caused Fusion to push
the barrier. The failure was retained in `take-01/`; no mutation was replayed.
The corrected build sets `CHANGE DRILL` before `VIA`, instead of inserting a
via using the previous drill setting and changing it afterward. It also uses a
conservative via insertion radius of `max(diameter/2, drill+0.3 mm)` for the
preflight and search. This reserves extra space for native insertion behavior.
The regression test rejects the original tight insertion point. Exact copper
read-back remains essential: nominal exported dimensions alone do not model
every aspect of Fusion's native router or effective design-rule dimensions.
Autodesk documents the [shared drill setting and design-rule-dependent via
size](https://help.autodesk.com/cloudhelp/ENU/Fusion-ECAD/files/ECD-CLI-V.htm).
This source supports the drill-setting change; the observed shove and extra
clearance regression come from the live test evidence.
## Scope
This is a bounded two-pad path planner, not a full PCB autorouter. It does not
rip up or shove existing copper, optimize routing order across all nets, route
differential pairs, tune lengths, or model polygons and arbitrary stackups.
It retains the rectangular, two-layer, straight-copper restrictions of the
existing preflight. It may reject legal paths conservatively or exhaust its
grid/node/time budget. Final acceptance always uses native Autodesk DRC.
The planner's grid search can find different paths at different resolutions;
it does not guarantee the globally best manufacturable layout. A failed
mutation can leave partial copper or a native shove, so inspect current state
before deciding how to recover. Planning failures do not create copper.
## Verified live result and videos
`take-04/final.json` records all three pad pairs connected, 10 total segments
(8 added, 2 original barriers), 2 vias and native Autodesk DRC with zero
errors, warnings and airwires. The calculated lengths were 54, 40 and 40 mm.
`take-03` also passed routing; its recorder failed because the Fusion window
was minimized. The runner now checks window and capture dimensions before
creating copper and finalizes both recordings in `finally`.
`fusion-obstacle-live-3x.mp4` is the 19.93-second share cut;
`fusion-obstacle-live-1x.mp4` is the 49.83-second version for reading live
results. Both are 1920×1080, 30 fps and fully decoded successfully. Both were
delivered to `C:/Users/john/Documents/Adom Routing Demos`; the normal-speed
file was opened and visually verified in Windows Media Player.
The existing **AdomActivityPalette** is reused, including its branding and
close handler. Its shared `_shell_html` component has optional routing fields
and an SSE feed. `../live_panel.py` hosts that page and feed in the container;
Windows Fusion reaches it at the verified `http://localhost:8893/` endpoint.
The native message API returned empty acknowledgments on this Fusion instance,
so the demo uses SSE instead of repeated page reloads. Each displayed event
acknowledges DOM application before the next copper edit. A missing acknowledgment
stops the demo. This is presentation evidence, separate from native PCB validation.
AB records the Fusion editor and its owned palette as two native window captures,
then the renderer aligns them using call-start timestamps. Initialization can
introduce a fraction-of-a-second offset; the edit manifest records this limit.
The live text is recorded video, not reconstructed captions. The short take
keeps calculation/check displays, trims part of the completed-state tail and
adds a five-second final hold. `take-04/panel-events.jsonl` is a polling record
started during this take; future runs log every publish and acknowledgment.
To reproduce after preparing an isolated unrouted board and discovering HWNDs:
```sh
python3 demo/routing/live_panel.py
# In another terminal:
python3 demo/routing/prepare_live_panel.py --document YOUR_EXACT_BOARD
python3 demo/routing/obstacles/record_obstacles.py \
--document YOUR_EXACT_BOARD --take YOUR_NEW_TAKE \
--hwnd FUSION_HWND --palette-hwnd ADOM_PALETTE_HWND
```
Verify both windows visually and fit the palette beside the board before recording.
`prepare_live_panel.py` changes the existing palette URL once and preserves its
close behavior. Keep the container server alive while that display is in use.
The optional component changes do not require replacing the loaded add-in or
restarting Fusion. The installed native routing runtime remains
`1.10.0-dev.routing.4`, pinned for development.