Libraries and Components- The Disconnect


I’ve been playing with applications for 40 years and most times my rule of thuumb is that I should be able to get 70% of the functions without resorting to the manual… KiCad fails this test for me in terms of componentz and libraries
The problem as I see it is the accent is on libraries, and not the components.Just try to open up an existing and save to another library in eschema to see the problem… Even the program is called a " Part Library Editor"

I believe that the accent should be on the component, the library is a folder containing components. I know I may be a little naive here in the inner workings of Kicad but I am having difficulty understanding why libraries are so featured in the Kicad make up, and not components…

I also think that that the definitions are wrong, footprints Yes but schematic representation as a component No
So I propose Schema and Footprints

Enclosed is a flow chart of an intuitive method to create and save both options. If it looks familiar it is because it is. Open up any Word or Excel to see the arrangement. As is the New/Save/Save As functions I am familiar with in Cut2D, Mach 3, PCArtist, and a plethora of other programs I have used.

Please developers, in version 5, address the difficulties of the component library disconnect…
It is not intuitive, It is not easy, It is not commiserate with the level of professionalism that is shown in other parts of the program


Well, first welcome to the club.

Second, this is a support forum, not a developers forum. If you want to have your voice heard and probably dismissed 5 seconds later this is the place to do that:

Third, most of your concerns are essentially non existent.
If you want to run components please use the search function with the term ‘atomic’ and you will find that KiCAD also allows this kind of workflow, to define components.
It’s all there.
You just have to learn the ropes and maintain your own personal libs, as the official ones will not be able to ever support this kind of setup.

Some more background info, so you get WHERE KiCAD comes from…
KiCAD started as a collection of tools in the french language.
Over time this got morphed into what KiCAD is now.
Schematic symbols will be called that.
Layout footprints will be called that.
Components/parts exist in the form of links and only as a combination of symbol + footprint + meta information (partnumber, etc. pp).
KiCAD evolved from hobbyist users, who wanted to be able to use any set of symbol with any (pin matching) footprint. That’s why KiCAD does have this lose connection and no dogmatic view of a singular atomic component.
That’s how the KiCAD world looks at things.

Good luck and if you run into trouble defining your own atomic parts, don’t hesitate to speak up. We’ll be glad to help where ever possible.


If I was a German speaker, I would coin a word that means “culture shock when encountering KiCad for the first time”. Maybe there is already :slight_smile:

I am a software developer. In my spare time I develop little bits of software for home use. I was recently revisiting software I first wrote exactly 30 years ago. Looking at it, an immediate thought was why the heck did I write it like that?. There are several reasons, my own knowledge and skill has developed a lot, PC hardware has changed enormously (no longer do I need to pack all data into a 64KiB segment), programming languages and development environments have improved enormously.

Anyway, it was quite interesting to rewrite code that was originally written for DOS and character mode GUIs, but because it is for my own use, I don’t need any backward compatibility, I can completely change the interfaces and file format to suit a 2017 PC. Also, I only have a few 1000 lines of code, not millions.

KiCad started out with a DOS program, and has grown since. Ideally, we would start with a blank sheet of paper and redesign KiCad, According to, KiCad has accumulated 860,000 lines of code, costing $12 million or 233 person years. KiCad doesn’t have anything like such a budget to spend on creating new code.

TLDR; because legacy. We don’t have a magic wand to create new code.

There are some things you can do that will make a difference:

  1. if you can code, contribute patches to Kicad
  2. or create external tools which work with existing KiCad files
  3. otherwise, donate to developers who can work on your ideas

