Not sure if this should go under feature requests but…
As someone who has contributed and worked as a librarian, I noticed there was a check symbol button in the IDE for 5.99
There are some really helpful scripts in kicad-library-utils.git, it would be great if we could run those from the IDE and show the output in the IDE. It would save a ton of time having to manually run that separate step. Maybe that’s in the plan for v6 or later but if not I wanted to bring it up.
If the checkers would run automatically and show a list its of the issues real-time in a separate window or when editing then authors would be able to immediately see that something might not meet the library conventions and address it there vs. the longer loop of pushing a part and then having the CI system find it.
I vaguely remember that there has been some discussion about it and that it won’t be done. If it has been discussed @Rene_Poschl has certainly been part of the discussion.
They check for KLC compliance. People don’t usually follow KLC convention strictly for their own libraries. Therefore usefulness would be limited to very small group of people.
ATM eeschema and symbol editor don’t have scripting API, but it’s been planned for v6. But scripting has been in pcbnew for a long time and even then the footprint editor doesn’t have that, it can be used only from the board editor. I don’t know if that will be the situation for the symbol editor, too, and in v6. If the library editors receive scripting abilities some day it should be possible to write a plugin and run the tests from it.
Another option would be to add a specific plugin architecture to the library editors, like there’s now the footprint wizard architecture and scripts.
In any case these are feature requests and should finally go to the issue database if there’s a realistic chance to get something accepted by the developers. I’m not a developer.
But still, If I’ve made a half baked Footprint for personal use, and such a scripts points out area’s for improvement I won’t mind getting pushed a bit in the direction of KLC. And I’ve got some fetish for wanting to have “error free footprints”.
Keep in mind that the arguments over how wide to assume adoption of KLC predate the user-settable severities (including ignore).
I don’t have a problem with adding tests that very few people use as long as they can be individually turned off (or even default to “ignore” out of the box).
My idea might be for a longer-term development, but I think it would be better to have the footprint and symbol checker(s) configurable and the configuration can be done setting-by-setting and by importing configuration files (this would also make exporting a configuration file desirable). Having KLC be the default would be ideal, but if one’s organization uses different rules (or a tailored interpretation of KLC) being able to apply the different rules would be good. Having the checker rules able to be imported by reading a configuration file would allow both:
Simple distribution of the same ruleset across an organization.
A freelancer to be able to apply the rulesets of different clients when needed.
I am not certain, but I’d think this is of limited use. It may be handy if you want to check a single footprint or library symbol, but for more elaborate checking working with external scripts that iterate over whole libraries are probably a better approach. I think this is how it’s done at the moment anyway.
When KiCad gets a better command line interface, then the appropriate program (Schematic symbol or Footprint -Editor) could be loaded directly if a problem is encountered (or problems first logged in a separate file).
@JeffYoung would an easier avenue be to implement action plugin interface also to Footprint and symbols editors?
Then anybody can write any plugin which would check the footprint/symbol. A plugin to check for KLC (or any other standard) and report back would/should not be hard to write. And plugins would stay third party so the core team would have a bit of distance weather using KLC or any other standard.
DRC already uses registered plugins, they’re just C++ at present. So it’s probably a little easier to expand that to include Python than to do more of a plugin interface for the symbol and board editors.
Error free footprint does not mean the same thing to different people. And the checks a script can do are quite limited. The main things to check are dimensions which can currently not be automated. The new measurement features of kicad will however make it a lot easier to do such checks as one no longer needs to export to some other software.
Even symbols can not be fully checked with scripts. The main thing to check are the pin names and numbers (plus checking that the footprint uses the same numbering scheme as expected).
I mean yes there is a script out there that can extract pin names and numbers from the datasheet (if there is a table in there that is correctly formatted) but i doubt it can extract the alternative names as supported with v6 so again limited to simple components (that are manually checked in less than a minute).