Ok, We have symbol library, footprints, 3D, and each symbol in schematics could be fullfilled of a lot of useful information, for example just add some fields like manifacturer number and a link were to buy and you can Export a great bom from schematics.
But wat if I have a tool that helps me to fulfill all this stuff easily? I was thinking about a sort of database, a place where I can search for commercial components when I’am designin my schematics for example I type 47k resistor SMD 1% and I get some results, i select one of them for example this code: AC0603FR-1047KL and I get all the fields I want for the resistor filled in the right way. I can do this while designing the schematics, not just later using other tool.
Something magic would be a plugin that take this stuff directly from supplier site using web api to get data that will be copied (on fly while running the BOM tool or when asked from its interface) and linked to the component.
This also can avoid some mistakes like selecting a wrong footprint for given components, for example a 10uF MLCC capacitor that would exist only in cases 1210 or bigger if I need 100V or more!
AFAIK there are BOM-scripts that already scan websites like digikey/farnell/mouser to estimate the price of a design. So figuring out the web-API has mostly been done I think.
Then there’s partkeepr where you can locally host a database of parts https://partkeepr.org/
not sure how you would create links between the vendor part numbers (digikey/farnell/mouser) and who would maintain that database? Does the “True components library” really save so much time/money that it is worth the time/cost of maintaining a (large) cross-ref database?
As every large electronics company has its own proprietary numbering and purchasing system, there is no single solution to this and each company would have to maintain its own database
I think it is not good to mix design process with order optimisation process.
I think the design process should end with specification like 47k 0603 1% and not the exact order code.
When that PCB is to be assembled then someone else can do the job of selecting the order codes.
I’m sure that at least some order codes of elements for PCBs I have designed in 2004 and are still in production are now different than those time.
Isn’t this part of the problem already solved by Octopart? It seems that all that’s needed is a database that links Octopart UIDs with KiCad symbol and footprint names.
It also seems that DigiKey is making some attempt to add their part / order numbers to some KiCad libraries, but that just looks like noise to me. I don’t want to depend on a single manufacturer.
I’m not sure, but I think that at least one of KiCad’s BOM Tools (online?) is capable of making overviews and order forms from parts of different parts vendors, and where you can select a vendor for a particular part with your mouse in a spreadsheet.
Also: Manufacturers go bust, parts get obsolete and replaced by other parts.
I’m with Piotr. I do not want such information in my schematic, and it sort of is already in Eeschema anyway.
It will also explode the library size, just multiply the amount of resistor values with the amount of resistor sizes times the number of resistor sellers, and you want to add them all into the database?
I do not use KiCad much (but I love it). Just today I’ve been playin’ for the first time a bit with the spreadsheet from:
Eeschema / Tools / Edit Symbol Fields…
I like it very much. You have an overview of all schematic symbols and their meta data. Clicking on the first column pans the schematic to show that symbol and there are various ways to group components, and then edit a metadata field of multiple parts in a single line. For example:
You can easily make a group of all green leds, and change them to RED leds.
You can make a group out of 4k7 resistors and change those (and only those) to 6k8.
You can change all 0603 SMD resistors and change them to THT, by editing a single line.
This spreadsheet is clearly not finished yet. It seems to have the ambition / intention to eventually replace CvPcb.
If you add a custom field to one of the components in your schematic, then this column is added to the “Edit symbol Fields” spreadsheet and is easily edited / manipulated for all other symbols also.
@RobertoP ,what you are proposing is an IT system linking Purchasing, Inventory Control, and Requirements Planning as well as Design Engineering. Companies with more than a few dozen employees have such systems, in one form or another. (Smaller organizations try to squeeze by with spreadsheet programs, general-purpose business database programs, or various types of basic accounting software. Does anybody still use boxes of 3x5 cards?) I have worked for, or with, over a dozen such organizations and no two such systems were identical. Some seemed to operate more smoothly than others but I was never fully satisfied with any of them. Sometimes the affected functions - Purchasing, Inventory Control, Manufacturing, and Design - were well-integrated; usually there was some clunky disconnect between at least two of the functions. The programs were always complex and expensive.
Please do not attempt to morph KiCAD into a tool with a different purpose. The effort will probably consume time and resources better devoted to other efforts. I fear it would be like a warrior who comes to a blacksmith, asking the metalworker to beat his sword into a plowshare. The resulting device is neither an effective weapon nor an efficient agricultural tool.
I try this tool yesterday on Windows, I still haven’t got any success yet. It require so many python module to install, then still I can’t get it run right with my weird working environment yet (cygwin). May try it another time, or learn Octpart API and script some thing up when I got a change. For now, I going to get the job done with digikey, and manual pick them
Octopart is now owned by Altium, I believe. Although it is currently free to use, that may not always be so - you need to be careful about tying functionality to this or any other external provider. Octopart recently unilaterally revoked one of my APIKeys and failed to respond to my emails. I have also found occasional errors in the Octopart dataset - none critical but nevertheless potentially problematic. However, if you don’t rely on an external agency, maintaining a comprehensive and up to date dataset would be an impossible task in a free project like Kicad.
The ability to manage a user library would, in my mind, be easier if, as well as selecting from the current flat file system, Kicad also supported placing components from a ‘proper’ database - i.e via some sort of interface to an SQL table. The present arrangement of a ‘bunch of files’ does make it more tricky to organise your own library of components. You need a good ontological structure for your personal libraries if you are going to be able to organise and find stuff efficiently using this sort of structure and reorganising it is bit of a performance - you can see how the official Kicad libraries have added more library folders and moved, for instance various sensors into more specific directories. Perhaps this aspect of organising personal libraries is also made worse because there are few good graphical tools to actually move components/symbols around easily. (Kicad Librarian only runs under emulation on macOS).
As @Anders_Wallin notes, you can use something like PartKeepr for your own components I have a small tool that integrates with PartKeepr (which also pulls in data from Octopart) and manages my BOM runs - https://github.com/Gasman2014/KC2PK. I have a selection of ‘approved’ house parts which don’t get on the database until they are validated - similar to the scenario that @davidsrsb describes . It would certainly be helpful if I could select from this sort of database directly - PartKeepr runs on a SQL backend & being able to query something like this directly (with my actual stock levels) would be very helpful for my use case. I accept that I am using this as a very (very) small production environment and this idea may not scale. The only functionality that would need to be incorporated in to Kicad would be an ability to copy a part definition in to the schematic or layout from a database. How you use it and what data you store on it would be up to the user.
I can understand why it would help with BOM information. But why would it help with things like footprints, 3d models, the graphical part of the symbols or even spice models? (You know the stuff ECAD software mainly cares about.)
For interfacing with bom stuff i would suggest a separate interface. How about defining a single symbol field as a house part number that is then used as the key in the database?
The only thing i can see as helpful would be something similar to git that inherently supports version control. But this would really need to be implemented in a way that hides it completely from the user.
Yes, I don’t have an absolutely coherent idea of how this would look in practice. My idea behind a database is that it would facilitate an atomic component workflow with current stock levels, lead times etc available ‘up front’. In that each database component would be fully defined, it would be possible to show all associated information about the component - including, as at present the symbol but also other associated data from the database - which might include stock levels, ordering information etc, as well as the footprint & 3D model - ideally in one window. Yes, I accept that quite a lot of that is achievable with judicious use of custom fields. The advantage, as I see it is that I then don’t need to have a database for my stock and another ‘database’ (in the form of a bunch of files) defining the symbol, footprint & model. Having this information in one place would facilitate management; the weakest of the ‘bunch of files’ approach is that it is predicated on a fixed ontology.
The workflow I have used is a post-hoc parsing of the BOM to pull in the data from PartKeepr and use Octopart to identifying ordering information. I doubt if this would be an effective strategy ‘up front’ as the lookup is somewhat slow.
Some sort of SQL connector is a feature that KiCad needs in the commercial environment.
If some big sponsor would pop up to fund the feature for V6…
Realistically companies have invested huge amounts of money with SAP etc into MRP systems and these won’t be replaced for a CAD applications benefit
For “jellybean” parts, yes. But for non-trivial ICs or other unusual parts, there really is no replacement.
Even for “jellybean” parts, I would rather be able to generate a BOM with part numbers right away, and then find replacement parts when necessary.
No, for “jellybean” parts, I would rather have a small fragment of code that can generate part numbers for my favorite manufacturer based on the resistor or capacitor value, rather than trying to put every conceivable resistor in a database.
Again, though, I see this as most useful for things like ICs or connectors which are more unique. (Though for certain types of connector, I might still want it parameterized by the number of pins.)
I think what I’m wishing for is an open-source implementation of such a system, for those of us who are doing this on our own. It’s great that big companies have already solved this problem, but not all KiCad users fall into that category.
I don’t think anyone here is trying to do that. (Or even has the power to do that if they wanted to.) Rather, I think a few of us are expressing an interest for a tool that would give individual users some of the benefits of these big company IT departments.
Well, that actually isn’t my biggest problem with it. My objection to creating my own atomic parts library (which seems to be the standard answer to this sort of problem) is that I like to publish my designs on GitHub as open source. If I use my own libraries, then I either have to tell the user to install my library before opening my design, or tell the user to click through the “rescue” dialogs that will appear. Both approaches would work, but neither is ideal. I would prefer to have my designs use standard KiCad library symbols when possible. (Yes, most boards will have a few unique symbols that have to be distributed with the design, but I feel that’s a much more tractable problem than distributing every symbol with the design.)
I think what I will eventually end up doing is creating a personal library, but then adding a field for “original symbol name”, giving the name of the symbol in the KiCad library that my symbol was copied from. Then, I just write a script that goes through a .sch file before I publish it, and replaces each symbol name with the value of the “original symbol name” field. That way, I get the benefits of a personal library, but to the end user, it still looks like I used the standard KiCad library.
Yes, but then I need to write a tool to generate the BOM by looking up the house numbers in the database. I can do that, but I think there would be value in having a shared tool that can be used by everyone who needs this workflow, rather than everybody cobbling together their own script.
Similarly, there might (I’m not 100% sure) be value in having a shared database of “house” part numbers for makers, rather than me having to make up my own house part numbering scheme.
I’m at the point where doing BOMs in a completely ad hoc, by-the-seat-of-the-pants way is starting to become inconvenient, but I don’t have an IT department, or a purchasing department (or any department of any kind) to set up a massive amount of infrastructure.
I think that such an extensive database would also have many more components than only what is on a pcb.
Connectors, cables, housings, screws and washers, and maybe even packaging material.
I see such a database more as a separate program than as integrated into KiCad.
With some scripts such a database could generate a library of “prefered parts” for use in KiCad.
But overall I’m not much interested in this sort of thing. I do not make many PCB’s and for me it seems like it’s more throuble than it’s worth. I’m very happy with what KiCad already offers. and would much prefere time being spent on the core of KiCad by the small developer team than on these distant extensions.
This Grand Unified Database that links a component’s electrical definition (resistor, inductor, IC, etc) with its mechanical implementation (TO-220, SO-8, SMD0805, etc) and part numbers from multiple OEM’s (Vishay, ONSemiconductor, Yageo, etc - and don’t forget that the p/n changes when you buy in bags, boxes, buckets, or boxcars) and the ordering numbers for the vendors you may buy the part from (Mouser, Newark, Sears, etc) and the unit count in your organization (stockrooms, desk drawers, the parts already allocated to some project, etc) . . . . . I would much rather see resources expended on improved DRC, a panelization tool, autorouters, etc.
“House part numbers”, in one form or another, are the norm for every manufacturer I’m familiar with who has more than a couple dozen (total headcount) employees. No two are alike, even in defining how much information is represented by a single part number. It would certainly be useful if some Wise and Insightful person defined an open-source “house part number scheme” that could be used by a wide range of organizations, from individual tinkerers up through million-dollar corporations with a couple hundred employees. (And I use the terms “wise and insightful” in their serious, literal sense - not in any way tongue-in-cheek or sarcastic.) As I have said, I think that task is outside KiCAD’s scope and beyond its present capabilities.
Estimates of those costs usually exclude the time, talent, and treasure required for in-house implementation, maintenance, and upkeep of the MRP systems. The far-from-ideal performance of tools like SAP, despite huge sums invested by developers as well as customers, should be fair warning about the size and scope of such a project. It’s one thing for Dick Tracy to have a two-way wrist radio in a comic strip from 75 years ago, but the wishful concept is a LONG ways from holding a functional I-Phone in your hand.
