fix: keep quad corner silkscreen clear of the pads (#734) - #735
Open
DPS0340 wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #734.
On narrow-body quad variants the corner marks were drawn through the pads.
tqfp32_w7's top-left arm ran fromx=-3.5tox=-2.4aty=3.5, while pad 32 occupiesx[-3.075,-2.525] y[3.400,4.875]— straight over copper, at −0.05 mm clearance.The fix
The corner sits at
(±w/2, ±h/2), the pad-row centre line, so an arm running inward always crosses the band the outer pads occupy. It only stayed clear when the fixedcsz = pw * 2arm happened to be short enough — which is why the defaulttqfp32looked fine and the 7 mm-body variant did not.Rather than shifting the corner (which would move it off the body outline), this clamps each arm to stop before the first pad it would reach:
maxArmLengthwalks the actual pad boxes (collected during pad generation, thermal pad included), keeps only those spanning the arm's perpendicular coordinate, and returns the distance to the nearest one. Arms that already clear everything keep their fullcszlength, so footprints that were correct are untouched — only 3 snapshots changed, and 2 of those are the reported defects.Verification
Measured, not eyeballed. Segment-to-pad distance minus half the stroke:
0.2 mm is not an arbitrary target: I measured KiCad's own references first and they land on exactly that number —
TQFP-32_7x7mm_P0.8mm,TQFP-48,TSSOP-10,SOT-457Tall report 0.2000 mm silk-to-pad.The new test bites. Reverting only
src/fn/quad.ts:It covers 9 variants (narrow and default bodies, QFN, LQFP, QFP) and asserts
cornerPaths.length > 0so it can't pass vacuously. It deliberately excludes the pin 1 arrow (_3paths), which is placed against the pad it identifies by design — I confirmed that arrow's 0.1 mm gap is unchanged frommainand not something this PR introduces.Suite:
468 pass / 0 fail,biome formatclean,bun run build(ESM + DTS) ok. I rendered the tqfp32 parity snapshot and compared it with the KiCad reference side by side — the corner marks now sit in the gaps between pads exactly as KiCad's do, andcourtyardDiffPercentstays0.00%.How this was found
Extended the #732/#733 silkscreen scan across all 90 parity footprints, comparing each against its KiCad reference. It surfaced 4 footprints with no silkscreen where KiCad has some, and 3 with actual overlap. This PR fixes the quad ones; #734 lists the rest (
sod123,sot723,tssop10_w3mm_p0.5mm,sot457_w2_pl1.5_pw0.6), which come from different code paths and are better as separate PRs. Happy to send those next if this approach looks right.