kicad-website
kicad-website copied to clipboard
KiCad
Update F4.3 to indicate pads should not be rotated
@poeschlr thoughts? @chschlue mentioned this as a requirement for footprints but it isn't in the KLC today
I started asking contributors to un-rotate pads if I had other comments about footprints. Only because it made the file size smaller to no effect on the footprint and, frankly, it's harder to grok when looking at the footprint file. But if there were no other comments I've merged footprints with rotated pads.
If @poeschlr accepts the concept I have some comments on wording.
I agree that rotated pads have no real negative impact. Still, I'd avoid unnecessary complexity (I wouldn't accept a footprint using custom pads that are really just rectangles for example.)
That being said, I'm not sure we need an additional rule. We usually only receive submissions with rotated pads if the whole footprint has been rotated along the way. I tend to think an extra rule mostly adds bloat.
@chschlue @poeschlr there are a ton of parts with rotated pads in the library today. Imo if it a clear "don't rotate" and we don't have it in the KLC and in a rule, which I have a change ready to propose, then I'd argue that we shouldn't worry about the rotation. Ie. if we care we should note it and check for it automatically, if we don't then we should ignore it and not worry. We shouldn't both worry and not document it and not automatically check for it...
I'm really ok either way. The rule is ready if we decide we want to put this in and want to provide that feedback via the CI system.
Perhaps we should change F4.3 instead? (To say that overlapping pads should be replaced with custom shapes, that copper shouldn't be rotated for no good reason and possibly some more general pad requirements)
Also, Thermal vias (if present) must share the same number as the thermal pad to which they are connected is repeated in F4.4.
@poeschlr has, if I was properly in his mind, in the past avoided adding many clauses which were likely to give bogus results or constrain submission without reason. As I started, I just started doing this because it was easier to check the diff alongside a check in KiCad. So you will want his input before this gets merged. As only website maintainers have merge rights to this repo he should give a blessing here and then request it be merged.
I don't think the style used here matches the rest of KLC (but this issue isn't limited to just this addition). What sticks out to me is the use of e.g. elsewhere but Ex. here. Also, note that custom pads don't have the option of thermal spokes so while we have migrated in that direction for many footprints I'm not sure a blanket rule is appropriate when there isn't equivalence. For a thermal pad that will likely have a solid zone connection it's probably fine, but this all over the library at this time might be the wrong approach where a more nuanced use of custom pads is best for now.
Alright, it sounds like there isn't consensus behind this change. I'll drop for now.
I have to agree with @evanshultz here. A rule like this would border on being pedantic and i am not sure we should invest time into enforcing something like this. It is in most cases the result of us requesting to rotate the footprint because we want it at orientation A (pin one at top left corner). Requiring this is just adding additional work for the contributor which i am not sure adds enough to us or the users to warrant the needed effort.
Alright, it sounds like there isn't consensus behind this change. I'll drop for now.
Should this pull request be closed?
@marekr works for me, if no one else thinks we should change it we should close it out.