A perspective on a centralized model repository for symbols and footprints

Community Feature Request Chat
1

I hope people will take this in the spirit it is offered, this is my perspective as a relativly new user.

kicad is a very very difficult application to master, it does a bunch of things that very opaque. The main one is symbol, footprint and model management. The decision to handle these as separate entities makes managing components in kicad really hard. i seem to spend most of my time trying to locate and piece together component symbols and footprints, the whole 3D rendering side from models appears to be a total waste of time as 90% of the models are not available.

It makes no sense to me to handle symbols and footprints seperatly, in fact doing so seems to have spawned a large number of incomplete component definitions as people hack their own implementations into private projects.

Would it not be a good idea for the kicad project to sponsor a centralized model repository for symbols and footprints that can be run like a wikipedia model, with a direct search API for integration to kicad. i know that people like snap-eda do something like that but even thier implementation is spotty and incomplete. Naming conventions are all over the place, the github approach with separate files means there is no available searchable metadata.

by having an accessible central repository that has moderation and standards enforcement, possibly sponsored by folks like snap-eda etc, would ensure that there is a one stop shop for everything. One can even support click through bom buying from the large vendors to encourage them to participate.

I work on parts exchanges for aviation and automotive, so i know how much of a difference it can make.

one final issue, the current model integrates pin-outs and footprints too closely, what is needed is a separation so that pin-outs for common chips can be mapped to common encapsulations. like DIP14 or SOT5, and they should be the third layout type. that would go a long way towards the standardization, the current scheme seems to be find a footprint etc that is close and edit it, but component footprints are largely standard across a large number of parts, i know this sounds like arguing for separation after arguing for integration, but this would be a key part of an online reference exchange, standard part mechanical data and footprints not tied to device pin-outs. It would also help to alleviate the 3D model scarcity if models where attached to a “encapsulation” type.

I want to stop having to spend hours of wasted time trying to find obscure components to use them in kicad

2

I do not see a single question mark at the end of any your sentences.

What is your first question?

1 Like
3

There are fully specified symbols. Such a symbol is typically named after the part number it is valid for and has the correct footprint already assigned in the library. It is the responsibility of users to then add their order information as the official library team can not show bias towards any distributor and it can not maintain order information for every distributor out there.

One of the strong points of KiCad is that you can assign a symbol to any footprint. This is only possible because the libs are separate! Most components come in standardized (JEDEC) packages. It makes sense to have a library of footprints generated using an industry standard (IPC) for them.
To manage such a library efficiently you need to have the option to organize symbols independent of footprints.

  • For symbols organization with regards to function makes sense. Symbols after all are there to abstract the function of a part. (For example a lib for all voltage regulators)
  • For footprints however organization against general shape attributes (example lead style, lead placement, …) makes more sense. (for example a lib for qfn packages)

I currently work with eagle and see how badly its system deals with this. I either need to duplicate the footprint of the same package in multiple libraries (maintenance nightmare) or need to have symbols organized per package (which breaks some important eagle features so yea maintenance nightmare it is) This simply does not scale to the size of the official lib let alone to the size of the library a distributor would provide.

I made the assumption that you mean management in the sense of making a good organization instead of management in the sense of having it easy to download and use assets. The downloading and “installing” of assets is indeed easier in tools that have a combined file format as one needs to only add a single lib in that case. But i think this is a trade-off worth taking.

And it is not even that hard to import assets into the existing organization:

Snap eda can provide a KiCad library. This is their decision. (digikey for example started one.) But we will never let a company run the official lib.

KiCad could provide a standardized API for enabling such a usecase but i do not think this should be configured out of the box to provide an interface to a single distributor.

I point you to octoparts recent reversal of API licensing for an example why it is a bad idea to lock a tool to a specific external entity.

All KiCad assets are contributed by the community. We have two options. Accept that people are more likely to provide footprints and have a large library of them at the cost of not having 3d models for everything or require every footprint contribution to also come with a 3d model which would drastically decrease the number of contributions we get.

