KLC 2.0 - Now with bells and whistles

Hi all,

KLC 2.0 has been released, in an ongoing effort to achieve the following goals:

  • Improve the quality of the libraries
  • Move the KiCad libraries further toward industry standard compliance
  • Make it easier for users to contribute to the libraries
  • Reduce the load on the library team

There is now also a FAQ section which deals with issues that are raised often.

Over the last few months we have been working on an automated system for running various tests against user-submitted footprints and symbols, using the Travis CI tools. The shiny new updates to the library scripts will be live soon, and these fix the various issues we have encountered thus far.

The library utils scripts are also very handy for offline use - they check many (not all) of the KLC guidelines and now are much more fully-featured.

Thanks for all the contributions thus far, the quality of the libraries has improved greatly in the last few months. As always we welcome any further assistance!


I strongly dislike following explanation: https://github.com/KiCad/kicad-library/wiki/Frequently-asked-questions#symbol-variants.

BTW: Status table is broken. https://github.com/KiCad/kicad-library/wiki/Status-of-the-libraries

Can you explain why?

Where symbols are provided in multiple pin-compatible footprint options, a single symbol can be used, with multiple footprint filters as described above.
However, often manufacturers provide a component in multiple footprints that are not pin compatible. This means that the same schematic symbol cannot be used for each footprint. In this case, a separate symbol must be drawn that matches the pinout for the different footprint.

I think it should be like this: one symbol (with aliases if any) per footprint. For example: ATtiny24/44/84 family in SOIC-14 (0.15" body) package should have one symbol for ATtiny24-20SSU and two functional aliases: ATtiny44-20SSU and ATtiny84-20SSU with correct footprint. ATtiny24/44/84 family in PDIP-14 should have separate symbol entry, even if the pins are compatible with SOIC-14.

Also, the LTC4357 is a bad example here because this is not a generic part, and each package have their own unique suffix.This may give the illusion for symbol designers that they might, however, call the components contrary to what the manufacturer recommended. What is in contradiction with the earlier sentence:

For Symbols specific to a given manufacturer, the name symbol should follow the recommendations of the manufacturer.


Ah, good point. Yeah, I totally agree with that.

Thanks for pointing this out, it was poorly worded and did conflict with the previous instruction.

I have updated the wording here - https://github.com/KiCad/kicad-library/wiki/Frequently-asked-questions#symbol-variants

1 Like