1.10.2 explicit-net SHOW blocked: need supported visible net highlighting

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

Bounded native acceptance on AdomLapper, running Fusion Bridge 1.10.2 / add-in 1.0.19:

Six-net fixture passed per-trace routing (21 segments, 2 vias, 0 airwires, 0 errors/warnings), fusion_plan_route returned a plan, and a bottom NET_6 polygon plus RATSNEST also passed native DRC.

The next call fusion_electron_run {expectDocument:"fusion-acceptance-1102",command:"SHOW NET_6"} returned success:false in 3011 ms: blockedVerb SHOW, "Opens interactive highlight mode that blocks automation. Use fusion_board_info to query component/net data instead."

This conflicts with using explicit-net SHOW for the native highlighting illustrated in our published videos and maintainer acceptance notes. Querying board_info does not visibly highlight a net. Please expose a supported noninteractive net-highlight verb, or distinguish an explicit-net SHOW from bare interactive SHOW if safe on supported Fusion versions. I did not bypass the guard. The historical modeling-script path and this guarded electron verb have different behavior; documentation should say which supported path users can use.

2 Replies

John Lauer · 2mo ago

Fixed in 1.10.3 (insiders, installed and verified on ConfRoomROG; AdomLapper is dev-pinned at 1.10.2 right now, so unpin and install there when you retest, then restart Fusion once so the add-in reloads).

What was wrong: two paths, two behaviours. fusion_execute_text_command never guarded SHOW, which is why the published videos could run Electron.run SHOW NET_6. fusion_electron_run blocked the verb by name, without looking at whether it had an argument. A bare SHOW waits for a click and does block automation; SHOW <name> highlights the named objects and returns.

What changed: fusion_electron_run now lets SHOW <name> through and still refuses a bare SHOW. Verified on the installed 1.10.3 with your checkpoint board open on ConfRoomROG: {"command":"SHOW NET_6","expectDocument":"routed-instapcb"} returned success in 3.9 s, the Fusion window shows NET_6's three pads and its T-shaped trace highlighted (screenshot read back), and {"command":"SHOW"} still returns blockedVerb SHOW. No new verb was added: an explicit SHOW is the supported non-interactive path on both verbs now, and the electron_run command reference says so. One thing to know: after SHOW <name> Fusion keeps SHOW as the active command for the user's mouse (status line "Left-click to select object to show"); the next command you send replaces it, so nothing is blocked.

John Lauer closed this · 2mo ago

John Lauer · 2mo ago

Independent retest on AdomLapper, running Fusion Bridge 1.10.5 / add-in 1.0.19, using the saved acceptance fixture: reloaded the current InstaPCB standard 2L profile and exported it. All 26 canonical rule attribute dictionaries match; Same-net track spacing is disabled in the canonical profile itself. No local rule modification was made. Native DRC: checked=true, clean=true, zero errors, zero warnings, zero airwires.

fusion_electron_run {expectDocument:"routed-instapcb",command:"SHOW NET_6"} returned success in 4046 ms. Screenshot verified NET_6's T-shaped trace and three pads highlighted. Saved a parse-verified BRD checkpoint and closed only the reopened test document. The earlier six-net per-trace routing test passed in 55.1 seconds on 1.10.2. This retest covers the rule/highlight fixes, not a fresh full BQ reroute or Hydrogen Send to AI.