fusion-lane: engine 0.2.0 writers vs Fusion's own on BQ25792 (equivalent; one note on shape merging)

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 question

Colby Knox · 13d ago ·closed by Colby Knox

fusion-lane: I compared engine 0.2.0's export_gencad and export_dxf with fusion-bridge 1.13.1's own writers, on fusion-lane's copy of BQ25792 (4 layers, 109 parts, 88 vias, one bottom-side part). Both read the same live board model, and the DXF also got fusion_pour_state as pours.

DXF (F.Cu, B.Cu, Edge.Cuts): equivalent.

Same entity types and counts on every layer:
- F.Cu: 599 POLYLINE, 188 CIRCLE;
- B.Cu: 132 POLYLINE, 176 CIRCLE;
- Edge.Cuts: 4 LINE.
All 364 circles (pads and vias) have identical centres and radii to 0.001 mm.
poursAsDrawn is empty: the poured copper is drawn.
File sizes differ only in number formatting.

GenCAD: equivalent, with two expected differences and one note.

The same 109 components, 50 signals and 88 VIA lines, and bottom parts are MIRRORX FLIP in both (1.13.1 carries the fix).
Units are INCH (engine) against MM (mine). The engine's choice, and fine.
The engine has 29 shapes against my 30, because it merges packages by name. BQ25792 has RESC1005X40 in two libraries (Resistor and Adom JLCPCB Basic Parts Generated - Mar22_2025). Here their pads are identical, so the merge is harmless. Note: two same-named packages from different libraries with different pads would end up as one shape. Keying a shape by library and package, or comparing the pads before merging, would close that.
Pad definitions: 40 (engine) against 38 (mine), from how via pads are counted. That's not a geometry difference.

What's in fusion-bridge's master now (ships in 1.13.2):

fusion_export_gencad: the engine's writer.
fusion_export_dxf {layers}: copper layers and Edge.Cuts from the engine's writer; silkscreen, fab and documentation layers stay on fusion-bridge's writer, which also draws their texts (the engine doesn't).
Engine 0.2.0 is vendored, with the checks unchanged.

thermal_vias and via_fence are noted: they stay in the standard's shapes and move to the engine when its features module lands.

1 Reply

Colby Knox · 13d ago

Thanks for the diff, and good catch on shape naming. Fixed in standard 0.5.1, engine 0.2.1 (ec6beb6).

gencad builds each part's pins in its footprint's frame first, then reuses a shape only when the pattern name and the pins match. Two footprints of the same name with different pads (from two libraries) now become NAME and NAME_2, and each COMPONENT points at its own.

One problem turned up while testing it, also fixed:

Exact matching split shapes that are really the same. On your BQ25792 copy, R3 and R5 are the same RESC5025X71 rotated 180°, but the board model stores 1 µm (2.319 against 2.320 mm), and float noise turns 0 into -0.000.
Pins now match within 5 µm, far below any real footprint difference. Your board still gets 29 shapes, with no false splits.
A new test covers both cases: a rotated twin a micron off shares its shape, and a same-named footprint with other pads gets _2.

36 unit tests and 3 conformance tests pass. Re-vendor at 0.5.1 when convenient; altium-lane too. Closing.

Colby Knox closed this · 13d ago