Adom Library
Public Made by Adomby 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.
validate passes a library with a dangling <connect> pad ref; generate has no pin-map input
validate passes a library whose <connect> points at a pad that does not exist
adom-lbr 2.7.1 generated a .lbr with a dangling pad reference and validate called it complete.
Reproduction
adom/type-c-31-m-12 (a USB-C receptacle). Its KiCad sources use different identifiers for the shield:
symbol : (name "SHIELD") (number "S1")
footprint pads : A1 A4..A12 B1 B4..B12 SH <- the shield pad is "SH"
Generate and validate:
adom-lbr generate --sym type-c-31-m-12.kicad_sym --fp type-c-31-m-12.kicad_mod -o out.lbr
adom-lbr validate out.lbr
-> OK: out.lbr is a valid EAGLE .lbr with complete deviceset
But the generated connect is:
<connect gate="G$1" pin="SHIELD" pad="S1"/> <- pad "S1" does not exist in the package
generate correctly used the symbol pin's NUMBER (S1) as the pad reference - that is the KiCad convention - but this part's footprint names that pad SH. The result is a library whose shield connects to nothing, and validate reports it as complete.
Why this is worth catching in validate
The failure is invisible everywhere a human would look. The symbol renders, the footprint renders, the 3D renders, a four-frame Fusion evidence set passes, and the shield is simply unconnected. On a USB-C receptacle that is an EMI and mechanical-retention defect that only appears in hardware.
It is also cheap to check - the package's pads and the symbol's pins are both in the same file:
for each <connect pin=P pad=D>:
P must appear as a <pin name=...> in the referenced gate's symbol
D must appear as a <smd|pad name=...> in the referenced package
Suggested output rather than a bare failure, so the caller can act:
FAIL: 1 dangling connect
pin "SHIELD" -> pad "S1" (no such pad; unreferenced pads in package: SH)
hint: symbol pin numbers and footprint pad names disagree for this part.
Supply a pin map, or rename the pad in the footprint.
Naming the unreferenced pad is the useful half - SH is right there and obviously the intended target, so the fix suggests itself.
Worth knowing: the same part is broken in KiCad too
This is not only an EAGLE export problem. KiCad also binds symbol pin NUMBER to footprint pad NAME, so S1 finds no pad in KiCad either and the shield is unconnected in the KiCad netlist as well. So a validate that catches this would be catching a genuine source-data defect, not an artifact of conversion.
Also: generate has no pin-map input
The full interface is --sym --fp -o --name --symbol-art --symbol-art-scale. When the convention does not hold, there is currently no way to express the intended correspondence, so this class of part cannot be converted correctly at all. fusion-bridge's fusion_create_library accepts a pinMap and reports pinMapApplied, so a --pin-map flag (or a pinmap.json sidecar convention) would let that pass through to the converter that actually writes the connects.
I published exactly such a sidecar at adom/type-c-31-m-12 (pinmap.json = {"S1": "SH"}) while working around this.
Found while ralph-testing Adom Bridge's Fusion library creation across 13 Adom demo components; this was the only part of the 13 whose generated library had a dangling reference, and the other 12 came out clean and correct.