Automatic specify generic components

[stevenj]

Things like resistors and caps are quite generic. It would be nice if there was a way for kicost to lookup these types of components based on their parameters (type, value, package). And then pick the most cost effective one for that job. Not sure the best way to achieve that, but it would be nice.

If the suppliers cant be directly queried based on the parameters than another way would be to have a generic part database, CSV for example, which maps the component parameters to known parts, but then someone would have to maintain that. However, it could be locally maintained, so that once you have verified that the Yageo 0.1uf Cap is just as good as the Murata 0.1uf Cap you add that to your own local list of Generics.

Just an idea.

[hildogjr]

I would link to link #77 with this request. I think if we standardize the code, we may implement a module / function that getting the value / reference (capacitor, resistor), if the manf# (and other) is empty, parse one string or use some definitions / dictionaries to pass the string to look for in the distributors to search capacitors / resistors.

[hildogjr]

I did some manual test in the web sites and with 100nF ceramic 0805 (value material and package/footprint) I could found the capacitor that I want.
I think this is the way: one python module/file specific do deal with (using generic type of material names) some definitions and with this three data parse one manf# to the rest of the KiCost script.

[xesscorp]

I don't know if this is an appropriate function to place in KiCost. KiCost generates part cost spreadsheets. The requested function is more like doing part selection. I could see a separate tool that processes an XML file and inserts part numbers for certain types of parts like resistors/capacitors. Then the augmented XML file could be passed to KiCost. That keeps the complexity of part selection separate from the complexity of costing.

[hildogjr]

Maybe as separated module active by --optionin the call, that is default off?
Because this need to be calibrated by the user (a resistor, for example, have: tolerance, package, maximum dissipation power, maximum voltage supported, ...)

[hildogjr]

@stevenj , I thinking about this implementation as a module that get informations in fileds of KiCad as 'value', 'manf', even footprint.
In some conceptual test I look for in digikey for " 390R 5% 1/4W axial" and I got almost the "CF14JT390RCT-ND" that was one that I had select in the past to this specifications.
I am thinking in an additional module to KiCost that we could specify the default characteristics (such as "tolerance", ...) but, I need help of the users to test each distributor web site and see if this kind of search string return always useful results (so KiCost got the most cheaper).
And of courser, first the implementation said by me in #4.

[hildogjr]

@xesscorp , the distributors sub modules have not yet my full understanding. How exacting these is working, just with a full exactly matching or analyzing the the answer of a match.
Explaining, for manf#=UA78M05CDCY, digikey page in my spreadsheet is https://www.digikey.com/product-detail/en/texas-instruments/UA78M05CDCY/296-27138-5-ND/1910303, but search on the site appear a list https://www.digikey.com/products/en?keywords=UA78M05CDCY%20.
The part is got by the exactly match in the results? (Understanding the possibility of search of value + footprint + voltage_max + tolerance + ... and got some results).

[hildogjr]

In each distributor submodule there are the code difflib.get_close_matches to the case that a search result a table of results and not just a single match.
This could be modified (by a get_part_html_tree() input parameter) to get the most shipper one and not the close match (close match still the default). So, using this and the informations that I told in the last comment (this I can extract by the footprint name and some definitions given by the user, I have some idea), I think KiCost will be able to select capacitor and resistors.
Maybe, the start point, is using the issues #146 and #161 and create this modification. And this could be validate by use of #4 implementation.

[mobilinkd]

I'd like to suggest a potential half-way step to specifying generic components. Allow users to specify alternate part numbers in the manf# field, with parts separate by a pipe symbol (logical OR operation).

For example:

manf#: SKSCLBE010|EVQ-P7C01P

This would allow kicost to price either of these two tactile switches.

Another example is this case:

manf#: FC-135 32.7680KA-A0|FC-135 32.7680KA-A3|FC-135 32.7680KA-A5

These are the same part, distributed on different sized reels. I use other components that are distributed either on trays or reels, each with distinct part numbers.

I see that #236 was closed as "wont fix" without any comment as to why. To me it seems that #236 is less involved and solves a more practical problem (at least for me) than allowing one to specify generic components. get_close_matches() may solve the second issue, but I done see how it will solve the first.

