Plugin to find components in KiCad

[Elictro]

Hi everyone!

Have you guys tried this new KiCad Plugin that helps you to search, discover, and download content for electronic components directly from within the software where you're designing? It was made by the SnapEDA team. I was wondering if you guys wanted to give it a try and share your feedback with us. You can download it here: https://www.snapeda.com/plugins/

Hope it's helpful for others.

Have a great weekend!

[bson]

What KiCad really needs is a proper bom tool, on par with eechema and pcbnew; bom management is really not a simple plugin operation.

Eeschema should be used to document component requirements.  Such as, resistor tolerances, IC parts (e.g. speed ratings, # of dies for flash, etc) - and so on.  A separate BOM tool is then used to search parts catalogs and identify potential candidates.  Since different parts catalogs have different APIs and are used differently they need adapter code.  The use of adapter code also allows for an internal database of preferred parts, including internal details like what other products they're used in, and current purchasing commits.  During layout parts candidates can be further narrowed down, for example by which footprint is most practical or other interface aspects (like pin capacitance).  This means the layout engineer can easily pull up detailed parts information to find these things out, from a distributor or vendor.  The layout engineer should have pricing and availability information at this point, so if possible they can choose a cheaper or stocked part if it's a toss-up, and if they pick a more expensive part they can note in the BOM why this specific footprint was chosen, and who approved its use or addition to the internal stock.  The BOM tool should then be usable to generate not only a basic list of components, but lists of potential parts from different preferred vendors that meet the requirement and their pricing in different volumes from different distributors. You know, stupid things that PMs often maintain spreadsheets on and require a gazillion back-and-forths on.  This way it's easy to answer what-ifs like, what if we make a run of 20000 but our favorite Murata MLCCs aren't available?  With a lead time of 6 weeks?  6 months?  Doing that stuff manually is incredibly twiddly and error prone, and it's easy to miss it might be cheaper to order the minimum volume of 25k of an IC directly from TI than 22k from a distributor, if lead time doesn't matter... in fact isn't automating dumb crap like this exactly why we have computers?!

[kripton2035]

this plugin does not work on macos (it's announced for "later")

[janoc]

What KiCad really needs is a proper bom tool, on par with eechema and pcbnew; bom management is really not a simple plugin operation.

Eeschema should be used to document component requirements.  Such as, resistor tolerances, IC parts (e.g. speed ratings, # of dies for flash, etc) - and so on.  A separate BOM tool is then used to search parts catalogs and identify potential candidates.  Since different parts catalogs have different APIs and are used differently they need adapter code.  The use of adapter code also allows for an internal database of preferred parts, including internal details like what other products they're used in, and current purchasing commits.  During layout parts candidates can be further narrowed down, for example by which footprint is most practical or other interface aspects (like pin capacitance).  This means the layout engineer can easily pull up detailed parts information to find these things out, from a distributor or vendor.  The layout engineer should have pricing and availability information at this point, so if possible they can choose a cheaper or stocked part if it's a toss-up, and if they pick a more expensive part they can note in the BOM why this specific footprint was chosen, and who approved its use or addition to the internal stock.  The BOM tool should then be usable to generate not only a basic list of components, but lists of potential parts from different preferred vendors that meet the requirement and their pricing in different volumes from different distributors. You know, stupid things that PMs often maintain spreadsheets on and require a gazillion back-and-forths on.  This way it's easy to answer what-ifs like, what if we make a run of 20000 but our favorite Murata MLCCs aren't available?  With a lead time of 6 weeks?  6 months?  Doing that stuff manually is incredibly twiddly and error prone, and it's easy to miss it might be cheaper to order the minimum volume of 25k of an IC directly from TI than 22k from a distributor, if lead time doesn't matter... in fact isn't automating dumb crap like this exactly why we have computers?!

Sure, but why is this something that must be provided by KiCAD? Given how organization-specific this sort of stuff is, it would be quite tricky to provide a generic, one size fits all tool for it.

All you really need from KiCAD is an export of parts with their product numbers or what are you using to identify them - which you can get already, either by the built-in (not great) BOM export or by using a bit of Python and the schematics file/netlist (there are Python modules for manipulating both).

You can store all that information in KiCAD using custom fields already, even though it would be probably better to not do so once you need more than 2-3 such fields per part - then it would be probably more practical to store a key to an external database entry instead or the schematic file would become very unwieldy (it is really not meant to be used as a spreadsheet - or rather a spreadsheet pressed into a job of a database!). All this info is exportable and manipulable using the above today already. I know because I made my own tool for handling some of this stuff.

The rest would be left best to an external tool because every business/designer has their own way of storing the information, their preferred vendors and way of working. Something  you could easily do yourself to adapt to your exact needs - if you can deal with writing Excel macros in VBA, you certainly can handle Python too. Or hire someone to do it for you if programming is not your forte. A skilled Python* programmer could whip something basic up for you in a day or two already. Given that if you need this you are likely using the tool professionally, that shouldn't be that big deal to pay for.

All the necessary "bricks" are in place already. I know that the "big boys" EDA tools (like Altium) ship with stuff like this. But then they also have a lot more development resources than KiCAD does and I think the KiCAD team has other, much more pressing priorities to deal with than this.


* I am talking about Python because there is support for scripting KiCAD in Python, there are external libraries to deal with KiCAD file formats and Python is a language where it is incredibly quick to do this sort of job (and I am proficient with it). But there is nothing particualy special about Python here - one could write the same thing even in Visual Basic or Excel macros if one was so inclined (and a large enough masochist). All the necessary data formats are open on the KiCAD side.