But yes currently 3d models are assigned using the file system path which makes it quite inflexible. I think version 6 will bring a library based system for 3d models.

So you are aware that the same footprint can be shared by a huge number of symbols. Interesting. Were you just unaware of the fully specified option? (What you say here in part contradicts what you request above)

Also yes right now a different pinout would require a different symbol. It would be nice if symbol aliases could define a different pinout. I think this will become possible with the new file format via the inheritance feature (note: I speak of the file format. We have no idea how this will be abstracted in the user interface as the file format is not yet implemented. We are also uncertain which parts of the file format will be implemented in the first iteration.)

Sorry that we do not have every component in existence represented in the lib. Especially sorry that we do not have obscure parts in the lib. Yours truly the head of the kicad library.

5 Likes
4

KiCad does have this. The standard libraries that come with KiCad are maintained on GitHub. See this link for contributing:


If you want to use the latest libraries (symbol, footprint, and 3D models) you can clone the three github repositories and point your KiCad environment variables to where you cloned the repositories. You can then periodically git-pull to keep your copies updated.

The standard libraries do have standards enforcement by the library team. The standards are defined by the KiCad Library Convention (KLC), and can be found here:

Obscure components are called “obscure” because they aren’t used by many people, so it is likely that someone else hasn’t thought to make a symbol and/or footprint for it. Making symbols and footprints are actually quite easy (but bigger pin-count components might become tedious although scripts can help here), so if the part is really obscure then you would spend less time just making it themselves vs. trying to find an already made symbol/footprint pair and then validating that what you found is actually correct. If you want your own creations to fit into what is already provided, refer back to the KLC (above) for guidance. And if you want to help the next person who might need it (and you designed it to conform to KLC) you can submit your work to the github repositories for inclusion in the standard libraries.

So based on your experience you probably also know how much work it takes. Please remember that the librarian team for KiCad (much like the programming team(s) for KiCad) are all volunteers. This is their hobby, not their job.

1 Like
5

The big problem with what is also called atomic parts, is that different commercial user all want something different. I have to deal with subtle footprint changes to suit my preferred PCB maker and assembler and no two companies will have the same approved vendor list.

In my past, I have worked in companies with large component standards departments managing these issues.

6

Do you mean atomic with one footprint and one symbol represent exactly one order number or do you mean the concept of having a symbol specify the footprint and order information but the footprint is still generic useable by many symbols that use the same generic package (which i would call fully specified symbol instead of atomic)?

7

There already is, it’s the KiCad official library.

This question comes up frequently, it’s a nice dream, but the reality is that it will never happen. Creating good quality parts costs time/money, and there are literally millions of parts.

The practical advice is:

  1. learn to create your own parts.
  2. pay a service like SnapEda, samacsys etc to create the parts for you.
2 Likes
8

Reality is that PCB layout is more of an exercise in identifying purchasable components, obtaining datasheets and designing suitable symbols, footprints and 3d models than actually laying out the board.
This has always been the case in my 40 year career

5 Likes
9

Despite the fantasies of the people who create organization charts and job descriptions - and pride themselves about being “in charge” - the reality is that these tasks are distributed among the circuit designer(s), the component engineer(s), the manufacturing engineer(s), the purchaser(s), the documentation controller(s) . . . . as well as the PCB layout guy. (Or gal. One of the best I worked with was a female girl person of the opposite sex.) I have been laying out PCB’s vocationally for only about 20 years, not 40, but “library work” typically takes at least half the total effort for a layout job. I can’t recall a job where “library work” was less than 10% of the effort, and many times 75% or more of the effort went to symbols, footprints, and their related documentation and verification tasks.

That is true not just for KiCAD, but also for some very expensive commercial EDA programs with built-in libraries containing zillions of parts.

Dale

2 Likes
10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.