1.) Is anyone willing to help me make this better? (Current enhancements in github issues) if you are a FreeCAD or KiCAD python API wizard.
2.) Was I completely wrong, and such a tool already exists somewhere I simply havenât found yet?
Does the SnapEDA or UltraLibrarian license actually allow you to do this?
Generally those services require a login because they are trying to âmonetizeâ you. If you look in the files you get, those files themselves have a restrictive license.
Personally, I donât find things like SnapEDA to be that useful. The footprints and symbols tend to have significant errors if you start looking. Generally, itâs faster for me to construct a footprint/symbol rather than try to hunt down the errors from SnapEDA.
About the only time I grab something from SnapEDA is when it is the only source for a 3D model. However, if I hit that, I tend to go searching for a different component from a competent company that actually pays real engineers to generate a 3D model and put it on their website.
This whole trying to âlock-inâ people with library management is a pox upon the industry. Itâs what finally drove me away from Altium and onto KiCad completely.
Does the SnapEDA or UltraLibrarian license actually allow you to do this?
Generally those services require a login because they are trying to âmonetizeâ you. If you look in the files you get, those files themselves have a restrictive license.
This still requires you to login and download the zip files yourself, so I donât think that would be an issue.
Personally, I donât find things like SnapEDA to be that useful. The footprints and symbols tend to have significant errors if you start looking. Generally, itâs faster for me to construct a footprint/symbol rather than try to hunt down the errors from SnapEDA.
I havenât noticed any âerrorsâ so to say yet, but I often have to rework symbols as theyâre unnecessarily split into two parts and things like that. What do you find to be wrong typically? Symbol creation can be quite quick, but I find footprint creation to be a very tedious task (but I havenât tried this in v6 yet, so maybe its more efficient?) I felt getting dimensionally accurate footprints in kicad < v5 to be a nightmare. Has this gotten significantly better?
Also Iâm really surprised that there is not a more community driven library management push. The idea that every engineer is reproducing the same footprint, symbol and model for a part is grossly inefficient and much more prone to errors than if we were all checking each otherâs work. Iâve seen a few efforts on github and gitlab to move towards a community managed library, but havenât seen anything as far reaching (part count) as SnapEDA and UL.
This whole trying to âlock-inâ people with library management is a pox upon the industry. Itâs what finally drove me away from Altium and onto KiCad completely.
The reality is that thereâs no quality checking and people will abandon the library because they canât trust it.
But hey â says someone â why not add an in-built crowdsourced quality check, a 5-star system! Because you canât trust the stars. Any random user can give 5 stars if it happens to work for them (or even without any actual checking or testing). This would need a trusted team who inspects the contributions. And the contributions should obey some rules. And here we come to the KLC and the official libraries.
The problem with the official library project is the lack of inspectors. The lack of wannabe contributors wouldnât be a problem, but itâs quite tedious to learn and obey the KLC rules.
This really is a âtrust but verifyâ situation. This goes for every part of your design. Thatâs the reality here. Having a starting point that turns out to be correct is really nice. Then the only time spent is the time you used to verify.
Well, if weâre being fair, the real problem is that the bloody manufacturers canât even get together and come up with a datasheet standard that would let us extract footprints programmaticallyâhowever, there is no money to be made in it so nobody ever complies and then weâre back at the beginning problem again.
However, even if that were the case, there would still be some issues. Just like BOMs, footprints tend to be âspecial snowflakesâ. Your process can handle .40/.20 vias, while mine only handles .65/.40 and her process only handles .75/.50 vias. The thermal vias of each of out footprints are going to look very different.
Thanks everyone for your comments, but Iâm sensing an overwhelming amount of pessimism here :D. Iâll keep trying to feed some motivation:
Yep, I have maintained my own branch off of that for a few years now. I havenât tried to PR anything though, but I really should learn the rules there as this is definitely a good path forward. Curious how much of the SnapEDA/UL stuff could be added there (with slight modifications/fixes) without breaking any such terms mentioned by @buzmeg as these are the kinds of things I tend to add on my branches but donât push.
Hmm, although I can appreciate the concerns, I think that might be getting a little too close towards a larger argument for/against open-source software, which sounds quite counter to the idea of the entire KiCAD platform. I sincerely donât believe in the idea there exists any âtrusted teamâ. Everyone makes mistakes; I donât know how many datasheet corrections Iâve submitted to manufacturers, and they are the ones that are supposed to be the âtrusted teamâ, but without user contributions highlighting their mistakes, these errors would remain in the datasheets for MUCH longer if not indefinitely. Again, the more eyes on something the more likely someone will notice something is wrong.
Besides, I donât think you need as rigorous QA on the contributions as you mention. If a new contributor makes a PR without any reasonable commit message(s) then its pretty easy to throw out quickly, whereas if theyâve explained in detail what was changed and why, it becomes pretty fast to verify the accuracy of that. I canât say Iâm too familiar with the hierarchy of the gitlab roles for PR approval, but I believe the more eyes on a particular piece of code, the better/more accurate it will become given enough time. If one crappy PR/commit slips through, someone else can make a reverting commit just as easily.
Also, Iâm not sure if gitlab has the same functionality, but github has some functionality to alleviate this kind of âtrust/talentâ bottleneck, and instead of depending on one of a handful of âtrusted team membersâ to approve of the PR, you can get > 3 or > 5 low-level team members approve (the number and rank of these things can be set arbitrarily). In this way, it becomes much harder for someone to merge something of random error. Just saying, there are plenty of advancements in git collab tools to make this MUCH easier than it is sounding here.
I canât claim to know, but it would seem this is what SnapEDA and UL are trying to do no? Iâd guess rather than pulling from datasheets, theyâre getting the design library files (Altium/ORCAD/etc) from the manufacturers with incentive that if their parts are on SnapEDA/UL more people will use them since theyâll be easier to integrate into their designs. I think there is indeed money in that. I can only speak for myself, but prior to all the supply chain issues, my first filter on Digikey after âActiveâ and âIn Stockâ was âEDA/CAD Modelsâ because I couldnât be bothered to use a part without them since there were so many that had them. Surely the manufactures have library files and arenât drawing these things in Inkscape :D, and this is how they generate the datasheet entries, so why try to scrape it from a pdf when you can use the raw file? As much crap as SnapEDA and others take for monetizing our usage, I think its a great solution to what everyone else seems to be warning against (lack of funding/manpower to centralize all this data); theyâve found a way to make this process sustainable. Iâm quite curious if anyone on the KiCAD library team has made any efforts to get this data directly from manufacturers as well?
I realize you are just playing the devils advocate here, but I think this is a bit of a logical fallacy. If we canât solve everything donât try to solve anything? Sure, you should still have the ability to customize these things, and the more complex the part the more that will be necessary for the reasons you mentioned, but for any low/mid level complexity part, I donât want to be bothered to draw the same 10-200 lines/rectangles that someone already drew 2 days ago. Its rebuilding the wheel, but 10s to 100s of times a day. As an engineer, I simply canât get behind such inefficiency. Yeah, I could (theoretically ) build an op-amp out of single transistors every time I needed one, but come on, there are more efficient ways of doing this.
Maybe we are talking about a bit different things. Footprints must work, they must have their pads in correct places and dimensions. No library can be perfect, everything must be checked, but a library which has random contributions without control would mean more work than creating one yourself.
This has nothing to do with Open Source. Itâs the same for any âlibraryâ for any software. The problems are of course different and an end user canât always choose to create things themselves. Take for example software app centers. Unfortunately I canât trust the starring systems or anything.
By âtrustedâ I mean I can know that it has gone through some real inspection or verification where the responsible persons know what they are doing, and some rules or standards are obeyed. This happens with the official KiCad libraries. They are not perfect, but much better than anything which accepts all contributions without restrictions (and rely on crowdsourced verification).
Anyone who really wants to help with high-quality KiCad libraries should start to inspect existing pending contributions to the official libraries against datasheets and KLC.
A lot of my thoughts from some time ago were presented in a few comments in this topic. I liked that, thank you all.
Libraries and related stuff are hosted here, 9 repos in total and only 4 of them are installed with KiCad.
KLC is here and that rule-set must apply. Not every rule can always apply for everything.
The best way (IMHO) to make a step towards helping with library management is doing some search in older(even the ones that still exist in the previous Github repos) closed or merged PRs/MRs (with a number of comments in them). Some of those comments are a great source of information regarding decisions taken at some situations.
Getting comfortable with Git will help a lot. But the fact is that Git is not required to just review a MR and add some comments to it. When the MR is ready you can ping someone to review and merge.
Maybe try to contribute something small for a start and see how this thing is rolling.
It has to be noted that a reply might follow after a few months from your comment/MR (I know this is not a good thing, but this is the current situation).
Please be patience and try to not feel discouraged if that occurs.
efforts to get this data directly from manufacturers
There are some discussions in GL regarding automation of a few things.
Money is riding on whether I can trust your part or not. My reputation is riding on whether I can trust your part or not.
It simply isnât that difficult to create a footprint for a semi-standard part. And generally I can trust the generator as it gets used and tested far more often than some obscure part.
The parts that take me a long time are the ones that have some sort of coupling between the electrical and the physical. Where is pin 1 relative to the the polarization notch? Which pins are tip and ring and what is their correspondence to left/right? Why does that 3D model have such a screwball origin and does it really intersect the edge of the board like that?
Iâm simply never going to trust a library on those parts. I will have to expend as much time checking those parts as building them myself. So, a âparts libraryâ doesnât save me any time.
This is, of course, completely different if Iâm working for a company that has a library steward whose job it is to make sure that those libraries work. Now, itâs somebody else who takes the money and reputation hit if something goes wrong. I can âtrustâ that library because there is someone with a strong vested interest in making sure it is correct and even still those libraries regularly have issues.
As far as I understand, this is not true. These companies do not have some magical access to design files at the manufacturing companies (not that these would be any more accurate!). They are using the same datasheets as the rest of us.
I think weâre getting a bit off topic for this particular post, but of course, you are welcome to choose what you trust and what you donât individually, but Iâm not seeing the difference between a footprint vs software with regards to open source. If the ERC code in KiCAD has bugs, you canât trust that either. In the end you have to place your trust somewhere, and I personally place it in the code/footprints that have had more eyes on them. And by trust I mean what @hermit said with , âtrust but verifyâ.
Yep, youâre right, but I think weâve veered off topic a fair bit on this post . Iâm all for supporting the official KiKAD library development, but SnapEDA and UL have a LOT more parts, so making use of that data somehow was the original intent of this post. On one hand, the KiCAD libs allow everyone to maintain and make them better, but the part count is still relatively low. On the flipside, SnapEDA and UL have a TON of parts, but we donât have the ability to update/manage them. Has anyone here submitted error reports to SnapEDA or UL and seen quick/positive progress on their management? Again, Iâm curious how much we can âborrowâ from SnapEDA / UL without getting into any trouble.
Hmm, I think you are just continuing to argue the âif you canât solve everything you canât solve anythingâ fallacy here. Of course, more complex parts will require further attention to detail, and of course in the end all fault lies with the designer. It you were using a paid service alternative to SnapEDA (Iâve never used them, but I know they exist) then you can blame them, but anything free or open-source is always user-beware. If you find checking existing libraries takes more time, then you must be very efficient at making new ones, and if thats what suits you, by all means, but for me personally this seems like a giant waste of time that can be engineered out of the workflow.
I donât think anything magical is necessary here. As an example, TIâs eval boards usually come with Altium design files, which include footprints, symbols, and models for individual components. They lock their library vault to you (you canât openly access anything and everything), but you can make local copies of the libraries for everything inside the eval project. The libraries have metadata showing which vault they came from and these point to a TI managed vault. So TI at least, is managing at least some of libraries for their parts in an Altium vault. I donât see it being too far fetched that TI gives SnapEDA read access to this vault.
SnapEDA even has a web interface for manufacturers to upload this very data:
After reading that, and some more FAQs on SnapEDA, it looks like another aspect of their business plan is to make the manufacturers pay for library creation in exchange for higher visibility, so TI and others are likely paying SnapEDA to create new universal (any CAD plaform on SnapEDA) versions of their Altium managed libs.
) build an op-amp out of single transistors every time I needed one, but come on, there are more efficient ways of doing this.