Skip to content
This repository has been archived by the owner on Oct 2, 2020. It is now read-only.

Thermal via drills are needlessly small #2153

Open
karlp opened this issue Mar 17, 2020 · 6 comments
Open

Thermal via drills are needlessly small #2153

karlp opened this issue Mar 17, 2020 · 6 comments

Comments

@karlp
Copy link
Contributor

karlp commented Mar 17, 2020

Thermal vias on "many" packages (especially in the qfn family) are 0.2mm drills. This is not based on any manufacturer guideline, but appears to have been introduced, and then copied continually since:
pointhi/kicad-footprint-generator@d0b9262 which came in via pointhi/kicad-footprint-generator#125

These 0.2mm drills cause boards to require higher specs than is commonly available, where 0.3mm is the smallest standard drill.

Given that there's no actual reason for 0.2, I suggest that all the generic parts are rewritten to 0.3mm. If a specific manufacturer part recommends 0.2mm, it can be kept and named appropriatly per KLC https://kicad-pcb.org/libraries/klc/F2.3/

Generic parts in question are (at least) QFN-*_EP*_ThermalVias along with TDFN and TQFN and UQFN and VQFN and WQFN.

This also applies to TQFP, EQFP,

In the DFN family, some seem to have 0.3, some have 0.2, and it's not as clearly scripted as in the others. SON is similar, mixed, and not as clearly scripted and copied without thought.

@JacobEFO
Copy link
Contributor

Seems like there's a total of 204 '_ThermalVias' files with 0.2mm drills. It might be of interest to see, if there are others with drills generally below 0.3mm.

I wonder what might be the best way to change this. One could imagine a scenario, just headlessly changing the drill size could cause violations of clearance.

@evanshultz
Copy link
Collaborator

The generator should place the vias relative to the thermal pad size, if possible, so changing the drill size should only slightly shift the via positions. Probably not a big deal.

IMO this could be done at any time, with a re-generation of the footprints in a PR and notification of any outstanding footprints generated by script. Perhaps when moving to GitLab there is a good opportunity to do this in a clean fashion?

@chschlue
Copy link
Contributor

How about teaching the generator to select drill size according to EP size and removing that parameter from size definitions by default (like it's supposed to be with paste coverage but sadly isn't)?

@evanshultz
Copy link
Collaborator

That could be done. Is there some relationship you are thinking about for drill size and EP size?

If the min drill size is in KLC then it could be in the global KLC config file and I can use that value unless the size definition has another value (which we might want for manufacturer-specific footprints). So then the drill is removed from most of the YAML files and where it stays it will function as an overwrite.

I'm not sure what you mean by paste coverage. Can you elaborate? Paste coverage is defined as a constant on line 25 of the generator and overwritten by the YAML info on line 272, if present. I just did a quick test and commenting out the line in a YAML file generates the same footprint as specifying a 65% paste coverage in the footprint definition. Maybe I'm missing what you're talking about?

@chschlue
Copy link
Contributor

chschlue commented Sep 19, 2020

That could be done. Is there some relationship you are thinking about for drill size and EP size?

I don't have any specific values right now, just that we probably shouldn't have 300µm holes in 350µm wide EPs.
OTOH, tiny EPs with thermal vias probably only make sense with filled vias-in-pad, which in turn requires support for actual vias instead of PTHs in FP files to enable proper CAM job generation.

Perhaps this is a stupid idea. At least requires further consideration.

I'm not sure what you mean by paste coverage. Can you elaborate? Paste coverage is defined as a constant on line 25 of the generator and overwritten by the YAML info on line 272, if present. I just did a quick test and commenting out the line in a YAML file generates the same footprint as specifying a 65% paste coverage in the footprint definition. Maybe I'm missing what you're talking about?

Many definitions include explicit 65% paste coverage because that parameter got copied and, well, pasted again and again although they should probably just use whatever our current default is.
What I'm saying is that neither EP_paste_coverage nor drill_size should be specified unless absolutely necessary.

Tangent: Does the generator currently have a command line parameter to specifiy paste coverage? If not, adding one would enable users to easily adjust coverage according to their particular needs (unusually thick or thin stencils, for example)

@evanshultz
Copy link
Collaborator

I see. Yeah, I don't quite think KiCad supports that situation well. One standard size of thermal via drill in all EPs seems suitable for now, to me.

Gotcha. So just clean up the YAML files by removing that extraneous parameter. Makes sense. Paste coverage and drill size could be cleaned up at the same time. I can do that.

There isn't a parameter for paste coverage. It looks like things which are relatively static but not in KLC were placed as constants in the script. Things that are in KLC are either in a global YAML file for all scripts to share, or a local YAML file just for that script.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants