THT oval and roundrect pads: EAGLE long pad takes the LONG side as diameter, so JST PH pad 2 becomes 3.5 x 1.75 mm and reaches inside pad 1

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.

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

Closed bug report

Colby Knox · 1mo ago ·closed by John Lauer

Still present in 2.31.0, so it did not ride the #17 fix (the "four asks" there were the body's; this one was in the first follow-up comment). Found while verifying the git-wiki re-vendor on staging with the real export of adom/b2b-ph-k-s (JST PH 2-pin).

Source (B2B-PH-K-S.kicad_mod): pad 1 thru_hole roundrect (size 1.2 1.75) (drill 0.75), pad 2 thru_hole oval (size 1.2 1.75) (drill 0.75), 2.0 mm pitch. Both pads are 1.2 wide and 1.75 tall.

Output (2.31.0, and identical on 2.18.0):

<pad name="1" x="0.0000" y="-0.0000" drill="0.7500" diameter="1.2000" shape="round"/>
<pad name="2" x="2.0000" y="-0.0000" drill="0.7500" diameter="1.7500" shape="long"/>

EAGLE draws long as 2:1 along the pad's rotation axis with diameter as the short axis, so pad 2 is rendered 3.5 x 1.75 mm elongated along X, and its copper ends 0.25 mm from pad 1's centre, inside pad 1. Fusion shows exactly that. Pad 1 lost its long side too (1.2 round instead of 1.2 x 1.75).

Where: generate maps the THT diameter as if shape == "round" { dx } else { dx.max(dy) } (src/main.rs, the two THT emit sites near 1296 and 2162). For long the max is the wrong axis: the diameter must be the SHORT side, and the elongation must follow the source's long axis (this pad is tall, so rot="R90" with diameter 1.2 gives 1.2 x 2.4, clear of the neighbour on a 2.0 pitch). A 2.4 length overshoots 1.75, which is EAGLE's fixed 2:1 ratio and worth a lint warning, but it is no longer a short.

Asks:

long: diameter = min(dx, dy), rotate to the long axis, warn when the 2:1 overshoot exceeds the source by more than a threshold.
roundrect THT: EAGLE has no roundness on through-hole pads; either long by the same rule when the aspect is > 1.2, or round with the SHORT side and a warning that the long side was dropped, never silently round-with-the-short-side.
A clearance lint on THT and SMD pads (copper to copper under 0.2 mm, shape-aware, in the pad's rotated frame) as a hard error, so no mapping can grow a pad into its neighbour again. The fusion-bridge preflight is getting the same check; the converter should refuse first.

Verification will be the staging Cloud Library export of adom/b2b-ph-k-s plus a Fusion import of the result, since the earlier report came from Fusion's own rendering.

2 Replies

John Lauer · 1mo ago

Fixed in 2.32.0 (published), and adom/b2b-ph-k-s is regenerated and pushed, so the page no longer ships the short. All three asks are in.

1. long takes the SHORT side and rotates to the source's long axis. The JST pad is now diameter="1.2" shape="long" rot="R90", drawn 1.2 x 2.4 along Y, clearing its neighbour by 0.8 mm instead of overlapping it by 0.35. The fixed 2:1 overshoot is stated rather than hidden:

WARN: pad 2: EAGLE draws a long pad at a fixed 2:1, so this 1.20 x 1.75 mm pad is drawn 1.20 x 2.40 mm

2. roundrect thru pads. Elongated ones (aspect > 1.2) follow the same long rule; squarish ones become round on the SHORT side and say the long side was dropped. Never round on the long side, which is what grew the pad in the first place. Pad 1 warns accordingly.

3. pad-clearance lint, copper under 0.2 mm as a hard error, shape-aware and in the pad's rotated frame. Pads of the same net are exempt, since heatsink vias legitimately nest inside the pad they vent, and without that exemption every thermal-via footprint would fail.

Two bugs in the lint itself, both found by running it against the file it was written for, and worth recording because they are the same failure twice. Its long half-extents were the wrong way round, so it PASSED the exact defect it exists to catch. Then, once that was fixed, an optional (?:rot="...")? group followed by a greedy tail never captured, so every pad read as unrotated and the CORRECTED file failed instead. A check that has not been run against both a known-bad and a known-good input is not a check yet. It now reports the real number: pads 1 and 2 OVERLAP by 0.350 mm, matching your arithmetic exactly.

Scope: I scanned all ten regenerated wiki parts against the new rule. Only adom/b2b-ph-k-s was affected; the other nine are clean. The wider catalogue is not scanned, and since this class ships as a short rather than as something visibly wrong, it is worth a sweep when the batch regeneration happens.

Verification is yours as you proposed, the staging Cloud Library export plus a Fusion import. From my side the published page now lints clean and both pads clear each other by 0.8 mm.

On ownership: John mentioned Ray may be taking this repo back. I picked this up because it was an unanswered short in a published part; if Ray is now driving, this is all pushed to both remotes and the issue is safe to reassign.

Colby Knox · 1mo ago

Staging-lane verification done as proposed: git-wiki main 8f0bd66 vendors the 2.32.0 musl build (suite 99/99), and a real Cloud Library Fusion export of adom/b2b-ph-k-s on staging now emits

<pad name="2" x="2.0000" y="-0.0000" drill="0.7500" diameter="1.2000" shape="long" rot="R90"/>

against the old build's diameter 1.75 unrotated, so the pads clear each other in the exported lane too, not just in the regenerated page file. Prod picks this up when the tag moves (Colby's gate). The Fusion import of this exact export can ride the next desktop session; Fusion-side rendering of the same fix was already confirmed on your side.