Thanks for the comments… However I was not really talking about atomic entities but about a standard coherent methodology in the creation of a new, modifying an old, or copying an entity, be it a schematic symbol or a a footprint.
The present methodology is non conventional, not intuitive to me, and differs between a schematic entity and a footprint hence the standard flow chart I suggested…
As to having separate footprints to schematics I like it! I can craft my schematic representation to the job at hand, especially with processors where a design could need analogs to the left and outputs to the right.
As far as cvPCB is concerned I only use this to check that all items have an assigned footprint. A simple list would suffice for me
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.)
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.
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.
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.