A tool to compare KiCad Footprint and Vendor Component package???
So I just fell in a hole (again). I placed an order for JLC for PCBA. I got a wrong device (diode) pn and they won’t place the part. Their checking doesn’t occur until after I order and pay.
A VERY USEFUL tool would compare the KiCad footprint to the JLC (or Digitkey or ?) pn PACKAGE.
I used an SOD123 footprint and some other device package: mismatch.
Could there be a tool which compared the Footprint to the JLC/LCSC/Digikey package?
I realize this is a big ask, as the tool would need to goto the JLC/Digikey pn listing and find the package style. Not impossible, but not lightning quick either. The performance delay is nothing compared to the DAYS it takes when JLC identifies the mismatch way too late to fix it.
However, this approach could also build a local database of:
Mfgr pn 1N4001
Pkg Style SOD123
Distributor pn abc123
Then future searches would be able to check a local database (or csv) before going to the vendor on the web.
Finally, compare Footprint to Pkg Style and highlight mismatches. No fancy GUI required. Just list all the parts and color code mismatches.
Are you just looking at the JLCPCB SMT parts library? This is downloadable as a CSV file which would be easy to parse and match on LSCS part number. If you are using KiCad library footprints, they will not match directly
eg. Resistor_SMD:R_0805_2012Metric in KiCad is 805 in JLCPCB.
Depending on number of parts in your BOM, it might be easiest to scan these by eye. Following the data sheet links or otherwise checking manufacturers websites would be a different league of difficulty.
This makes brainwaves in the direction of KiCost.
That is (was?) a method to match KiCad’s BOM info with cost / availability information from stores.
I have not used it personally though. From what I read on this forum the project was frustrated because of manufacturers deliberate change their website often with the intention to break scripts that crawl it to extract information.
If the JLCPCB SMT parts library is a single downloadable parts file, and download is approved by them, then those can maybe be combined.
Everywhere I look noawadays vendors are providing parts information freely. DigiKey has an API. I’ve downloaded JLC’s CSV and it’s updated regularly. Seeed Studios offers pre-built KiCad libraries. It only makes good business sense. Information wants to be free.
But as far as OP’s question, I don’t think automation will eliminate any pitfalls. I have a library of “Atomic” symbols for JLC parts and I still lose sleep over “Have I missed any problems with the pinouts?” @iabarry feel free to message me if you want to hear more.
Unfortunately, all those different sources are formatted differently. I don’t remember the “guilty” parties, but I do recall a time in the not-so-distant past where vendors were changing their APIs as a response to 3rd parties scraping their data for aggregating information. KiPart I think had issues with that. Then OctoPart came around to do all that scraping and provide a unified API to assist comparing pricing between different vendors. I haven’t checked recently, but as I recall they started going to a subscription model to access the API outside of their web page. Again, KiPart had (and/or is having) issues with that. I don’t recall the public reasons (probably server load), but I wonder if they were getting any pressure from the vendors or being forced to purchase subscriptions from the vendors to use their APIs.
Information wants to be free, but the gate-keepers of that information are who keep putting up barriers and toll lanes. Granted, some of those tolls can be reasonable, because it does take human effort to massage the data and those humans want some sort of compensation so they can afford to do things like buy food to eat…
You can get some of the data for free, but when volumes get bigger, then so is the incentive to put it behind a paywall. Also, octopart has bee bought by altium, and they’re not best friends with KiCad…