Everything else is basically talk (no offense intended, I understand it comes from a desire for improvement which we all share). KiCad is not short of ideas for improvements [KiCad wishlist] (

I created an unofficial repo for atomic parts. Submissions welcome :wink:


Most libs in the official symbol libs hold parts that i would define as atomic. (Only the Device, Switch and Connector libs are fully generic. All others should hold atomic parts.)

Every part there is identified with the manufacturer part number and the footprint field is set. (Or at least this is the goal. A lot of symbols do not yet have the footprint field set. But we are getting there.) This approach allows for footprint reuse. Take for example the soic-8 footprint. That particular footprint is used by a lot of different devices.

The footprints are generic where they can be generic. (This does reduce maintenance effort.) We allow for manufacturer specific or even part specific footprints. (Example for the former are the footprints starting with Bosch_ in the LGA lib, for the later have a look at the relay lib.)

What we can not provide is the inclusion of your personal house part number (self explanatory.)
Or the inclusion of ordering information. (Who would ensure that this is valid at all times for all users. Too much maintenance.)


You contradict yourself in the same paragraph… Very few of the parts in the official library are atomic, because the vast majority use generic (shared) footprints. An atomic part has its own, dedicated footprint which is not shared. It is not a stated goal anywhere in the KLC to create atomic parts, it is more incidental for certain components with a proprietary footprint.

I understand your desire to promote KiCad, but saying things that are really quite misleading is not helping anyone.


What would be the benefit of this? As far as i can tell a SOIC-8 is a SOIC-8 no matter what part it is used for.

I see one major downside to having one footprint per component instead of one footprint per package. (maintainability)
Lets imagine one sets up a lib that way.
You discover later on that your SOIC footprints (with exposed pad) should get a slight modification to the paste layer because your assembly house found that they could increase yield that way. Now you need to go through your lib and change all SOIC footprints. There is a high danger of you missing one of them. (If they are atomic is it even easily possible to find all SOIC footprints?)

Of course if you have a MEMS sensor that needs special treatment then you will make a specialized (or atomic) footprint for that sensor. But this does not really make sense (to me anyways) if you do it for the logic chips. (You would need as many soic-14 footprints as there are logic symbols in the logic lib. All of them holding the same data.)

What term would you use for symbols that are fully defined and represent one component, but point to generic footprints?


Semi-atomic? You select a component (symbol) and get also a footprint automatically (this is what people often want and are happy with), but the footprint is shared. Or unidirectionally atomic? One automatic footprint for one symbol, but many symbols for one footprint.


Looking at the KiCad FAQ and KLC, I see that some confusion has crept in. Both documents have a misunderstanding about atomic parts They both refer to “atomic parts” but get the concept wrong. Someone (maybe Wayne), coined the term “fully defined part” , and then he or someone else decided that is the same thing as “atomic part”, but that is wrong. At best it is compromise between generic and atomic parts.

It is true that an atomic part is “fully defined” but it is important that an atomic part is also self-contained, unlike “fully defined part”. An atomic part has a 1:1 relation between symbol and footprint, fully defined parts are only many:1

Why is that important? Because of version control. In production it might be necessary to change the footprint properties for a specific component, and you don’t want to propagate those change to any other.

Therefore we have 3 types of part : generic, fully defined (but probably a shared footprint), and atomic (self contained). The KLC (and official libs) might have a goal of full defined parts, but that is not the same as atomic parts.


For what it’s worth, there was a recent discussion on the developers’ email list about nomenclature, as in “what is a part vs what is a component?” And it turns out that the answer isn’t as simple as one might hope. Part of the problem is that (as noted) Kicad’s developers (and users) speak many languages, and as such interpretation of those words differs. For example, I’m guilty of considering “part” and “component” synonymously, and one of the others on the developers’ list suggested that they are not. To wit, a “part” can be a generic thing, like a resistor, a capacitor, an IC chip. And a “component” is more fully specified, such as a 10k0 1% 0805 resistor and an SN74LVC17PW Schmitt Trigger buffer.

A corollary to that discussion was, “the EESchema libraries, what do they hold, anyway, and when we edit something, what are we editing?” From a purely operational standpoint, the “library editor” in EESchema allows users to edit symbols and whether those symbols are parts (resistor, cap, etc, as defined above) or components (that 74LVC17) or “just a symbol” (like your power symbols VCC et all, and symbols which call out things that need to be on a BOM, etc etc). That kinda muddied the waters.

A second corollary follows from the history @Joan_Sparky discussed. Originally EESchema and pcbnew were separate programs. (Aside: there has been discussion about renaming these programs and the other Kicad utilities to basically unify them under the Kicad banner.) The original idea was that symbols and footprints should be separate. After all, why have a hundred op-amps in your symbol library when only one is sufficient? And why not have the ability to choose which footprint you want to use for your op-amp when you go to do the layout, as it doesn’t matter what footprint you want when drawing the schematic? Hence, separate libraries and a utility (CvPCB) that lets the user do the footprint assignment after drawing the schematic.

Except: professional users (who design electronics for a living in a typical business environment) utterly abhor this whole CvPCB flow. I could list a whole bunch of reasons, but it comes down to this: these users (myself included) work from a vetted parts list (where the criteria includes non-design things like “can we buy this part?”). So anything in a component library must be complete. That is, an “atomic part.” This requires that, for starters, there is no such thing as a generic op-amp. Instead, the library has a part OPA1652AID. And since we are familiar with the vendors’ part naming, we include the suffix which indicates package. This requires that the library symbol include the correct footprint. The final required bit of information needed to make the symbol a complete component is a Part Number. Whether that is a manufacturer part number or a company/house part number is driven by your company’s ERP requirements. At my day job, we have such an ERP system and everything that goes into a product is assigned a company part number. So that part number is in every library component symbol, so when a BOM is generated, the purchasing person can import it into her system and order parts as required.

And for the hobby/DIY/Maker users who do not have an ERP system and aren’t building anything in production quantities, the original CvPCB flow works for them.

The good news is that Kicad support both use cases.

Sorry for the length.

The end result of the listserv naming discussion was that they were going to pick a nomenclature and document it so every user will be clear on what is meant. And again, that is especially important because of the multiple languages spoken by users. And if you choose to not RTFM, then I can’t help you :slight_smile:


[quote=“rodmcm, post:1, topic:8879”]
Please developers, in version 5, address the difficulties of the component library disconnect…
[/quote]Well, 5 is in feature freeze so it’s pretty much a done deal. As far as the 70% rule? Playing around with applications for 40 years may mean nothing if you have little to no experience with ECAD and you don’t tell us that. I tried gEDA and it was very apparent that the people developing it worked with it. I loved many elements of the work flow. As far as it went. With Kicad you at least have developers that use the software and make the decisions about its direction and not some marketing department.

To your point. The libraries have been a bone of contention for some time and that is being worked on. Many simply don’t care because they plan on vetting every single part they use because it is their axx on the line if something fails. This is independent of Kicad. As such, the existing structure becomes second nature to them. Change it too much and the existing user base might not be very happy. :wink:


You want the schematic designer to choose generic functions such as NAND gate or OPAMP. This is the design that they simulate and verify.

The PCB layout engineer will select the actual parts and package the symbols together and assign slots. PCB will also select technology such as surface mount top or bottom, through-hole 1 sided,2 sided etc. Each one of those has a different footprint and pad-stack.

The symbol has no way to know what footprint will actually be used on the board and each board will be different.

John Eaton


I may disagree about who performs the specific tasks, but my personal observation and experience supports the basic point: “Design” is almost always a series of activities where the later tasks add increasing amounts of detail to what was done in earlier tasks.

I feel inefficient and frustrated when I am forced to specify all the final details too early in the process. When I start to create a schematic I may have only a fuzzy idea of what value is required for some parts. Requiring me to concentrate on details down to construction and packaging, at that stage, actually hinders my ability to concentrate on fundamental questions such as values, power and voltage ratings, etc.



Yes, One thing that managers need to under stand is that if you ask an engineer to go back and change a decision that they made in the past then they must now go back and revisit every decision that they made since then. Thats why changes take a longtime to get right.

John Eaton


Thanks for the comments… However I was not really talking about atomic entities but about a standard coherent methodology in the creation of a new, modifying an old, or copying an entity, be it a schematic symbol or a a footprint.

The present methodology is non conventional, not intuitive to me, and differs between a schematic entity and a footprint hence the standard flow chart I suggested…

As to having separate footprints to schematics I like it! I can craft my schematic representation to the job at hand, especially with processors where a design could need analogs to the left and outputs to the right.
As far as cvPCB is concerned I only use this to check that all items have an assigned footprint. A simple list would suffice for me


That is true – but in many companies, engineers work from an approved parts list*, and the whole process involves more people than the schematic designer and the layout person. I mean, there’s purchasing to consider, for starters. And the mechanical engineer, who designs the enclosure and very likely does thermal modeling.

And the design engineer and the layout person have to communicate – talk to each other – to make sure that what the layout person is doing doesn’t negatively impact the design performance. A great example is FPGA pin swapping. The layout person wants to swap pins to make that job easier. I need to tell him what he can swap, what pins are fixed (clock inputs and the like), how to manage differential pairs, and to make sure that I/O bank voltages are correct for the signals. And after he’s done with all of the swapping, we still go back, update the pin constraints in the FPGA tools and re-run the design to ensure that the fitter doesn’t complain about illegal placement and that it meets timing.

So as to the assertion, “the symbol doesn’t know what the footprint will be,” is true in a pedantic sense, but I place OPA820 on the board for a reason, not because it is “just an op-amp” that can be changed for a TL071.

Modern board design isn’t the “throw it over the wall” style one could use back when it was all MSI TTL design.


  • the approval process for our “approved parts list” is not this painful rigorous process you might envision. Rather, it’s, “Oh, i need to use this part!” so I fill out a part number request with pertinent information (vendor, vendor part number). We ask purchasing to verify that it’s readily available and isn’t likely to go NRND soon, even though engineering tends to follow the “Digikey rule” – if it’s not available in quantity from Digikey or Mouser, we rarely consider using the part. Then we have the layout guy make (or find) a symbol, make (or find) a footprint, and marry the two and put the resulting component into the company library after someone else (generally the person requesting the part) checks it. Then the part is “released” in our ERP system.

Why do we do this? Some good reasons. One, reusing components in the library makes financial sense, as we can buy larger quantities for the price breaks, and oftimes those parts are already on the shelf so they don’t need to be bought. Second, a part in the library is “vetted,” meaning the symbol and footprint are correct and it’s a part we can get. The engineer doesn’t have to do any research on it beyond determining whether it’s the right part for a design.


[quote=“rodmcm, post:14, topic:8879”]
The present methodology is non conventional, not intuitive to me, and differs between a schematic entity and a footprint hence the standard flow chart I suggested…[/quote]

With the schematic library revamp coming up in V5, symbol editing will be very much like footprint editing, and the library system will be the same (library tables, etc).


Thanks for that
Is there a release date for V5?


Haven’t seen one pop up on the list.


The goal is to have it before FOSDEM (february). At least according to wayne. But he admits that this might be a bit wishful thinking on his part.


Lets back it up a little bit more. Why have how many resistors in your symbol library when only one symbol is needed for drawing the schematic.

Could the CvPcb workflow be integrated to look only at only certain libraries/folders, that contain only ERP approved part numbers?