Fusion lane: polygons with thermals off are converted as thermal-relief zones

Glenn Jones · ·closed by Glenn Jones

adom-aiflow 0.2.26, Fusion lane, fusion-bridge 1.13.44

Polygons drawn in Fusion with thermals off (solid pad connection: CHANGE THERMALS OFF, thermals="no" in the .brd) are converted into KiCad zones with thermal-relief pad connection:

(zone (net 21) (net_name "SW1") (layer F.Cu) ... (connect_pads (clearance 0.3)) (min_thickness 0.3) (fill yes (thermal_gap 0.3) (thermal_bridge_width 0.3))

connect_pads without yes is thermal relief in KiCad, so every gate and check judges different copper from the board in Fusion.

What it broke on our board (TI252772, 4-layer LM251772 module):

  1. gate reported 3 unconnected: a VOUT castellation (J9) 0.33 mm from a same-net pad, and an SW1 test clip (TP3) boxed in by same-net pads. In Fusion both merge into the solid pour (0 airwires, Fusion DRC clean). We had to add four same-net bridging traces to the real board only to get past the gate.
  2. verify-pours --plan cannot match: the board side reads pad connection "thermal", thermal gap 0.3, thermal bridge 0.3 while the pours are solid. Matching would mean writing "thermal" into spec.pours, which misdescribes the copper.

Expected: a Fusion polygon with thermals off converts to (connect_pads yes (clearance <isolate>)); thermals on converts to thermal relief with the board's thermal settings.

Run folder available on request.

4 Replies

Colby Knox linked pull request #48, which closes this when it merges ·
Colby Knox closed this in pull request #48 ·
Colby Knox ·

Fixed in adom-aiflow 0.2.27 (PR #48, published today).

  • A Fusion polygon with thermals off (thermals="no") now converts to a solid-connect zone: (connect_pads yes (clearance <isolate>)). Gate, DRC and verify-pours now judge the same copper as Fusion.
  • Thermals on stays thermal relief. Its gap is now the board's slThermalIsolate (10 mil by default), and its spokes are the pour's thermalwidth, else its width. Both were a fixed 0.3 mm before.
  • For verify-pours --plan, describe these pours as "connection": "solid" in spec.pours. The thermal fields aren't needed for solid pours unless your plan states them.

Checked on a real Fusion board: on the BQ25792 charger .brd, all 38 thermals-off pours now convert to solid. I haven't run it on your TI252772 board. Once you're on 0.2.27, the four bridging traces you added only to pass the gate shouldn't be needed. If gate still reports J9 or TP3 unconnected on 0.2.27, reopen this and attach the run folder.

Upgrade: tell your AI "give me the latest adom-aiflow" (or adom-wiki pkg install adom/adom-aiflow); adom-aiflow --version says 0.2.27.

Glenn Jones ·

Thanks for the quick fix. On 0.2.27 the solid-connect part works: all 7 outer pours on the 772 power module (LM251772) now convert as connect_pads yes. The four bridging traces are gone, and Fusion shows 0 airwires.

The same conversion has a regression, though: 0.2.27 converts this 4-layer Fusion board as a 2-layer KiCad board, and both inner planes are dropped.

Steps: I ran route on the Fusion run to pull a fresh fusion_board_source. That run is at the pours step, with aiflow/run in the attached zip.

Output:

ERROR: declared reference planes do not exist: AGND on In2.Cu, PGND on In1.Cu
ERROR: gate refused: the board has 2 copper layers but aiflow/run/board-31.kicad_dru carries the jlcpcb-4L pack, not jlcpcb-2L

The fresh export is complete. board-live.brd (14:37, attached) contains:

  • layerSetup (1+2*15+16), with layers 1, 2 (Route2), 15 (Route15) and 16 all active
  • 9 polygonpours, all thermals="no": VIN on 1 and 16, PGND on 2, VOUT on 1 and 16, AGND on 15, and SW1, SW2 and SHUNT_L on 1

The conversion is not:

  • board-31.kicad_pcb (0.2.27, from that export) has 2 copper layers and 7 zones. There are no In1.Cu PGND or In2.Cu AGND zones.
  • board-30.kicad_pcb (0.2.26, 2026-10-31 00:45, same design) had In1.Cu PGND and In2.Cu AGND.

So the inner layers seem to be lost in the new Fusion polygon conversion. The run is blocked at the pours step until this is fixed.

The attached zip has the run files you asked for in #113 (screen recordings left out):

  • run.json, run.jsonl and spec.json
  • board-30 and board-31 (.kicad_pcb and .kicad_dru)
  • board-live.brd and board-live.kicad_pcb
  • plan-pours.json and verify-pours.json

verify-pours.json is from a check run at 14:36 against the older board-30 snapshot. That's the #113 side note: the check doesn't pull a fresh board.

772-aiflow-run.zip

Colby Knox linked pull request #52, which closes this when it merges ·
Colby Knox closed this in pull request #52 ·
Colby Knox ·

Fixed in adom-aiflow 0.2.30 (PR #52). Thanks for the run folder; it made this quick to pin down.

Cause: the Fusion converter only ever mapped the top and bottom copper layers. This wasn't the 0.2.27 thermals change: the published 0.2.26 build also converts your board-live.brd as 2-layer, and your run log shows the same "PGND on In1.Cu does not exist" back on 10-28. Your board-30 must have come from another build.

Now: inner layers convert in your board's stack order (layerSetup (1+2*15+16): Route2 is In1.Cu, Route15 is In2.Cu). Your board-live.brd converts to 4 copper layers, with PGND on In1.Cu, AGND on In2.Cu and all 9 pours, so the reference-plane check and the 4-layer rules pack should both pass.

Not yet: AI Flow reads inner-layer copper but doesn't land or measure it. land pours and measure stay on top and bottom, so keep drawing the inner planes in Fusion yourself.

Upgrade: tell your AI "give me the latest adom-aiflow" (or adom-wiki pkg install adom/adom-aiflow); adom-aiflow --version says 0.2.30. Then run route again to pull a fresh board. If anything is still off, reopen this.

Glenn Jones ·

Confirmed fixed on 0.2.30, thanks Colby. The quick turnarounds on this and #113 got us moving again today.

On the 772 power module (LM251772):

  • route pulled a fresh board, and it converts as 4 copper layers with all 9 pours, PGND on In1.Cu and AGND on In2.Cu.
  • gate passed: 0 new DRC errors and 0 unconnected, without the four bridging traces (now removed).
  • verify-pours passed against the plan, and the run is past the pours step.

Closing this one. Two small things I noticed on the way, in case they're useful (neither blocks us):

  • pour writes thermalBridge / thermalGap of 0.5 into solid pours when spec.pours leaves them out. So verify-pours flagged Fusion's real 0.1524 / 0.254 until I wrote them into the spec, even though they mean nothing for solid-connect pours.
  • verify-pours --adopt refuses on a Fusion run with "the saved zone has no uuid to own", because the converted Fusion zones have no uuid/tstamp. A plain verify-pours passes and records the pours as verified-existing, so we didn't need adoption.
Glenn Jones closed this ·

Log in to reply.