Libraries and Components- The Disconnect

#21

Yes. Footprint filter.

But it think the reason why people make atomic resistor parts is because they have ordering information stored directly in the symbol (for bom)

I would however suggest to have house part numbers, that use a combination of the hpn field and the value to generate (via a script) the detailed hpn and from that the ordering information. (How should the designer know during the design process which resistor is best suited for the people in purchasing. As long as the electrical and mechanical requirements are met.)

The hpn can for example be: R_[size][value][tolerance] Then you can have the hpn field for resistors pre filled with R_0603_[%V1]_[%V2] and the script knows to split the value field in resistor value and tolerance.

The problem here might arise if the designer enters value, tolerance pairs that are not in the approved list. (Can not happen if the designer can only choose from a restricted set of fully specified parts.)

#22

@Rene_Poschl answers the question below.

First, Iā€™ll say that at one company, we had a resistor library that had an entry for each and every resistors. Of course, this was over 20 years ago, and we used DOS PCAD, and the library organization was driven by ERP needs.

At the day job now, we go with house part numbers and the concept of a component ā€œfamily.ā€ A ā€œfamilyā€ of parts are things that are obviously common (like resistors) but vary in exactly one parameter. So 0603 1% resistors are a ā€œfamilyā€ and the variable is the value. In our library we have things like RES_0603_1% and RES_0402_1% and RES_0603_0.1%. Each is a different family and each symbol has a Part Number field set to the family part number (created by our ERP system).

So you place a RES_0603_1% on your schematic and edit the Value field to a real resistor value. Do that for all resistors in the design. A BOM processing tool takes the BOM generated from the schematic and for things that have families it marries the family part number and the value and builds a proper part number for use by purchasing.

Others use a similar system, except that their BOM processor knows Panasonic or whomever part numbers and can build such from the resistor value.

This subject always comes up when discussing library organization. Itā€™s an old old problem, and nobodyā€™s solution is better than any other solution. It just depends on user needs. I can only advocate for what has worked for me. Your solution make work better for you. The good news is that Kicad supports different workflows and requirements.

#23

Well I just have to say I couldnā€™t agree with anything in the first post. Developers Kudoā€™s to you. I downloaded Kicad and produced my first PCB in 4 hours. Damn thing worked too. OK it wasnā€™t that complicated, it only had 100 components. I only had to make one component in the PCB foot print, which was actually in the library already, I just didnā€™t search well enough.

So I read all this stuff about the libraries, and discord and I say ā€œThe libraries are damn impressiveā€. Its is however great to see the aspirations to get things better.

Iā€™ve been building programs for 40 years now, and where does Kicad rateā€¦ Kicad is awesome. OK some parts I find a little clunky, but then Altium was also clunky in aspects, and so is Eagle. Maybe those 2 later ones are better now, but I donā€™t careā€¦ Kicad is awesome.

Having produced my first Python 2.7 GUI app Iā€™ll be joining the developers soon, I did look at some of the codeā€¦and my god where do you start.

My wish list would be to add simulation to the schematic, at least just the analog stuff, but for now truck on developers Kudoā€™s to you.

#24

Agree that is a very workable solution. I do something similar by using a BOM script to bring in all in the footprints and values - I then extract the parameters from my component directly - so I can then do a query for parts that meet my search criteria from my stock database. This is ideal for ā€˜jellybeanā€™ components. I can just place a R_0603 and set its value to say 4K7 1% and I can use the script to do a stock search with those parameters .As a one man band, I like the way that I can also tie this in with my stock management. In my case, I use PartKeepr for stock control - this runs on a mySQL database and has my ā€˜approvedā€™ parts and stock levels and can pull in part parameters and order numbers/pricing directly from Octopart.

The advantage with this sort of approach is that you donā€™t need to hard code an PN into a particular component and are therefore not tied to one specific product. The actual component choice can be done by matching the component spec to the parameters in the database - so you might have a choice of 4K7 resistors from Panasonic or Yageo or whoever.

The BOM report also identifies non-stock items which can easily be added and so provides basic MRP functionality too. This way you donā€™t need a specific Resistor or Cap library - you can simply place the component and defer the choice of the exact item from stock until later.

#25

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.

#26

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.

#27

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.

#28

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?

#29

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.

#30

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

#31

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ā€¦

#32

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.

#33

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.)

#34

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.

#35

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.

#36

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.

#37

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.

#38

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.

#39

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.

#40

As of yet there does not seem to be a python api for eeschema.
Which limits such things to external tools like KiCost.