I have a number of BOM items that have qualified alternates (dual MOSFETs, tantalum caps, polyfuses, EEPROMs, tactile switches, etc). Other than the tantalums, I don't know if anyone would consider any of the others to be a generic component. I would not want kicost to price them that way.

[hildogjr]

@mobilinkd , I moved this discussion into #236 to not spam or mix the subjects.

[craigarno]

Reading through this thread has given me a new perspective on component purchase and I can see some merits to providing KiCost with an exact manufacturer selection. I have been in design situations where this is exactly the behavior desired and needed. So let me try to give the other perspective. This is long, I'm sorry, but it's important.

As a developer either sole, or in a group of developers, there are times when in-house parts won't satisfy new design part needs. The list of "new" parts could number in the 50-100 range. It takes a lot of time to individually search Digikey, Newark, Farnell, Mouser and other supported vendors for these new parts, and if two or more of these do carry the needed single manufacturer's part, they don't usually have the same prices. Cost -by- Manufacturer can and often is part of the new part selection process, or old part selection review. Let me provide a simple to follow example:

New part "555 Timer" (old tech but new to company). In the schematic this is listed as NE555 which is functionally compatible with TLC555 and a host of other part numbers from different manufacturers. From a design point of view I'd like a "loose" search for part matches. for instance if I go to Digikey and search for "555 Timer" I get matches for Manufacturers; TI, National, Renesas Electronics, STMicroelectronics, Microchip Technology, Diodes Incorporated, ON Semiconductor, Maxim Integrated, Nexperia, Rochester Electronics, Advanced Linear Devices, Rohm Semiconductor, NXP, NJR. This is great, it's what I want, and prices on Digikey vary considerably between manufacturers for functionally equivalent parts.

This price variance is why part selection must consider manufacturer selection cost in addition to vendor cost. If I make a spreadsheet and label columns Digikey, Mouser, Newark, etc. then for rows I put TI, National, Renesas Electronics, STMicroelectronics, Microchip Technology, Diodes Incorporated, ON Semiconductor, Maxim Integrated, Nexperia, Rochester Electronics, Advanced Linear Devices, Rohm Semiconductor, NXP, NJR. It is easy to see that I need to investigate 5 vendors times 14 manufacturers or 70 different prices to provide the data needed for a manufacturer+vendor combined cost decision. Now if you have 100 new parts which also need this process, that is 7000 part-manufacturer, vendor prices which must be analyzed for one "new" design.

At manufacturer level the Design Engineer must be involved in selecting a manufacturer because different manufacturers use different process technologies which can result is different setup/hold and propagation delay timing which will determine if a circuit design will work or not, even if the part is functionally the same and pin compatible. comment: I've had this happen with memory chip manufactures.

Other factors which prevent selecting "bottom dollar" parts fit in some of these categories;

• delivery time vs quantity in a JIT type environment
• Second and Third Vendor/Manufactuer sourcing company procurement requirements
• temperature range; commercial vs automotive vs military
• MTBF

I don't expect KiCost to help with all of these decisions, but would hope KiCost can help with manufacturer selection, especially with simpler part selection. i.e. a column checkbox for "exact manufacturer match" which if unchecked will include other possible manufactures (loose search), just like Digi-key and Mouser do with online component searches.

Summarizing, not including Manufacture in the Vendor selection process is like choosing product purchase price without considering $25-$100 shipping cost. You can make a bad decision by only looking at half the data. Which to use (loose vs exact) will depend on if part searching is done by a procurement specialist, or a design engineer. Design Engineers can do initial selection if the tools make it easier with automation. Otherwise the design engineer is left doing initial Manufacturer selection manually which is quite tedious. Having KiCost do this initial "loose" part-manufacturer search with clickable datasheet links for detail component specifications is quite useful. Right now I see KiCost as solving the procurement problem, not the manufacturer problem. I think it could do both without too much effort depending on who is running the tool.

As an alternative, when I watched the YouTube video, there was an option to copy formatted BOM info as plain text for copy/paste submittal to Digikey, Mouser, Newark. I'm happy to do my design manufacturer searching on the various sites if KiCost can help with "generic part" BOM input formatting, sans Manuf# information. This way KiCost can avoid duplicating the search functionality these sites offer, and maybe help make some design engineers design effort easier.

Thank you for reading this far.