I have a view that is different to some. I’d like to be able to use a database for parts. I appreciate that this is somewhat more advanced than most people require, but having used OrCAD and Altium with such features I’d like it. Plus I’d be able to use existing stuff I have here with minimal extra effort.
To me, when I place a resistor, I’d like to be able to do it all in one operation, so I’d go to my 0603 resistor database and pull out a 10k resistor, which would be pulled in with all relevant fields already assigned. I did have a go at writing a script to generate a Kicad library from the database and this worked fairly well except for the fact that Kicad uses the Value field as a primary index key, so I can’t have a pre-defined 10k 0603 1% resistor and a 10k 0402 1% resistor without messing with the Value field to make each one unique. At the moment I have such things as 100R_0603_1, which distinguishes it from 100R_0603_5 and 100R_0402_1, but that makes other parts of the system look less good.
It would be nice to have a plug-in mechanism for placing schematic components so that I could write a fancy bit of Python to return a text block on its standard output with the DEF -> ENDDEF as the equivalent of a library part. That way I could abstract the symbol graphic and the part data fields as I see fit so I could keep a separate list of symbols and reference those from the database to avoid needing several thousand identical resistor graphics.
I have been creating parts with an extra unique field that I plan to use for BOM generation with a Python script to look up in the database to retrieve manufacturer information and order codes - this means I don’t have to care too much about my resistors, assigning my part code to a manufacturer/vendor comes later than the initial schematic capture and if I have to change, I don’t need to update any of the the schematics.
IMO this is the correct approach. Having a symbol library and footprint library and a database that connects these to “real” parts. There is plenty of free database software available, I use Oracle Express. The database can hold more than just “parts”, allowing simple SQL queries to be used to generate BOMs etc. And it doesn’t need to be that tightly integrated into Kicad, most of the functionality already exists.
That’s how I do it - OrCAD allows a relational database so I can have a set of part tables which contain stuff relevant to the schematic/layout such as defining which schematic symbol and which PCB footprint to use, and then do a lookup in the vendor table when it comes to generating the BOM with manufacturer/supplier codes. It also means that if you’re using internal company part numbers, you can let the procurement department maintain the vendor table without affecting anything on the schematic.
Altium doesn’t do the relational bit (or I haven’t figured it out if it is capable) so you end up with all the vendor information in the same tables as the design information.
KiCad could do the relational bit easily with a python plug-in for the BOM, what it’s missing is the up-front database selection mechanism when placing parts on the schematic.
I third this approach. Many professional EDA tools (OrCAD CIS/CIP, Altium) utilize a parts database that marries a schematic symbol and a PCB land pattern to a physical part. This, among a few other things, is really what separates KiCAD from more serious EDA tools.
Let’s take SMD resistors for examples. To have a 1 to 1 relationship between a placed resistor in a design and a specific order-able part there needs to be potentially 1,000s of resistors in your resistor library with the majority of the information being identical (the symbol geometry). With a database you can have one symbol and a bunch of DB entries for the same thing. You can even then write scripts to scrub Digi-Key to update information on parts!
I’ve seriously considered trying to implement something like this in KiCAD scripting, but haven’t actually looked into it much (but now I am really considering it). Does anyone know if this is possible?
I’d be happy with just an implementation of the supplier links tool for parts in the schematic similiar to what Altium used to do. This would allow a user to do a search through a common interface to look up the part number and link to each of the major suppliers(Digikey, Mouser, Element14, etc) or possibly just directly link to part aggregators like Octopart and let them manage the back end database. Granted this would not be perfect for large organisations and their custom systems.
As KiCad users are in many countries with different local distributors, there is no way KiCad can just do this for you.
There is nothing stopping you doing your own private atomic system
I’m not asking just for me. Having it connect to the largest global distributors would be a good way moving forward to ease use for the majority of users. And if it was an open well documented method to get access to the back-end DBs then local distributors could develop their own.
I really don’t understand the resistance to making things easier for users to vertically integrate systems…
I wrote some code to scrape Digikey and create KiCad libraries, but it is not very practical if there are 1000’s of parts. KiCad performance falls off a cliff, and then becomes unusable. There would need to be some serious performance improvements in KiCad to make it useful.
Preselecting parts to create KiCad smaller, custom libraries would be doable.
Not really sure i fully understand what the feature request here is. But there is KiCost which provides an interface to several distributors. https://github.com/xesscorp/KiCost
It takes a BOM and helps the user to decide what to buy. (I never used it my self. I have my own “database” that interfaces kicad via a house part number field.)
I think the problem is that people overestimate how much developer resources are available to KiCad, and greatly underestimate how much effort goes into developing a user friendly, globally supported, vertically integrated system like you propose.
Searching and selecting parts is easily handled by google and supplier web interfaces, it would be massively redundant to implement all of that in KiCad. OTOH, there are many features specific to PCB design that are impossible to provide via external tools, which would really improve KiCad. Therefore, it is felt KiCad devs should concentrate on core features.
What I would like to see in KiCad is a “plugin API” for parts databases, so that external tools could be used to manage the parts. That would not be trivial either, but would provide a way forward without taking up too much developer resource.
Yes the limited resources are best spent on core functions of improving KiCad. But I totally agree that developing open APIs to make interfacing easier for external tools that may over time be added to the featureset of KiCad.
This may even decrease the developer burden as external tools can be managed seperately, and in the case of commercial entities like distributors, they can fund access to their own libraries in a better manner.
Not easy to define that list. Digikey are big in the USA, but barely present in Asia. Alibaba is a big player in China, but almost invisible in the USA.
Even companies with fairly global reach like Element14 vary their business rules by country, refusing to deal with hobbyists in some.
I’d be very interested to see a poll as to who the major suppliers for trusted(ie non-grey market) electronic components are for the users of KiCad. That would then let us know exactly which distributors would be useful to aim for better integration.
It shouldn’t matter which distributors people use, if KiCad were to implement such a feature then it should be configurable, exposing the API so that vendor specific plugins could do the work.
I think this topic has digressed from the suggestion above of using a database. I don’t know what APIs V5 will expose to Python scripts but it would be nice if, when adding a component to a schematic, the list of available symbols (and footprints) were obtained from a database rather than from the libraries. This would allow KiCad to be used as is, or integrated with your favorite database or ERP system without placing any additional burden on KiCad developers or Library maintainers.
This is just my opinion and open for comment but not intended to be a feature request as such.
Companies I’ve worked for use “trade” distributors like Arrow, Avnet and a bunch of others most people have never heard of. Larger companies go further up the distribution chain up to the manufacturer themselves.
The design engineers select parts and specify alternatives, but it is up to the Purchasing department which variant they buy, and who from. They do not use the CAD tool that the designers use. In fact there is a completely separate software package that Operations use for ERP that integrates purchasing, stock control, production, sales orders etc such as SAP.
Component data is kept in a separate database, which has additional info relevant to designers, but is linked by “house” part number to the main ERP database, and kept in sync. Data from that database is then extracted to create libraries for our CAD tools (schematic, layout, MCAD). The CAD tools used by the engineers are just a cog in a big machine.
Obviously we have an IT department and other “programmer/engineers” who maintain the databases and bespoke scripts.
All the above can and is implemented outside the CAD tool. Therefore in principle, KiCad already has the features needed. All it needs on the user side is some method of generating libraries for KiCad, which is dependent on the local requirements which really only the user can implement. It’s not practical for KiCad to contain interfaces to every type of ERP tool and every electronics distributor.
I think what people are really looking for is a free ERP tool, that can be adapted for use with KiCad.
Yes, where possible we deal directly with the manufacturer or one of their reps, otherwise we use a distributor. It usually doesn’t do us much good to scrape websites as that is seldom the price we pay anyway.
Quite the contrary, I was only suggesting being able to use a plugin with ESchema to allow the user to implement, or interface to, the database or ERP system of their choice. As you say, much of this can already be done with external tools, and generating libraries is certainly one way. My suggestion was simply to facilitate a minimal integration between the CAD and ERP systems. This requires nothing more from KiCad than Python scripting support, which I thought was planned for V5, if not then this discussion is rather moot anyway.
The thing about an integration API is that it would affect a lot of KiCad code at a core level, ie component chooser,netlist gen,symbol editor,cvpcb,edit footprint assignment,read netlist,place module. Currently KiCad reads all libs into a memory cache, that would not scale well to very large databases. There need to be some fairly major internal architectural changes before a clean API could be implemented.
KiCad does have a “plugin” architecture for reading symbol and footprints libs, but these are internal to KiCad and not accessible by users. These plugins are called on a one-off basis when the internal cache is built. However, it should be possible to create a generic plugin that reads from a database instead of a text file. The model here is that the github plugin actually downloads a zip via the web.
The scripting support in v5 is limited to pcbnew, basically a script can access all elements on a board, but that doesn’t give access to symbol or footprint libraries (AFAIK, I might be wrong). Of course a script either run inside or outside KiCad can access external text files, but there lacks a method for a script (or the user) to tell KiCad “the external files have changed, please re-read them”.
For all these reasons, I try to gently steer people away from the expectation that KiCad should (or will) have a built in database functions or direct links to supplier websites. Obviously I don’t speak for KiCad devs in any way, or even always agree with what they decide, but I have been watching them for a few years and have a little knowledge of the codebase. I can generally predict what they will say regarding new features.
I came across this project recently https://github.com/turdusmerula/kipartman/issues/18 - kipartman - which I guess has some of the bones of what several contributors have in mind. I have not been able to get it to run and there are some limitations apparent but I think the concept is quite interesting.
With a python API to eeschema this would all be a great deal easier and would facilitate a variety of options for linking in to external part databases.
