app

Fusion - the Fusion 360 Bridge

Public Made by Adom

by 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.

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

Save an electronics design in place (no Save As fork), save the 3D PCB beside it, re-import as a new version

John Lauer · 24d ago ·closed by Colby Knox

From adom-aiflow 0.2.3 (issue adom/adom-aiflow#74, items 6 and 7, reported by Muzzer on fusion-bridge 1.11.39; source read at 1.11.43).

What happens today

fusion_save_to_cloud {name, projectName, folderPath} is app.activeDocument.saveAs(name, folder, ...) (addin/AdomBridge/commands/cloud_documents.py, handle_save_to_cloud). It is the only save verb.

  • The first save of a new electronics design saves the whole design: .fprj, .fsch and .fbrd, linked.
  • Every later save made while the 2D board is the active document writes the board as a NEW standalone .fbrd of the same name. The design (.fprj) keeps linking the original, unrouted board. In Muzzer's run the routing, pours and silkscreen all ended up in the unlinked .fbrd; opening the design showed a board with 0 tracks. He had to export both halves, re-import them as a new design and delete six stale files.
  • The design's 3D PCB document (<Design>.f3d) was saved into the active project's root, not the design's folder.
  • Each re-import of a design (fusion_new_electronics_from_eagle, used by aiflow's 3D restore and by any re-run) leaves another set of files with the same name. Muzzer's run folder ended with one .fprj, one .fsch and four .fbrd all called "Buck12V5V", which the data panel cannot tell apart.

What adom-aiflow does now (0.2.3)

  • It saves only a new design's first save, and refuses when the active document (or any open document of that name) already has a dataFile, or when the target folder already holds a file of that name.
  • It reads the folder back after the save and warns when a file kind appears twice under the name.
  • It has no in-place save, so a checkpoint save of a design already in the cloud is left to the human.

Asked of the bridge

  1. fusion_save_document {expectDocument?, comment}: save the open electronics DESIGN in place (Document.save(comment)), never Save As. Resolve the design document itself (the one whose product is the electronics design, not the board or schematic view that is in front), activate it if needed, save, then verify and return:
    • fileId, versionNumber before and after (the version must go up by one),
    • the board the design links (its .fbrd lineage) and that it is the board that was just edited (for example the board document's dataFile.id matches the design's linked board),
    • success:false, errorCode:"not_saved_yet" when the design has no dataFile (use fusion_save_to_cloud for a first save).
  2. fusion_save_to_cloud refuses a Save As of an already-saved electronics document unless the caller passes asCopy:true, with an errorCode (for example already_saved_use_save_document) and a hint naming fusion_save_document. This is the data-loss guard: a Save As by name on a saved design with the board in front should never happen silently.
  3. Save the design's 3D PCB document beside the design (same project and folder), not in the active project's root.
  4. Re-import into an existing design as a new version: for example fusion_new_electronics_from_eagle {schPath, brdPath, intoDesign: <fileId or name+projectName+folderPath>} that opens the existing design, replaces its schematic and board from the files, and saves a new version of the same lineage (no new .fprj/.fsch/.fbrd). Until then, any import that is closed without saving should leave no files behind; please confirm that fusion_close_document {save:false} on a never-saved imported design (no dataFile) writes nothing to the hub.

Acceptance

On a design saved once into <project>/<folder>: route a net with the 2D board in front, call the new save, then close everything and open the .fprj from the data panel. The board shows the routed net, the folder holds exactly one .fprj, one .fsch and one .fbrd of that name (plus the .f3d beside them), and the .fbrd's version went up by one. A fusion_save_to_cloud on that same open design is refused.

2 Replies

Colby Knox · 16d ago

Items 1 to 3 are fixed in fusion-bridge 1.12.0 (source commit 6fdab0e on master; ships with the next release). Item 4 is still open.

1. fusion_save_document {documentName?, comment?} saves the open electronics design in place. It finds the design behind whichever tab is in front, saves the design document, and reads back each changed document's version before and after, plus the board the design links (linkedBoard). When Fusion reports nothing unsaved it answers saved:false; a never-saved design gets not_saved_yet.

2. fusion_save_to_cloud on an electronics design:

  • saves the DESIGN document, so .fprj, .fsch and .fbrd are saved linked, whichever tab is in front. That is the fix for the fork: Save As on the board document is what wrote the unlinked .fbrd;
  • refuses a design that is already saved with already_saved_use_save_document unless asCopy:true;
  • refuses a name the folder already holds unless overwrite:true;
  • creates missing folders on folderPath;
  • requires projectName when no project is open in Fusion's data panel (Fusion cannot read its active project then).

3. The 3D PCB is saved beside the design: saving through the design document puts the open 3D PCB's .f3d in the design's folder.

Root cause behind "the design shows a board with 0 tracks", found while testing: doc.activate() moves Fusion's API to a document but not always its UI, and the board export and every Electron command act on the UI's board. A routing read or edit named one board and touched another. The edit then sat in a board the saved design never linked, and the design that was saved had nothing to save. Every routing verb and the view verbs now put the UI on the named document's tab first (UI.SwitchToTab).

Acceptance, live on DESKTOP-BAR6S0F (scratch designs under Default Project / fusion-lane-tests):

  1. A never-saved design, board in front: fusion_save_to_cloud {name, projectName, folderPath} wrote .fprj, .fsch and .fbrd v1, linked, and created the folder.
  2. Routed NET_1, then fusion_save_document: board v1 to v2 in the same lineage.
  3. A second fusion_save_to_cloud on it was refused with already_saved_use_save_document.
  4. Closed and reopened from the cloud: the board shows the routed net, and the folder holds exactly one .fprj (v2), one .fsch (v1) and one .fbrd (v2).

Closing a never-saved import with save:false writes nothing: none of today's scratch imports that were closed unsaved left a file in the hub.

Still open: item 4, re-import from EAGLE files into an existing design as a new version (intoDesign). Fusion's sch+brd import always creates a new design; doing this needs the existing design's schematic and board replaced in place. That is next.

Colby Knox · 15d ago

From the fusion-lane thread. Item 4 is done in fusion-bridge 1.12.3 (signed, public today), so all four items are now fixed.

4. Update a saved design from files, as a new version. The new verb fusion_update_board_from_eagle {brdPath, expectDocument, save?} makes the open design's board the board in an EAGLE .brd (or .fbrd) in place:

  • parts are moved and turned by name;
  • tracks and vias are ripped up and drawn from the file;
  • pours, the outline, holes and net-less copper are replaced;
  • the whole board (parts, copper, pours, outline, holes, nets) is read back against the file.

With save:true it saves in place, and only after an exact read back. If the read back doesn't match, nothing is saved and the reply says to close without saving.

A file that adds or removes parts, or changes a net's pads, is a schematic change. It is refused with schematic_differs, so for those, import the files as a new design. Silkscreen and documentation, design rules, and name and value positions aren't synced; the reply's notSynced names them whenever the file differs in them.

Acceptance, on a design saved into Default Project / fusion-lane-tests:

  1. A first file: J2 moved, NET_1 routed on both layers through two vias, a pour and a hole.
  2. A second file applied with save:true: the read back was exact, and the board went from version 1 to version 2 of the same lineage. The design links that board.
  3. The folder still holds exactly one .fprj, one .fsch and one .fbrd of that name.
  4. Closed and reopened from the cloud, the board shows the second file's parts and copper.

Found on the way, and fixed: fusion_open_cloud_file by name could open the .fbrd or .fsch of a saved design. Fusion then raises its "links to multiple Electronics designs" chooser, which can't be answered headlessly. Opening by name now opens the design (.fprj) when there is one of that name.

Your question about unsaved imports: confirmed. Closing a never-saved, modified imported design without saving wrote nothing to the hub: no Untitled file appeared in the project, and its file count stayed the same.

Closing.

Colby Knox closed this · 15d ago

Log in to reply.