I've written before about my favorite Eagle tool: a pricing ULP that gets real-time prices for parts from Digikey and generates a BOM cost for building a set quantity of boards. Recently, Jorge Ortiz from the Jicamarca Radio Observatory modified the code to remove the restriction of only allowing a single ordering number and value for a part. That was a problem for things like resistors which have different ordering numbers for each resistance value. He even added the capability for specifying multiple manufacturers for a part which is helpful for things like resistors and capacitors. Jorge also found a fast way to go directly to the Digikey web page for a given part and avoid the much slower search function technique I used.
However, I noticed that the new ULP wouldn't fetch the price for the PIC18F14K50-I/SS MCU I used in some of my designs. It turns out that Jorge's technique fails if the part number contains a '/'. The Eagle ULP netget() subroutine doesn't escape the forward slash so it gets interpreted as a URL path separator and a 404 Page Not Found is returned. So I modified the ULP to escape the '/' by replacing it with "%2F". But then I found that netget() will escape the '%' character so you get a URL with "%252F" in it and that results in another 404 error.
Figuring that this problem must have been solved previously, I started a topic in the Eagle forum about it. It took awhile to explain my problem so it was understood, but Doug Wellington was helpful in escalating the problem to the Eagle developers. However, after all was said and done, the end result was this:
Just an update, the devs can reproduce the issue and have traced it to some of the third party libraries we use in EAGLE.
They're going to work on it, but there's no estimated timeframe for the repair.
Even if they do fix it, the fix will probably only be incorporated into Eagle 6 and not propagated into their older versions. I'm using Eagle 5.11 and I have no intention of upgrading, so my final statement on this was:
Thanks bunches for that!
Now you might be asking: "Why do you need to scrape web pages to get part prices? Doesn't Digikey have a web API for that?" And you'd be absolutely right: Digikey has an API in development. It's been in development for years. I contacted them in July of 2013 and asked to become a beta-user. After some back-and-forth, I got this final reply in December:
Our review committee has met to review your request. Unfortunately, they do not feel that this is a good fit for us at this time. Please continue to utilize the Digi-Key website for continued access to our component information, availability, and pricing.
To which I could only reply:
Thanks bunches for that!
I finally resolved the Digi-Key problem by using my older search function technique for those part numbers containing a '/' and using Jorge's method for everything else. It's ugly, but it works.
I also wanted to get part prices from Mouser so I could compare pricing with Digi-Key. I found Mouser also has an API that's already released, and it's easy to get access to it. But if you look carefully at the list of data available through their API (and I did not), you'll notice this little gem:
Pricing Information (Up to 2 price breaks)
I contacted Mouser and was given an email address where I sent the following request:
Hi. I created and distribute a ULP add-on for Eagle that does board pricing based on real-time component information from sites like Mouser and Digi-Key. Yesterday, I applied for and received permission to access your Mouser API web service. This will make it much easier to get pricing information (and it looks like it will also enable some new features in my ULP).
Unfortunately, the terms of service limit me to receiving two price breaks in response to a service request. This makes the purchase of a board parts kit from Mouser appear artificially high. (You can imagine the effect on the cost of 100 boards with 50 decoupling capacitors each if each capacitor is priced at the quantity=10 price break.) So my ULP would be giving the user bad cost estimates and, potentially, driving them away from using Mouser. Therefore, I would like to get access through your API to the same amount of pricing information that I see on your website. Is this something that can be arranged?
I sent this request several times, but each time I received the response "Your message can't be delivered because delivery to this address is restricted." I went back to my Mouser contact and asked if there was another route to deliver my request. I received the following reply:
Thank you for contacting Mouser. This is currently the only route and all the information that I have concerning API.
I apologize that I am unable to help you further.
To which I could only reply:
Thanks bunches for that!
If the Mouser API is too restrictive, I could always go the web-scraping route that I used with Digi-Key, right? Well, no, actually. It appears every fetch of a Mouser web page generates a 301 redirect before getting to the product page with the pricing information. That would be fine except - and you can probably guess this by now - netget() doesn't handle the 301 correctly and just reports an error fetching the page. Now I could go to the Eagle forum and try to resolve this, but I'll just short-circuit that whole process and jump right to the expected end result:
Thanks bunches for that!
So in the final tally, my pricing ULP works correctly (albeit inefficiently) with Digi-Key and not at all with Mouser. I know some of you who read this will say "Why not just interface with Octopart and use their API?" I guess I could tell you that Octopart only allows 500 part queries per month before they start charging and it's really easy to exceed that with a board containing only 20-30 parts. But, instead, I might just respond, "I've ceased development of this ULP and I'm moving to KiCad."
To which you could only reply:
Share on Twitter Share on Facebook Share on RedditThanks bunches for that!
Comments
New Comment