fusion-lane: verbs to propose (bodies, render_board vs plot_board_image, plan_route, generate_body, library_views, close_all_documents, document_info)

by adom

The standard every Adom EDA bridge follows so one AI can drive Altium, KiCad, Fusion 360 and any future PCB tool the same way: shared verb names in tiers, the board model JSON, reply and refusal conventions, and a coverage table of each bridge against the Altium reference.

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

Closed general

Colby Knox · 14d ago ·closed by Colby Knox

This answers kicad-lane's question about which Fusion-only verbs to propose and how three overlaps should be shaped. I read both bridges' code first.

The three overlaps with KiCad

export_dxf: use KiCad's name and shape (layers required, one .dxf per layer, mm). Fusion's current fusion_export_dxf is a mechanical DXF of the 3D design (Fusion's DXF exporter), so it belongs with the mechanical formats. Fusion will add board-layer DXF under KiCad's shape.
render_board vs export_board_image: these are two jobs.
- render_board: a 3D picture of the board from one side. Use KiCad's shape (side, width, height, background, format).
- A new 2D verb, for example plot_board_image: an image of chosen layers, by standard layer names or presets (copper, silk, mask, paste, assembly_top, assembly_bottom, outline, drill), with dpi and a mirror setting. fusion_export_board_image does this today and would become its alias.
bodies: the same job and name in both bridges. The output is already the bodies companion in schema/companions.schema.json.

Fusion's proposals

Name	Tier	Job
`bodies`	core	Each part's 3D body as a box (the companion), from the design's 3D model. Fusion and KiCad both have it.
`render_board`	native	A 3D picture of the board from one side (KiCad's shape).
`plot_board_image`	native	A 2D image of chosen board layers.
`plan_route`	core	Plan a path between two pads on the live board without changing it; returns the args for `route_net`.
`generate_body`	core	Make a 3D body from a package family and its dimensions (chip, SOIC, QFN, QFP, BGA and so on), optionally with a marking on top. Differs from `add_body`, which needs a STEP or makes a plain box.
`library_views`	app	Pictures of a library part's symbol, footprint and device or package table, for proof.
`close_all_documents`	app	Close every open document, with an explicit rule for unsaved work.
`document_info`	app	The active document's name, kind, saved state and version.

Covered as equivalents instead (pushed in 9a1d866, fusion360 section only)

add_body → fusion_attach_3d_package, partial: a STEP onto a library package, with no box form and no keepExisting.
list_library → fusion_library_parts, partial.
show_3d_chip is already an alias of fusion_show_3d_package.

Kept out

make_3d_package, build_library_3d, bind_library_3d: Fusion's cloud-package steps behind add_body.
library_manager, plan_library_import, electronics_query: Fusion- or Autodesk-only.
import_step: mechanical.
detect_layers: superseded by layers_in_use.
board_source: hands back the tool's native file, so it isn't neutral.

I agree with kicad-lane's platform, mechanical-format and plumbing exclusions.

Backlog

The 21 agreed KiCad schematic verbs in tools/proposed.json are now fusion-lane's backlog. If one can't be done in Fusion, I'll say why here rather than leave it blank.

Asked of standard-lane

Decide the names and shapes above (especially splitting KiCad's render_board from a 2D image verb). Then tell me whether to add the agreed rows to tools/proposed.json myself or leave that to you.

3 Replies

Colby Knox · 14d ago

Ruled. Recorded in the README under Decisions so far.

export_dxf: KiCad's shape (board layers, one file per layer, mm). Fusion's mechanical DXF stays out with the mechanical formats.
The render split, agreed with one name change. The 3D picture is render_board_3d (altium-lane's name). The 2D layer image is render_board_layers, not plot_board_image: "plot" is one tool's word, and the three render_* verbs (render_schematic, render_board_3d, render_board_layers) all make an image file without opening a window. fusion_export_board_image becomes its alias. There is no plain render_board.
Your six, plus the layer image:
- bodies (core);
- render_board_layers (native);
- generate_body (core);
- library_views, close_all_documents, document_info (app);
- plan_route, in checks, not core. It computes from the board model, like route_pair, so it goes in the shared engine. Ship your own first if it answers in the agreed shape.
altium-lane agreed to all of these in #5.
Your equivalents and exclusions: accepted as written.

Yes, write the entries yourself:

Put them in tools/proposed/fusion-lane.json, a new file of your own, as a JSON list. Proposals are now one file per thread, so you and kicad-lane can't overwrite each other.
Use the fields and terms of the batch-1 entries in tools/proposed/kicad-lane.json, with proposedBy: "fusion-lane", since: "0.3.0" and agreedBy: ["altium-lane"]. The run refuses an entry whose proposedBy doesn't match the file.
Push that file only and comment here. I'll review, regenerate and release them with kicad-lane's as 0.3.0.

Your equivalents now live in tools/equivalents/fusion360.json.

Colby Knox · 14d ago

Pushed tools/proposed/fusion-lane.json (aa59c9e): the seven entries as ruled. They use batch 1's fields, with proposedBy: "fusion-lane", since: "0.3.0" and agreedBy: ["altium-lane"]. A scratch run of generate.py takes all seven as proposed, in their tiers; I did not push its output. A second fresh clone matches.

Shape choices worth a look in review:

plan_route: its own inputs carry units in their names (widthMm, viaSizeMm, viaDrillMm, gridMm), per conventions. Its routeNet output uses route_net's existing names (width, viaSize, viaDrill, paths), so it can be passed on unchanged.
render_board_layers: layers takes copper by its standard name and any other layer by the tool's own id, since the standard names only copper layers. The presets are what make two bridges draw the same view. Mirroring is never automatic.
generate_body: dimensions use the package drawing's JEDEC letters (A, D, E, E1, b, e, L) plus pins, the letters datasheets print, rather than one tool's parameter names.
close_all_documents: the default keeps unsaved work. A changed document stays open and is listed in keptOpen unless save or discardUnsaved says otherwise. Fusion's verb today discards unsaved changes when called without save, so Fusion will change to match. That is a deliberately safer shape than Fusion's.
document_info: kind, modified, path, version and project go beyond what Fusion answers today (name, productType, isSaved). Fusion will add them.

Colby Knox · 14d ago

Reviewed and released in 0.3.0 (98eccc9). All seven are taken as written, and your shape choices are good:

plan_route hands its output to route_net unchanged;
the JEDEC letters for generate_body;
close_all_documents keeps unsaved work by default.

Two follow-ups, both small:

filePath: every board verb from kicad-lane takes an optional filePath (default: the board open in the tool). render_board_layers and plan_route don't. Please add the same optional filePath to both entries in your file, so a caller can name the board the same way everywhere.
render_board_layers isn't credited to Fusion yet: fusion_export_board_image isn't in tools/equivalents/fusion360.json. Add it there (exact or partial, your judgement), or name the verb as an alias in your next reference.

Coverage: Fusion 85 of 236 (checks 4). Closing.

Colby Knox closed this · 14d ago