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.
Maybe I’m slow but why not? KiCad librarians have no qualms about periodically deleting, renaming and generally messing with symbol and footprint libraries, so that if you are actually using native libraries straight up, you end up with all kinds of mess on your hands. And here we expect a third party library to be backward compatible? I just don’t see the advantages. Old designs will use the symbols and footprints from the local cache. New designs shouldn’t use obsolete components to begin with.
For those outlier cases - chances are whoever bought a bunch of parts in a the first place would have those symbols and footprints in the local library. Even if they would have to create a new one from scratch (I’ve been doing it for years because most of the time I couldn’t trust KiCad libraries) it is not worth it to create bloated libraries and introduce confusion about which parts are still available. On the positive, alternative approach can be advantageous: that nagging reminder in EEschema that a local symbol couldn’t be matched to the symbol in the library can serve a reminder when re-assessing an old design to address components that are obsolete.
Due to the varied nature of customers, I think it makes sense to keep the parts in the library for bit of time before complete removal. However, it should be made plainly clear that the part is not stocked and is not recommend for new designs.
I’d guess that most people would not mind having to download a few parts that have become recently obsolete. What I’d personally not like is to download a list of 100 parts where more then 50% of them are obsolete. At some point this becomes “bloat” and should be removed.
It looks like there is not 1 simple answer that will work for everyone. Some thought put into a mixed approach should keep the majority satisfied.
I think we’re going to aim for appending _obosolete or _nrnd or _nonstock to any applicable parts according to its status on DK’s website. If I can figure out a low overhead way of keeping track of obsolete dates, we may roll off parts into an obsolete lib after a certain time frame so the parts can live somewhere and not be completely lost to the annals of history.
I would say this is somewhere that a new feature could be added to KiCad. Have a ‘status’ field to allow parts to be active, deprecated or obsolete that would then clearly indicate to the user when selecting them (possibly with a yellow or red background or something, plus a clear non-colour warning) that the part may not be readily available. Then it would be easy for Diki-Key or other library maintainers to just change the one part field as a part progresses through its life cycle.
Of course, the danger is that people will assume that in the absence of a warning, the part is OK so anything that doesn’t get updated is going to annoy those who rely on it as their only source of information.
This would work for digikey but not for the official lib. A part can be obsolete when you look at one distributor but it can still be sold by others. (This might even be depended on where on this world you live. Maybe a new regulation means this part can not be sold to you but can be sold to someone in china.)
And such a field does not need new features. You can add any field to your symbol you want. You can also use the description field for this. (Add a tag at the beginning of it for example)
A part is obsolete when the manufacturer declares it so, and all official distributors should be notified of that so in theory if KiCad was getting libraries from multiple distributors who maintained them in a timely manner, you’d expect them all to mark the same part obsolete pretty quickly. Then you’re just buying the remaining stock, and some distributors will sell out before others. You can also have ‘discontinued’, where the part is still being made but a particular distributor no longer stocks it, which is what I think you’re talking about.
The other side of this is sometimes what happens with NAND flash memory (as an example), where a part is obsolete but there’s a direct replacement, often when the manufacturer updates a process or on-board firmware and so technically has changed the part. This makes the old part number obsolete and a new one is assigned, which may only be one digit different from the previous part. For most people they won’t care about such minor things because it’s unlikely to make a difference, but for someone in volume production they’d want to get samples of the new part and test them before committing to a large production build even if they fully expect it to make no difference.
