pcb-rnd knowledge pool
Someone else's footprint
sef by Tibor 'Igor2' Palinkas on 2016-!!-!!
How using existing footprints is overrated
"Tapping their database for footprints": this idea often comes up with open, free or semi-free databases. It sounds like a great idea first, but if you think over the details, it's not as great as it first sounded. The problem is that different tools model the world differently. And it is not a file format question, but data model question: no matter how good your format is, no matter how good your library is, no matter how good anyone's import/export code is or if you even use the same format/EDA tool the footprint designer did: at the end, if you import a footprint from "somehwere else" you will need to open the datasheet and manually check all relevant aspects. In a real complex case this includes:
- mass production soldering consideration details, like how longer an smd pad exactly is or that you want round cap on one end and square cap on the other
- tricky mask and paste patterns
- sometimes even tricky silk pattern
At the end you will spend almost as much time on making sure the imported footprint won't mess with your design than if you just draw it from scratch, dealing with exactly the same considerations.
Of course this is somewhat relaxed on the low end, for hobbysts trying to build an arduino shiled with 1206 and TO-92 packages, 2 layers, hand soldered. But they are not our true target audience: for them, pcb-rnd and gEDA is just too complicated and they will probably land at KiCad or eagle.
I don't say this means we shouldn't import or reuse footprints. I only say that the value of tapping a big database is often not as high as it first seems.
web service for sharing resources
We have edakrill .
converting between formats
Pcb-rnd already does this well.
Inventing yet another format from which conversion to everything else is "possible" or "easy" is not required for this. If your starting format is feature-rich enough, exporting to others will work well. Whether this format is a specifically designed for that or just happens to be a good format originally used natively by some EDA tool - doesn't really matter. If any service says "we have a magic format, and this allows us to convert to anything" , it is mostly just PR I believe.
On the other hand we do have tEDAx - not for having a file format that holds data better than any other format, but specifically to make the implementation of interoperability cheaper for smallish projects. So tEDAx is not needed for communicating between two EDA tools, as a file format it doesn't offer better features than any other format the two tools mutually understand. What it offers is that if you have a tool that needs a new format to be able to communicate with another tool, tEDAx is probably the cheapest to implement.