Closed bug report

Route landing needs a rectangular outline (blocks custom outlines); false readback_mismatch on vias; CHANGE blocked in electron_run

Muzzer · 24d ago ·closed by John Lauer

Found during a full adom-aiflow Fusion run of the buck molecule (fusion-bridge 1.11.39, AB 2.1.168, 2026-10-18).

  1. Route landing needs a rectangular outline. land route fails with unsupported_board: Initial preflight requires a rectangular four-line outline once the board corners are rounded (MITER arcs). A refine pass that goes back to routing after outline round cannot land, and a real product with a custom outline (curves, notches) cannot be routed through the bridge at all. The user's next board needs exactly that. Request: accept any closed outline (lines and arcs) in the preflight, or say which check needs the rectangle.
  2. Via landing reports readback_mismatch for vias that landed. The readback lists the via at the planned spot (e.g. planned 7.280047896, read 7.280046875). A re-run skips them as present. Looks like an exact float compare.
  3. fusion_electron_run blocks CHANGE ("opens interactive change mode"), including fully specified forms like CHANGE WIDTH 0; / CHANGE LAYER 48 (x y);. They work inside a SCRIPT file, so allowing the complete forms would save a send_files round trip.
  4. fusion_check_dialogs resolution text for the Electronics d3d12 assertion (SkiaWindowContextDx12.cpp line 1022) says it is a router assertion seen on LINE; it is the canvas losing its D3D12 device. On this box it happens only with DisplayLink indirect displays attached (IndirectDisplayAdapterDetected=1 in NMachineSpecificOptions.xml); see fusion-bridge#121.

3 Replies

John Lauer · 24d ago

Thanks, Muzzer. All four are fixed in fusion-bridge 1.11.43, on the insiders channel now and public after sign-off.

  1. Any closed outline routes. The preflight no longer needs a four-line rectangle. It chains the layer-20 lines, arcs (MITER corners included) and circles into closed loops: the largest is the board edge and the rest are cutouts. Copper must lie inside the edge, outside every cutout, and the board's edge clearance away from every outline segment. Arcs are checked as fine polylines, with the small chord error added to the margin. plan_route uses the same check. An outline that does not close is refused with the point where it breaks. Tested on your buck board with the corners rounded: the routes it planned before still plan, and copper in a cut-off corner is now refused (the old box check allowed it).
  2. Vias that landed no longer read as readback_mismatch. Fusion stores coordinates in 1/320000 mm steps, which is exactly your 7.280047896 to 7.280046875. Plans now snap to that grid and go out with 9 decimals, and the readback snaps both sides. Verified live: a GND via planned at x 7.280047896 landed and came back verified: true. fusion_place_vias now also compares the normalised net name.
  3. fusion_electron_run accepts complete CHANGE forms: a property, its value and a closing ;, with optional points, so CHANGE WIDTH 0; and CHANGE LAYER 48 (x y); run. A bare or open-ended CHANGE is still refused, and the refusal now shows the accepted form. Checked live on the board.
  4. The d3d12 assertion (SkiaWindowContextDx12.cpp, "Unrecoverable d3d12 error") now has its own rule: the Electronics canvas lost its GPU device, not a router assertion. The resolution says to save, restart Fusion and update the graphics driver, and mentions the DisplayLink pattern from #121.

The Fusion lane side of your run (finish's silkscreen count, the silkscreen layer restore, your wired-schematic patch, thermal vias) is in adom-aiflow PR #38 for its maintainer to review.

John Lauer · 24d ago

Update: 1.11.43 is now on the public channel, so a normal update picks it up.

John Lauer · 24d ago

Closing: all four items shipped in 1.11.43, which is public. If a custom outline or via readback still misbehaves on your next run, reopen this with the board and the reply JSON.

John Lauer closed this · 24d ago

Log in to reply.