Libraries and Components- The Disconnect

You are probably correct about some people wanting an ERP system for use with KiCad. I didn’t know if your reply was to me or not but in any case I did not take it personally, I just tried to make it clearer that I was only talking about interfacing with existing database/ERP systems.

I was thinking about a little less integration than that. My thoughts were that KiCad would continue to load libraries as it does, only the component chooser would be populated with parts from a database. Once you selected that part the plugin would use data from the database to load the appropriate symbol from the library and assign the appropriate footprint to that symbol, as well as any other fields the plugin read from the database (ie. value, tolerance, wattage, voltage …). Instead of selecting the default component chooser you could select the plugin which could present it’s own chooser dialog.

Anyway, those were just my thoughts, none of which is going to be possible until ESchema supports Python plugins. However, after giving it a bit more thought at the gym tonight, and borrowing from what you said earlier, perhaps a more doable approach would be to create an external tool that would read a database and build the symbol library accordingly.

I think I agree that Python support in eeschema would be a basic first step, and maybe sufficient. The pcbnew scripting has been really useful and I think the ActionPlugin will be another good step forward.

I know Python for eeschema has been talked about informally, but it doesn’t appear to be on KiCad roadmap (either v5 or v6). There have been some grumbles about the SWIG approach, it may not be perfect but I find it gets the job done.

There is a programming concept called the “Unix Philosophy” that says to keep all programs simple. Each program should do one thing and do it well. You build complex solutions by linking together simple tools. The other way is to make your tool do all things for all users. You add features that are far from the core objective and it becomes bloated and hard to manage. Kicad is heading down this path. You should think about adding new features by adding a new tool rather than shoehorning into an existing one.

Eeschema should be stripped down into eeschemaLite with design management and hierarchy done in a separate new tool.

Selecting a part is a multistep process. One designer places a Nand gate. Another on packages 4 of them into a component. Another selects logic family,speed and temp range. Still another picks thru hole or surface mount. You want to support uplifting whats on the schematic rather than having to delete and replace with a new component.

John Eaton

Yes, that is the problem.

What I’d like to ultimately see is a way for KiCAD to access a database (SQL preferred) that could have many many components in it that ties vendor and distributor information to local schematic parts, symbols, and in-house part numbers. Then when parts are placed into a design 1.) all the vendor and distributor information is copied locally and is static, or 2.) some information is placed into the design and then BOM generation and other tools pull the information dynamically from the database (preferred).

Right now, if you wanted 1-to-1 mapping of placed parts in a design to order-able parts, your schematic library begins to balloon. Let’s take resistors for example. Right now on Digi-Key there are 860,049 different order-able parts. With a schematic library of maybe 20 parts and a maybe 200 footprints you could get near 100% coverage (while the database handles all the linkages).

1 Like

I like the process, I am just wondering in this scenario who creates the database?

And maintains it.
I have been updating a BOM from 8 years ago that referenced RS and Element14 part numbers.
Nearly all of them are still stocked, but the reference has changed. Fortunately intern hourly cost is low.

Database creation and maintenance would be left to users, much as library and land pattern creation is. Many medium and large companies have dedicated maintainers.

I think you would ultimately see people in the community step up and and maintain and create the database. Much of the work can be done via scripting and DigiKey scraping.

I find that highly unlikely, since the official libs contain barely 5400 symbols and it is a struggle to maintain those, even with some scripting and community support.

If users create their own databases, there are dozens they could choose from, so KiCad might need dozens of interfaces. The database schema would need to be compatible with KiCad also.

I still think the practical way forward is for all part maintenance to be done outside of KiCad, and a custom set of libraries is created by each user for their own needs. Tools like KiField are already part way along that path.

2 Likes

Big companies with their own house numbering systems have substantial component standards departments to maintain their databases. The coverage of these house number databases is at least an order of magnitude lower than RS or Digikey, as they only recognize parts already used in their own products. Expecting that volunteers will be able to do more than that is wishful thinking

2 Likes

Crowdsourcing is a great idea; in practice it most often means that crowds try to find a source to satisfy them.

This would do nicely for me. I can use plug-ins for everything except schematic input at the moment, so an interface that calls a plug-in and then parses the standard output from that plug-in as the part definition then I’m sure I could make it work. A bit of python to query a database and print a bit of formatted output would give me what I need. Then I could tie it in with the BOM plug-in and be able to build a good part database management system.

I tried it :slight_smile: A quick script to parse the database and create a KiCad lib. It has severe limitations though, not least that the value field has to be unique as it pulls in from the library. So you can’t have a 1K 0402, 0603, 0805 and 1206 resistor all just having a 1K value. The current mechanism pulls in a generic resistor and then you edit the value afterwards. There needs to be a separate unique part identified that is not the value field.

The hooks are missing, I can’t do what I want with what’s available.

The other downside is that there are various different incompatible approaches to a problem out there, just look at all the variants that people have thrown together to do BOM management. This is not necessarily a bad thing, but it means you have to find the one you want and stick to it.