Why not start an official KiCad Atomic library?


#1

There are library changes coming, why not include Atomic Libraries in the progression?

The biggest issue that I am aware of is whether or not parts are “pin compatible”.

The next issue is that my Atomic parts are intentionally not KLC compliant; I’m a rabble-rouser when it comes to compliance.

If there were a place to upload the various Atomic Parts that KiCad users have in their own libraries, then maybe there could be a separate KiCad Atomic Parts Compliance (KAPC) rules to that separate library.

Just trying to think outside the box.


#2

“Es gibt nichts Gutes, außer man tut es.”
Erich Kaestner

Go ahead, write up a KAPC 0.1 and stuff will develop from there.
:wink:

Something to start with and base your efforts on (as a lot of grey-matter has mulled over this already, repeatedly):


#3

Any library system is going to have to make a balance between:

  1. Library completeness (electronic bits have large variation) vs ease of use
  2. High standard vs ease of contribution
  3. Pleasing no one or displeasing everyone

Many companies enact their own library management system and/or standards.

I say this not to dissuade your efforts, but as an overview of what we struggle with to build the current libraries.

An ongoing project that will (hopefully) be completed by v5 involves:

  1. Overhaul organisation of the schematic libs. This involves improving general quality but more importantly bringing sanity to the library structure.
  2. Overhaul of the footprint libs (see above)
  3. New 3D models! Huge amount of work already been done on this, thanks to some great Python scripts that have been developed.

On top of these, I think having a landing page for the libraries is important. Directing users to a GitHub page can be confronting. A good looking and easy to use website for downloading and contributing to the libraries would be a huge asset.

There is a place for atomic parts within the KiCad libraries but it needs to be considered.

  1. Increased library size
  2. What field names to decide on?
  3. What do you do when a company or P/N changes?
  4. Risk of becoming too specific to a particular need and thus not useful in the general case.
  5. etc

The (official) KiCad libraries are slowly becoming a really good asset. The ability for users to contribute back (and some individuals have made absolutely enormous contributions) is one of its strengths.

We need to find a way to capitalise on the library set we have, I think. The non-atomic and somewhat-atomic part setup is very handy for a lot of users. I’d like to see a good way to also include atomic parts to the libraries without disrupting what we already have.


#4

Why not start an official KiCad Atomic library?

Well, we get a lot of questions, “why not x?” and before even getting into the details I have some general conclusions.

There are two main reasons why ideas don’t turn into reality, even if they are widely regarded as a Good Thing

  1. It’s hard to get people to agree on how it should be done https://philosophynow.org/issues/107/Why_We_Cant_Agree. I’ve noticed that a group of peers can be paralyzed by even a simple task, such as deciding where to have dinner. It seems that it requires leaders to make decisions, and that we have evolved as leader and followers https://en.wikipedia.org/wiki/Evolutionary_leadership_theory

  2. Many people are willing to be users but very few are active contributors. This has been described as the “1% rule” https://en.wikipedia.org/wiki/1%_rule_(Internet_culture)

At his point you might thinking “what has that hogwash got to do with anything”, but actually 80% of the task will be struggling with those two issues. If you can figure out how to avoid them, then you will get much further. For example, don’t try to build a consensus on the spec,. create one and say “here is the spec”. Find a leader, and follow them, or be a leader, and lead by example. Try to find ways for people to contribute with very little effort, or find ways to reward them for participating.

tldr; go ahead and do it, but don’t expect much help.


#5

If we move all parts to generic libs, then does that free up manufacturer names libs for atomic parts?

That could be a real problem, I found that with very large numbers of components loaded (e.g 100,000) KiCad becomes unusable. I’m not sure where the practical limit is.

I think that we have no choice but to change the parts every time that happens. Ideally, we would retain the old version for compatibility, but there is no built-in support for versioning, and we would end up with a lot of “dead” parts.

An atomic part is probably just a generic component plus an MPN and a few other fields, so I would script the generation of AP anyway. A simple spreadsheet would contain the MPN etc, and then the names of the generic component,footprint and 3d model.

I wrote a tool to create atomic parts from Digikey web pages, it didn’t seem to generate much interest.


#6

I’ll look into it once I redo my libs one more time… but not in the next 3 months :wink:


#7

Could you specify what you mean by atomic part?

As far as i understand the concept for atomic parts, the official lib is already marching towards this direction. Only one or two libs will hold truly generic symbols (the current device and connector libs), some libs like regul lib will hold semi atomic parts and all other libs will house atomic parts only.

Under atomic part i understand a part that is named via the manufacturer part number and has a footprint pre defined. (With footprint filters that allow the user to select slight variations of the footprint example for handsoldering or with thermal vias.)

A semi atomic part is one that is specified by the base mpn because different manufacturers produce this part. (base mpn is the same for all manufacturers, options like package are different.)

I think this comment by evan summarizes well what the future will bring.

