Yes, and this is where our philosophies differ.
Your approach is, that if a symbol has more than one footprint with different pinouts, you just add a new symbol/alias, bloating the library even more.
My approach is: a symbol is a symbol.
And if an engineer cannot connect a symbol to the relevant footprint, then the datasheet has not been read, and understanding of the own circuit is non-existent.
I’d say, getting a job turning beef patties would be more to the point.
But I’m just a grumpy old guy, expecting just a little bit of brain from designers.
Too optimistic, perhaps.
1 Like
Your approach is, that if a symbol has more than one footprint with different pinouts, you just add a new symbol/alias, bloating the library even more. My approach is: a symbol is a symbol.
this doesn’t work with the current kicad (and also not for altium CS, and only partly for eagle) way of defining symbol+component. A component with different footprint can have a different pinout - so a different symbol is needed.
As kicad currently ties symbol+footprint together with the pinnumbers: it’s necessary to differentiate between different footprints.
My complaint about the libraries is not about quality, which is pretty good. Some are old, and need some corrections, which I do with my own libraries.
But I don’t understand why “alias” and duplicate parts are there in such a quantity. Apparently, everything submitted is accepted, as long as it’s correct.
The symbol library is so bloated, that it’s almost impossible to find what you need (a 'phone book would be easier).
Examples: why are there two simulation libraries?
Why are there hundreds of dual op-amps that all have the same symbol and pinout?
Why are there hundreds of diodes when Diode, Zener, Schottky, Tunnel, Capacitance, Diac would suffice?
The “Device” library is very good and seems to have been created by someone with competence and knowledge, just to name an example.
1 Like
You’ve nailed the weak point here. And I don’t have that answer to that one. Fact is, that the symbols need pin numbers as it is. And they’re mostly DIP/SO numbers.
I like this sort of “brainstorming” thread.
Folks, this struggle has been going on for years. I have worked for 4 different companies, done consulting, and know a fair number of engineers. Everyone I’ve met who does this for any length of time has their own library. No library will have everything everyone wants, how they want it. The best you can ask for is a starting library with some quality parts, so you have at least some foundation to build on, and KiCad provides that. In fact, we used it to build much of our internal library, even though we use Altium (gasp!).
Even if you have a a bunch of top notch PCB designers, they will argue about this or that aspect of the symbol, nuances about the footprint, etc. It will be based on the various ways they got burned in production, or simply visual preferences. It used to bother me, but now I just make whoever wants a certain look or feature in a symbol or footprint document what they want or go away. If they can document it well enough to follow, I will follow. Consistency has it’s own merit, and I sure don’t want to manage it.
However, since moving to a database library, many problems went away. You can design symbols, and you can design footprints, and the parts in the database grab the symbol and footprint you want. You can have the minimum number of symbols and footprints possible and consistency is practically guaranteed. Once we moved to a database library, so many problems and errors went away. That’s why I am so glad KiCad is taking this step, because it means we can finally start moving to KiCad. Altium works, but it gets very expensive once you start having multiple seats, and we have found our customer experience to be unpleasant, to say the least.
Just my $0.02 or your country’s equivalent.
John
4 Likes
Library team member here. There are many many things we would like to do to make the libraries better. Getting rid of most of the simulation symbols in favor of stuff from Device is top of the list. However, most of our time goes to reviewing contributions. We have a large review backlog because the team was down to effectively 1-2 people over most of this year. We are actively recruiting people to help us do reviews (I just recently joined myself). We could especially use help from people experienced with scripting/automation, but it’s also helpful to have people who can check contributions for correctness and KLC compliance so we can split the effort across more people. If you would like to help, please get in touch!
9 Likes
May be an idea to post an address or link here?
Perhaps an advertisement in FAQ also? 
Here is the rub. There is no one correct organization of the libraries. It is obvious we have different workflows, different views on organization of the assets and different external requirements how the libraries should be organized and what they should contain. And then we need we need to align all of these with features available in KiCad. And from what you’ve written @ML9104 I think you should look up on how Horizon EDA organizes symbol libraries. If I am allowed to dream it would be nice if KiCad would allow more flexible symbol library organizations. But when waking up I remember that this would need developer effort, which is probably better spent on more pressing issues.
The library is gravitating towards fully defined symbols. Not all of the symbols are fully defined (some are general) but most new contributions are. It comes down to reducing the designer effort when drawing schematics. When you place OPA340NA you have a proper symbol within the schematics and the symbol already has proper footprint selected with proper link to the datasheet (if the manufacturer did not change the website layout). And if you also populated supplier part no. You can export the bom and order components. If you would place general symbol for an opamp, you’d first have to find symbol with proper pinout (as KiCad does not support symbol-footprint pin remaping) then you would need to enter all previously mentioned data. This is tedious and error prone.
So as I imagine that most contribution to KiCad library are of symbols that one regularly uses, one tends to enter this data already in the library symbol. Thus most new contributions are “fully defined”
In the end the official library is what it is. I think it is really good. And I think that we mostly agree that the quality of the assets is good, but the organization is not to everybody’s liking. As such the library is a good starting point and as such it makes little sense to reduce requirements that the assets should conform to before accepting them in the library.
May be an idea to post an address or link here?
Perhaps an advertisement in FAQ also?
message me on this forum, and we can figure out the rest by email after
maybe that’s your view but that is certainly not how it can (and in my opinion should) be used in KiCad.
First of all the datasheets: If you don’t define them in the library you can’t define them anywhere else. if you want to have them in your schematics (and every engineer I know want’s to have them there) you otherwise would have to assign them one by one in the schematic. who want’s to do that?
Next footprints: It is not a thinking task for engineers to let them assign the right footprint to a symbol. it is just a shifting of part of the search in a bigger component library to the search of the right footprint. and it is more error prone too. if the footprints need to be assigned again and again eventually in this process a wrong footprint will be selected, as even the most perfect human being will do errors once in a while.
finally additional fields: multiple times a year a discussion pops up here to add even more information to the symbols, e.g. MPNs, so we have contradicting movements here. in the end there is not a way to make everyone happy.
This is mainly a limitation of KiCad itself:
In KiCad, the “schematic symbol” is the “part”. At the moment Kicad has no native method for handling parts which can have different packages and pinouts. An example for this is the ubiquitous ATMEGA328, which comes both in a sDIP-28 and TQFP-32 package. Because KiCad has no method to assign different pin assignments to the same part, different parts and thus schematic symbols have to be created.
On a larger level, this is also related to “database libraries”, in which a more abstract definition of a “part” is useful. On that level I’d think of a “part” as an empty container, to which data such as schematic graphics, footprints and other meta data can be added. There is currently some initial support for database libraries in KiCad-nightly, but I do not know any details of that.
I understand your thinking. But the fact is, that the library contains links to datasheets,
and those link contents are outside KiCAD control. If your engineer doesn’t check the datasheet directly at the manufacturer, he/she should be fired for negligence. End result: no time or affort saved.
Well, no. That’s exactly the problem. It’s a symbol library that includes some “part” information, but at the same time it’s a part library that only contains scant device information. It’s neither.
And I think the KiCAD “Steering Board” or whatever it’s called (I’m not good at political things) should take a step back and decide exactly which direction to take. I’m sure you do already.
And please take this contructively, I appreciate all you’ve done and are doing.
Thanks.
Developers did not decide to put datasheet links into the main libraries. That was a decision among library maintainers.
There is no steering board.
2 Likes
I apologize for being ignorant of the inside workings of FOS projects.
I can see why datasheets are referenced, the inconsistent 14 pin DIP package length issue a couple of years ago is an example, but they are a complete pain to maintain as they are constantly changed by the OEM.
There is a reason why KiCad’s library is distributed with links instead of embedding documents within the library. Most of the documentation from the manufacturers is released under the terms that you don’t have the right to distribute the documentation further. So KiCad legally can not distribute the documents directly. Same goes for 3D models. Now with documentation there is a sensible reason behind it (besides IP/legal reasons). The documentation might change and with the link you should always get the latest version of the documentation. I am pretty sure that if KiCad library would come with documenation, somebody would complain why the datasheet revision for a specific part is old.
With 3D models I think it is just IP/legal bullshit preventing the inclusion of manufacturers 3D models in KiCad’s library. This also leads me to reason that manufacturers don’t really have a priority to put their parts in the library as you’ve alluded. As this prevents us for doing their job for them, and I think that they should appreciate somebody else doing their work for them.
As for the dependency on linked documentation I fully agree that this is a serious problem nowadays. And it is a present in all fields. As our systems are getting bigger and more complex more and more of our work depends on somebody else’s work (standing on the shoulder of masses?). KiCad has already learned this at least twice. In V4 (IIRC) you could link footprint libraries to github. And IIRC the official libraries were actually linked. Even more, pcbnew (PCB editor) automatically updated used footprint if the footprint in the linked library changed. This was soon recognized to be a bad idea. And until V6 the symbols cache was not part of the schematics. The solution of linked 3D models is also planed.
As for your issue with the links to documentation. Having symbols encoded in a readable text format makes it possible (if not easy) to parse files for documentation link, download the documentation to a local storage and change the link to point to local storage. You could further improve this and periodically scan for updated documentation and alert the design engineers about the changes.
With V5 I’ve made a similar plugin that did this within a scope of a project (for documentation and 3D models). But the solution was somewhat awkward so I decided not to port the documentation part of the plugin to V6. When KiCad gets python API for schematic editor I will implement this functionality port it.
Links to datasheets in the symbol record should be a non-issue when databases are deployed. It’ll probably be a field that’s obtained using the MPN thus ensuring that you get the datasheet from the relevant manufacturer.
2 Likes
ok, what exactly is the difference when instead of using the datasheet link in kicad the engineer goes to a distributor side and uses the datasheet link there or goes to google and uses the link google provides? except from more time it takes to copy the MPN, open the browser, going to the side and entering it, there is no difference. in neither case the engineer or the service (if it is the distributor or google) has direct control over the datasheets. your point is purely academic.
and btw: the KLCs don’t even require you to enter a datasheet, you can just fill the field with ‘~’.
When did I mention “distributor”? Neither KiCAD nor “alibaba” are reputable sources.
The manufacturers are.
for you maybe, but that doesn’t mean most of the others working with kicad see it like that. and btw, a link to a manufacturers side is then per your definition reliable…