app

Adom Library

Public Made by Adom

by adom

adom-lbr — the EDA library translator. Bring a component in from any supported EDA tool and convert it to any other (KiCad ⇄ Altium ⇄ EAGLE/Fusion) through one canonical adom-lbr JSON — symbol + footprint + 3D + pin↔pad map. Altium is written natively (no Altium needed). Includes the adom-lbr Manager: browse wiki components and view symbol/footprint/3D + the per-EDA layer stackup.

edaaltiumschlibpcblibintlibkicadeaglelbrfusion360converter
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests1 Activity
Closed general

generate: duplicate pad names (same-net arrays) pass through verbatim and Fusion refuses the whole library - emit the EAGLE @-suffix convention

John Lauer · 1mo ago ·closed by John Lauer

generate copies KiCad's duplicate pad names verbatim, and Fusion refuses the entire library

KiCad allows several pads to share one name when they are the same net - thermal via arrays, shield pads, exposed paddles. This is normal, correct KiCad data. EAGLE/Fusion does not allow it: the importer refuses the WHOLE library.

adom-lbr generate copies the pad names through unchanged, so every part with a same-net pad array produces a .lbr that Fusion rejects outright. Measured across the 13 Adom demo parts - three affected:

ads1220irvar     22 pads   pad '17' x6    (thermal vias)
rp2350b          91 pads   pad '81' x11   (ground array)
type-c-31-m-12   20 pads   pad 'SH' x4    (shield, 4 physical pads)

The fusion-bridge's preflight names the failure precisely:

lbr_preflight_failed: pads-unique: duplicate pad names - Fusion's importer
refuses the ENTIRE library over these: RP2350B/81 x11.
Rename to e.g. 17, 17@2, 17@3...

The fix is the EAGLE @-suffix convention

EAGLE's own convention for one logical pin on several physical pads is NAME, NAME@2, NAME@3... - and connects reference them all to the same pin. generate should emit exactly that when a .kicad_mod has repeated pad names:

  • package: 17, 17@2 ... 17@6
  • connects: <connect gate="G$1" pin="17" pad="17 17@2 17@3 17@4 17@5 17@6"/> (or one connect per pad, whichever EAGLE-dialect Fusion accepts - the space-separated multi-pad form is standard EAGLE)

That preserves the electrical meaning (all six pads are pin 17) instead of losing it.

Why this matters beyond three parts

Any QFN with a thermal pad, any connector with a multi-pad shield - i.e. a large fraction of real parts - hits this. It is also invisible until Fusion refuses the import: validate passes these files today, so nothing upstream catches it.

Related: adom-lbr#9 (validate does not check connect/pad referential integrity). Same theme - validate should also flag duplicate pad names as long as generate does not resolve them.

Repro: adom-lbr generate --sym rp2350b.kicad_sym --fp rp2350b.kicad_mod -o out.lbr from adom/rp2350b's page files, then count <smd name="81" in the output: 11.

1 Reply

John Lauer · 1mo ago

Fixed in 2.10.0 (published to this page; current is 2.10.1). generate now resolves same-net pad arrays to exactly the convention you asked for, and the linter enforces it.

What generate emits now, measured on all three affected demo parts from this page's org:

rp2350b        91 pads, 0 duplicates   81, 81@2 ... 81@11
               <connect gate="G$1" pin="81" pad="81 81@2 81@3 81@4 81@5 81@6 81@7 81@8 81@9 81@10 81@11"/>
ads1220irvar   22 pads, 0 duplicates   17, 17@2 ... 17@6
type-c-31-m-12 20 pads, 0 duplicates   SH, SH@2 ... SH@4, and the pinmap.json sidecar composes:
               <connect gate="G$1" pin="SHIELD" pad="SH SH@2 SH@3 SH@4"/>

The multi-pad connect is the space-separated standard EAGLE form, so the electrical meaning (all pads are one logical pin) is preserved instead of lost. All three validate clean and lint PASSED with 0 errors.

The validate half you flagged is in too: a new fatal duplicate-pad-name check. A pre-fix .lbr now fails loudly:

FAIL: rp2350b-old.lbr has 1 error(s)
  [duplicate-pad-name] Pad name '81' appears 11 times in package 'RP2350B' - Fusion's
  importer refuses the entire library over duplicate pad names. Use the EAGLE @-suffix
  convention (81, 81@2, ...) with a multi-pad <connect> (adom-lbr generate now emits this).

One message per repeated name, not one per extra pad, so an 11-via array reads as one problem. The connect-pad-unresolved check from #9 also learned to resolve each name inside a space-separated pad group individually, so a group with one missing member still fails.

Regression tests cover the @-suffix dedup, the multi-pad connect passing, a missing group member failing, and the duplicate-pad-name error (10 tests total, all green). Source is on the page repo and GitHub main.

Log in to reply.