Is there a specific set of rules that you do not like? (Just out of curiosity. I do not intent to start a flame war here.)
As @SchrodingersGat and @bobc already mentioned each set of rules is a compromise. There will never be full agreement within a given comunity. I think the current KLC is well thought out. (A few things could be more specific but we are working hard to make the KLC even better. At least i think this is what we are doing.)

I am also a bit confused by this question by you. Because you are the one person who always wants to decrease the lib size.


KiCad KLC Deviations
#8

Maybe I wasn’t 100% clear.
I do not mind however big the library ends up getting.
I do mind having to download library items again, and every time, there is a sub-version; especially for items that I/most people will never use.

This wasn’t so much an issue when the download was 300MB. The .exe is now approaching 1GB, it is becoming an bigger deal.


#9

There is zero reason for this to be a show stopping issue.
Digikey, Mouser, and Newark ALL have “their part number”, “manufacture p/n”, “manufacture”, and “description”.

The “KiCad House Number” should comprise of the variables that affect the actual purchase of the parts. This would include “package/case/footprint”, and order-packaging (tape, tube, tray).

There should be a “Basic Name” field. The schematic does not need to have the text “ICM7555IBAZ-T” when “555” will suffice.

There should be a “value” field for parts like resistors that have a value.

If I have forgotten something, let me know.


#10

You answered my unimportant remark about lib size but ignored the request to specify your understanding of atomic and how it deviates from my understanding of it. (I really would like to learn what the difference in understanding is.)


#11

My definition is that an atomic part is one which has a symbol and a footprint (and one assumes that the footprint carries with it a 3D model, but that’s not important). The atomic part includes a Part Number or some other identifier. This Part Number could be a complete manufacturer’s part number (which necessarily encodes package type), or it could be a “house” or “company” part number, which is used as a key in a database which will ultimately point to an orderable manufacturer’s part number.


The name of the atomic part in a library is generally the full manufacturer’s part number. This is important, as OPA551UA and OPA551PA are two unique devices. They differ in package, so substitution (in the sense that you want to put them on a PCB) is impossible. (I know there are those who say, “but I want to defer the choice of package until I’m in layout.” I am not interested in that argument, as it complicates the design, and generally when I am choosing parts I work with the buyer to know what I can get and at what price. That consideration is more important than package per se.)

For ICs and many types of parts, the Value field is unimportant, and is usually identical to the name of the part in the library.

The spanner in the works is what to do about common passives, such as resistors. The brute force choice is to have one library entry per resistor value/package/tolerance. This can lead to very large libraries, but the library creation itself can be automated. Other ways of handling this include using the Value field and the Part Number field together, and have a post-processing script build the manufacturer part number from the two. Panasonic resistors, for example, have a very rational part-numbering scheme, so the mapping is not onerous.

Electrolytic capacitors? Good frickin’ luck. :slight_smile:

I realize that I am repeating myself.


#12

Didn’t mean for it to come across that way. Both @SchrodingersGat and @bobc addressed some of the issues earlier in the post.
I have not fully solidified the concept in my own mind to make a quality comparison.

The basic concept is that one part number should have the symbol, the footprint, and the 3D model all defined with one KiCad alpha/numeric number.


#13

I think that more efficient would be to start a webpage where people could easily share their libraries. Maybe instead of writing rules, negotiating conventions, arguing what the kicad official way should be, users would start sharing their libraries.
One user is typically one set of rules. You like - you download. You don’t like - you look for some contributor who does it the way you like.
If system of user ratings would exist there, then probably there will be few top results (greatest contributors) which would be reasonably satisfying for most of users. Some of the libraries would be atomic (maybe could be described with some specific, searchable tag).
This is what I would do if I had time and skills to setup and promote such page :wink:


#14

This is a great idea, except – it wouldn’t be the “Official Kicad Libraries Page.” That title carries with it an assumption of quality, that the symbols and footprints were vetted and are “known good.”

And now we’ve circled back to the original reason for official Kicad libraries …


#15

I agree with this.

It would make good sense to use the existing libraries.

All that is needed is one “KiCad part number” and the fields to tie everything together.


#16

And I read it - again. Your POV is still top notch + concise in regards to this. :nerd:


#17

KPN = “KiCad Part Number” is probably the most sane and sensible suggestion for the unique part identifier that I’ve read in all discussions about part numbering schemes and atomic libraries so far. Thanks!


#18

Why a kicad specific number? Who makes sure this number is unique over all symbols (over all libs)? What is wrong with using the manufacturer part number? (There the manufacturer makes sure it is unique)


#19

Manufacturers numbers change frequently.
Slightly more generic numbers get into complications when one user requires a specific qualification. This is why many companies use house numbers


#20

I understand the need for house numbers. But they are house numbers not generic numbers for an official library. (One can have multiple house numbers for the same part depending on where you buy the part.)

Also if a MPN changes the symbol needs updating anyway. No matter if you use the MPN as the main identifier or as a separate field.