I find myself frequently creating new symbols, footprints and 3D models of the parts I use, which seems to be the norm for pretty much all ECAD activities.
As there is not really such a thing as “close enough” in anything other than symbols (correct pins in a symbol is good enough, but bad pads on a footprint is not), I end up creating new parts for pretty much everything.
Is there any guidance on what is worth contributing back to the community and what isn’t? I’m generally using pretty simple and common parts, but that still leaves things open to unmanageable repository sizes.
That document, and the “Contribute” document, seem to focus on how to contribute, and not on what to contribute, which was my question. The KLC in particular though is lengthy, so if I missed the part about selection criteria I’m happy to stand corrected.
Judging by some of the very specific components, I suspect the answer is “anything goes as long as it is generally available”.
Any symbol or footprint KLC compliant is a candidate for the official libs. The librarians must check wheter the component passes their criteria or not.
If you don’t know, that’s fine. I’ll see if any of the librarians comment on the existence of any guidance.
It is a fair amount of effort to make parts fully KCL compliant, and I don’t fancy doing that if most of them will just get rejected because of some invisible and arbitrary reason.
The only reason for your parts to get rejected is if they’re already in an official library. If your design has need for symbols, footprints or models not in the libraries and the parts are generally available then it’s likely they’ll be worthy of inclusion.
If users don’t contribute to the official library, everyone who requires the same parts wastes effort creating their own versions of the symbols, footprints and 3D models instead of helping to refine the official ones.
The KLC goes towards giving some reassurance that library parts are likely to be design-safe to use as they are.
There are some scripts available which you can use to check if the parts you are considering submitting are KLC Compliant - they will identify any design deficiencies before you make a pull request. This should weed out most oversights before getting too far. The process cannot be completely automated though - the symbols and footprints are all checked for accuracy by hand before they can be included in the official repository.
As the guardians of quality, we must be grateful for the huge amount of work that has gone into auditing, maintaining and systematising the library by the small, intrepid band of volunteer librarians who truly deserve a vote of thanks.
I’ve been using those scripts, they are a great resource. I’m not a professional EE by any measure, so I hope that following the KLC and the output from those scripts can only make the boards I try to make more likely to succeed.
If I’m going to learn something new, I figure it’s worth learning it “as right as possible” from the start.
The scripts do not really check anything that would make the footprint or symbol safer to use. They mainly check stuff that is only important for having a consistent library.
The things that are really important need to be hand checked (this is the main work that library maintainers do.) So the pin number, pin name and pin type stuff still needs to be compared to the datasheet. And for footprints a dimension check is also in order (For that i have a tutorial for my workflow here on the forum: Tutorial: How to check footprint correctness?)
For a lot of footprints we have quite powerful generator scripts that make it easier to get it right. (for most standard IC packages there is one that uses IPC equations and constants to arrive at a footprint from package dimensions) They are found here: https://github.com/pointhi/kicad-footprint-generator
For the simple stuff I’m building, I generally find the standard packages are well catered for in the standard libraries. It’s mostly specific connectors and non-standard things like relays and AC-DC converters etc that I find myself creating. So many of the script tools don’t really help much.