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.
Any library system is going to have to make a balance between:
Library completeness (electronic bits have large variation) vs ease of use
High standard vs ease of contribution
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:
Overhaul organisation of the schematic libs. This involves improving general quality but more importantly bringing sanity to the library structure.
Overhaul of the footprint libs (see above)
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.
Increased library size
What field names to decide on?
What do you do when a company or P/N changes?
Risk of becoming too specific to a particular need and thus not useful in the general case.
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.
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.
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.
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.
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.
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.
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.)
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.
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
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!
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)
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
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.
So, since I started this thread, I was going to offer the following. However, I realized I wanted to think it through a little better. But, then, several seem to have caught-on to where I was mentally headed. Here it is:
How about this for a start?
Like the device suppliers I mention, create a unique intelligent “house” part-number for KiCad (KPN).
This is just the “part number”:
Ref Designator - (Value/Simple Part Number) - Mounting Type - Footprint - *Optional MPN
R_10K_SM_1206
U_555_TH_DIP-8_W7.62
Concentrating on the IC first. This KPN would basically just be a “data holder”. The actual symbol and the actual footprint would remain where they are now. The Texas Instruments NE555P and LM555CN Fairchild/ON Semiconductor can both use the same symbol and same footprint.
For example:
U_555_TH_DIP-8_W7.62_NE555P
U_555_TH_DIP-8_W7.62_LM555CN
With intelligent part number creation, the symbol and footprint are specified in the name itself. The MPN in the KPN would be the orderable device number.
Contained inside the “KPN” would be several fields. For example from the TI 555 datasheet:
Order-able Device
Status
Package Type Package
Drawing
Qty
Eco Plan
Lead/Ball Finish
MSL Peak Temp
Op Temp (°C) Device Marking
Hope this gets some thoughts generated to help make this happen.
I think you meant that one house number may have different MPNs. Certainly it could be done that way. The simple fix for this is not allow it for the KPN library. Each library entry must be it’s own unique entry.
