Switching to the schematic of an open design is undocumented: add fusion_show_schematic, disambiguate same-named tabs

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

Closed feature request

Colby Knox · 1mo ago ·closed by John Lauer

What happened

An electronics design opens in Fusion as several tabs that all carry the design's name (3D design, board, schematic). fusion_activate_document only takes name (substring) or documentType, and fusion_document_info reports every one of those tabs as documentType: "unknown", so there is no way to ask the bridge for the schematic tab of the design that is open. fusion_export_source run from the PCB editor then writes an .fsch whose only payload is the .brd, and fusion_export_eagle_source for .sch answers "No .sch file found inside .fsch ZIP container".

Board: adonis/nametag-blank-large-led (cloud lineage EgWOX80CTeelI46nsXIQqA), 4 open tabs, all named nametag blank large LED.

What works today

From the board editor, fusion_electron_run {"command":"EDIT .sch"} switches the active editor to the schematic; fusion_get_app_state reports Schematic Editor and both exports then produce the real schematic. EDIT .brd goes back. So the capability exists, it is just not discoverable: the fusion-molecule-export skill still names a fusion_show_schematic verb that is not in the current build.

Asks

A first-class fusion_show_schematic (twin of fusion_show_2d_board) that runs EDIT .sch and confirms the workspace, so the skill text and the verb list agree.
When fusion_activate_document cannot disambiguate (several open documents share the name), say so in the error and point at EDIT .sch / EDIT .brd instead of the generic "No open document matching".
When fusion_export_eagle_source is asked for .sch while the PCB editor is active, refuse with "board editor is active; run EDIT .sch first" rather than the ZIP-container message, which reads as a corrupt file.

1 Reply

John Lauer · 1mo ago

Thanks, Colby. Fixed in fusion-bridge 1.10.35 (insiders), verified on ConfRoomROG against the BQ25792 electronics design, which opens as four tabs all named BQ25792, the same shape as your nametag board.

Ask 1: fusion_show_schematic. It already exists and works: it ran SwitchSchDocCmd and landed on the Schematic Editor there. Your AI could not see it because adom-bridge commands shows a stale hand-written Fusion list inside ab (63 of the bridge's 160 verbs; fusion_show_schematic, fusion_schematic and fusion_state are missing). That is filed on ab as adom/adom-bridge#211. fusion_describe is the complete list. All three show verbs also take documentName and activate that design first.

Ask 3, and the silent .fsch problem you found. The export verbs now pick the editor from the file extension. fusion_export_eagle_source and fusion_export_source switch to the Schematic Editor for .sch/.fsch and the PCB Editor for .brd/.fbrd before exporting, and report it in switchedView. From the board editor:

Export	Result
`.sch`	switched to Schematic Editor, 623 KB, contains `<schematic>`
`.brd` (from the schematic)	switched to PCB Editor, 841 KB, contains `<board>`
`.fsch`	switched to Schematic Editor; the container's payload is now a `.sch`, not the `.brd`

If the switch ever fails, the reply is wrong_editor_active with the exact fix, never the ZIP-container message.

Ask 2: same-named tabs. fusion_activate_document {name} now returns sameNameDocuments (4 here) and says the tabs are one design's views, and names the show verbs that reach a specific view. documentType still reads unknown for these tabs; that value comes from Fusion's API for electronics tabs, so the show verbs are the reliable way in.

Your EDIT .sch / EDIT .brd finding is exactly what the show verbs do under the hood. Closing; public gets it with the next promotion.

John Lauer closed this · 1mo ago