I had an idea for a new Bill of Materials tool (BOM) for KiCAD and so I made a project that conceptualizes what I was thinking. I’m calling it BOMGarten right now, and I released the Alpha version for free a couple days ago. It’s GPL3 since it uses some KiCad helper python software (sch.py) in the background. I was wondering if I could get some feed back on it.
Right now it’s pretty bare bones and the code itself can be downloaded here:
And a video of it in use can be seen here:
I’d be interested to hear any feedback on it. It’s still a work in progress, but I think if fully fleshed out it could be a really useful tool.
Hi. Nice tool. It’s not clear to me how the part information gets from the Digikey web page into your tool. Do you have to manually visit the web page and then BOMGarten scrapes that page to extract the data?
Yes, so basically as you’re looking for parts you copy the part number from the web page and put it into BOMGarten. When you press the scrape button it uses the selected scraper from the scraper combobox and gets data from the webpage. Right now I only have one scraper available (digi-key), but I plan on having multiple scrapers that would work with other distributors (mouser for example).
Edit:
Just to clarify further, you don’t need to have a browser open or anything, my code uses beautiful soup and the search string that Digi-Key provides:
‘http://digikey.com/scripts/DkSearch/dksus.dll?Detail&name=’
Which when you append a component name to it will resolve (hopefully) to the part webpage that you want, and then can be parsed by beautiful soup.
You’ll have a problem extending this to Mouser since they use various web services to prevent scraping. Also, all the distributors like to change their webpage HTML format so you have to keep on top of that by updating your scrapers (alot!). Using Octopart was a possible solution to that chore until they stopped giving free API keys to non-students and screwed everyone. That leaves using the various distributor APIs, but that means each BOMgarten user has to get their own API key for each distributor.
KiCost already went through this mess. Then we gave up.
It may turn out that you can get away with only scraping the Digikey website. Except for the distributor ordering number (and pricing), all the part data should be the same across all distributors. Then inserting all the part data into the schematic fields is a real time saver.
This would work as long as Digikey doesn’t start pulling the same anti-scraping tricks as Mouser. Digikey has been pretty supportive of KiCad, so that might work. And you would only have to keep up with one scraper.
Once you release BOMGarten, you should list it here so others can find it.
That’s true. The main purpose of this tool wasn’t to get things like pricing. This was added more as an after thought. More or less, it was to keep data like manufacturer part numbers, descriptions, and keep engineering notes and make it a bit easier to maintain projects in the long run.
I appreciate the feedback! Once I get it a little bit further along I’ll list the tool, but right now I could end up changing fundamental features.
@volunteerlabs, interesting project. I was one of the collaborators in KiCost. We freeze it because of the scrape/API problems found.
At this point of your project, we should be concerned about standardization of the filed names. So in the future, different tools (such yours and KiCost that appear to be complementary) could be work together.
I’ll have take a look at KiCost and see what would be required. Right now I’m working on core features of BOMGarten. So far I’ve heard from multiple people that my webscraper is going to get outdated very quickly. I think in the near term my next goal would be to include a second scraper that uses Digi-Key’s official API. To do this, however, it seems that the user would have to register with Digikey’s API service and provide credentials.
Not ideal, but certainly a lot easier than filling out a BOM by hand.
If this tool work directly on the BOM csv file. It would be more flexible. So that I can apply this to multi-configuration csv BOM file/files. With this new script I reasonably made Back import custom fields.
If the code’s already there, then yeah, I’ll definitely take a look into it. I guess my only concern would be a potential mismatch between the schematic file and the BOM.
