The goal of the digikey-kicad-library library is to offer a collection of well defined parts that include assigned footprints. This meant to augment KiCad’s default library and give users another choice in library paradigm (meaning that it is One Solution, not The Solution). It contains 1-to-1 symbol to footprint assignments to meet the needs of those who prefer that style. It does not currently include the idea of a one symbol to many footprints primarily because that defeats the purpose of having an orderable part number ready in the Bill of Materials.
I cloned their repo and counted the number of parts in each library. While there isn’t a lot of stuff in each category, it is a nice start. Kudos to Digikey!
1 to 1 symbol to footprint assignments will facilitate library management especially to newbies like me. This is a good ONE SOLUTION, not THE SOLUTION. Digikey, thanks.
Mbeh
Not only that, it appears that they chose the same license, and the same license exception, that the KiCad libraries will be using. So I would think that would make it possible to use symbols and footprints from the Digi-Key library as a basis for symbols and footprints in the KiCad libraries and vice-versa. Awesome!
Another good thing about the Digi-Key library is the extensive information included with each part: 11 fields versus the 4 standard fields of most parts. They also include an MPN field so all the parts work with KiCost (I know that is mostly of interest to me).
Thanks for the attention guys. We’ve been poking at this project for a while. This is truly a ground up effort from several Digi-Key technicians and engineers; an “oh, wouldn’t it be cool if this existed” idea. Please give some grace, it is not complete, there are many things to fix and ideas to hash out. We welcome any feedback and want to make sure we can have a baseline set of parts that people can have some level of trust in (always check for yourself!). You’ll see some blog posts in the future about how we went about creating this and what some of the underlying principles are.
This is another excellent news with Digi-Key in its headline! I simply wanted to express my gratitude for you and other Digi-Key people for the support we receive. We are happy to see big companies contributing to open source projects, and obviously KiCad is the closest to our hearts, so your efforts bring particular delight. I believe the new library will be a great help to the users. Thank you very much!
We started with the previous version of the KLC and ended up deviating as it made sense (and sometimes when it didn’t). It sure would have been nice if Oliver and the librarians’ awesome KLC 3 would have been out when we started, but we will revise and improve what we have for consistency. The footprint naming needs quite a bit of work, but it’ll eventually be more consistent with the KLC standards where it makes sense.
For those of us who are REALLY newbies (and thoroughly confused by KiCad’s library structure), is there a tutorial or instructions for installing these libraries into KiCad ? I am retired and working on IOT devices around my home is my hobby, and KiCad makes my designs a lot easier to understand and build. many of the parts I use come from Digi-Key. I am finding the KiCad library structure so confusing that I find it easier to re-create my unique parts when I start a new project. I wish there was a way to create the part and footprint once.
Eschema and PCB were separate programs that were merged. Knowing this helps to partially understand the structure. It is being reworked for the next version release.
Generally Kicad loads a default set, but not all, libraries. On a slow computer loading all can take a little time so that’s why the default behavior is not to load everything. This can make you believe ‘stock’ parts are missing when they simply haven’t been loaded. Look at your library paths in Eschema to find out where they are located. Open a few. They are text files. When you create a new part you generally want to make a new lib in your name space for it. Before saving new parts you have to set your private library as ‘current’. You also have to make sure it is in the list of libraries that are loaded.
The PCBnew stuff will be separate but the same principles apply. I have no idea how much this changes when version 5 comes out. That draws closer.
The good thing about text files is that in the beginning I was creating a new lib for every new part because I was offered the choice. I went back and was able to do cut and paste and make one file out of it.
Also, keep in mind English is not the native language for developers so things that seem to have what you might consider an inappropriate name made sense to someone.
It may be quirky but it really isn’t hard once you see what is going on and have done it a few times, but yeah, it is far from intuitive out of the box.
I’m trying to gather some community opinions here. I posted a github issue here that covers the topic.
Does anyone want to weigh in on how we should handle items that go obsolete? I don’t really think they should be deleted completely, but should they be moved, segmented or named differently? How should this be handled?
I agree that they shouldn’t be deleted. Your purpose as a distributer is a little different and we need to respect that. People sensitive to bloat would be appreciative of the fact they aren’t forced to download and store stuff they can never use though. I think your target audience would say segment. This way it could also be a warning to a user on something that might have just recently gone obsolete, provided they keep their libs up to date. Sad to say you need to think about ‘blame’ too.
So far I have heard a few options between here and discussions elsewhere.
Pull Non-Active parts out and place in one big monolithic library without any extra categorization. This would end up in the current organization as dk_obosolete.lib
Pull parts from the current library set and put an the entire taxonomy in a separate folder with a shadow taxonomy includes a each family library of obsolete parts. ex there would be both dk_Encoders.lib and dk_obsolete_Encoders.lib .
If there was a preference for keeping all parts in one major set of libs and one taxonomy, how about prefixing symbol name with something like o_ (or z_ so it ends up at the bottom or nrnd_, or any other suggestion) so we have individual part numbers listed as o_CN2240. Sounds a bit obscure, but quite workable. It saves hunting in multiple places.
Indeed, this is already there and is continually updated on each lib push/update.
I’ve written scripts to segment and organize libraries in pretty much any manner we’d need so the overhead with any option is pretty low. It’d be really nice if there was more hierarchy available for lib management, but alas, users are a bit stuck for the moment.
Yup, there’s no delusions there. We just though it’d be nice to offer an atomic list to the segment of the population who’d find it useful.
[quote=“hermit, post:16, topic:8520”]
provided they keep their libs up to date
[/quote] Ain’t that the truth.
Any idea how widespread the library adoption is at this point? I don’t know much about the inner workings of github but I’m guessing there’s now good way to use it to get the actual users input?
When I ran my own small business I made heavy use of the catalogue feature of Altium Designer (10.x and then 11.x). The catalogue that satisfied my component need best was Farnell’s. Although I could have saved some money sourcing components elsewhere, the amount of work that it saved me outweighed the higher prices.
I think this is also valid for small businesses that use KiCad as EDA package. I don’t know how dedicated Digikey is to this project, but maybe there’s manpower for creating an script/extension for KiCad that checks the availability of the placed parts via your API.
[quote=“bombledmonk, post:18, topic:8520”]
Pull Non-Active parts out and place in one big monolithic library without any extra categorization. This would end up in the current organization as dk_obosolete.libv[/quote]
My 2 cents: Bad idea.
[quote=“bombledmonk, post:18, topic:8520”]
2. Pull parts from the current library set and put an the entire taxonomy in a separate folder with a shadow taxonomy includes a each family library of obsolete parts. ex there would be both dk_Encoders.lib and dk_obsolete_Encoders.lib .[/quote]
If oyu choose that road, think about adding ‘_obsolete’ at the end. This way alphabetic sorting works better and users see it immediately. Else there will be a big block of obsolete libs in the list and all other from ‘P’ to ‘Z’ after that.
Maybe introduce a regime to toss out parts 2 years after they became obsolte or something like that. It won’t stop bloat but at least set a limit.
