I would just like to see the component libraries we have cleaned up and some naming convention developed and adhered to.
Something that would be really nice would be to give the ability to place the connection point or hole somewhere other than the center of a pad. The ability to define irregularly-shaped pads would be nice. I would also like to specify a pad that has no electrical connection, especially for some of the MIL-spec thermal pads. As an aside, has anyone considered using XML for all these files? <ducking to keep from getting hit with all the tomatos> It's a standard format that has parsers/generators/checkers readily available. A schema for Kicad's file formats could easily be written and then automated/semi-automated tools and libraries could be easily used to develope ancillary programs to analyze boards, analyze schematics, perform patch-up operations, etc. I know there would be some portability issues between the older files and the new ones. I'm not saying this would be easy or quick. But it would give us some modern file formats that could be easily manipulated as needed. Greg ________________________________ From: Philip Pemberton <ygro...@philpem.me.uk> To: kicad-users@yahoogroups.com Sent: Saturday, September 12, 2009 7:55:07 AM Subject: [kicad-users] Kicad library project Hi guys, I'm toying with the idea of building a completely new set of libraries for Kicad (and possibly EAGLE as well). This all stems from the fact that no CAD package I've used thus far has had what I'd call a "decent" set of libraries, and IMHO it's gotten to the point where something really needs to be done... As I see it there are a few problems in common with most CAD libraries: - Bad design. Pads with impossible annular ring sizes, stupid drill sizes, SMD pads that are barely larger than the pad on the component itself (and thus utterly impossible, or at least very difficult to hand-solder). - Things not meeting PCB manufacturers' requirements. Differing ideas on whether the drillsize in the NC file is the final size after THP or the pre-THP size, design rules for pads and so on. - Silkscreen on top of pads. I mean, seriously. Scraping silkscreen off PCB pads is NOT fun, and soldering to a silkscreen-coated pad is close to impossible. The EAGLE libraries (even the Cadsoft-created ones) are especially guilty of this, but most CAD vendors appear to have done it at some point. What I was thinking about doing is writing a small-ish program that took a list of components to generate, like this: ----- $DefaultUnit Inches; // axial through-hole components (resistors, RF chokes) AXIAL0.6 AxialThruHole(0.6) // 0.6in spacing AXIAL0.8 AxialThruHole(0.8) // 0.8in spacing // radial electrolytic, 0.2in pin spacing, 7.5mm diameter C-ELEC-R-0.2-5 CapElectRadial(0.2, 7.5mm) // very fat-pinned electrolytic $PinDrill 1.2mm C-ELEC-FAT-R-0.2-5 CapElectRadial(0.2, 7.5mm) // revert to default drill radius $PinDrill 0.8mm // DIP, 100mil pin spacing 300mil between rows, 8 pins DIP8 DualInLine(0.1, 0.3, 8) ------ ... and use a set of templates for each component type to generate the component footprints. You still have to build the schematic symbols manually (it's hard for a computer to figure out where best to put the pins, unless they're just laid out in a grid on a rectangular outline) but the footprints are generated by computer, and thus the pin numbers, silkscreen and pad sizes/types can conform to IPC, ANSI, IEC or whatever standard or house style you like. Bonus: if you're having your board made by a manufacturer who insists that the drillsize be the "pre-plating" size, or if they place restrictions on the drills you can use, then you can change the drill sizes in the script, regenerate the libraries and go from there. All without having to edit dozens of component footprints to meet your PCB maker's requirements. As long as you don't change the pin counts or numbering order (i.e. turn a component called DIP8 into a quad flatpack), you can carry on using the existing schematic libraries. What I'm ultimately thinking of is a "basic" component library that covers 80% of use cases -- you're still going to have to tell Kicad what the PIC12F508 looks like on the schematic, but at least you can use the footprint generator to make the DIP8 package for it. Another bonus would be that if you change CAD packages, and your CAD package has some form of text-import feature (like EAGLE's Script Import), you can effectively take your libraries with you. Does anyone think this sounds like a good idea, or am I wasting my time? Cheers, -- Phil. ygro...@philpem.me.uk http://www.philpem.me.uk/ ------------------------------------ Please read the Kicad FAQ in the group files section before posting your question. Please post your bug reports here. They will be picked up by the creator of Kicad. Please visit http://www.kicadlib.org for details of how to contribute your symbols/modules to the kicad library. For building Kicad from source and other development questions visit the kicad-devel group at http://groups.yahoo.com/group/kicad-develYahoo! Groups Links
