Do bear in mind that KiCad is a multi platform system, so things should work on both Linux and Windows.
Andy On Sat, 12 Sep 2009 19:45:02 +0100 Philip Pemberton <ygro...@philpem.me.uk> wrote: > waynegramlich wrote: > > I think your idea is a good one. Not locking it down to a > > particular electronic CAD package is also a pretty good idea. > > It's more a convenience thing of anything, that and other people might > want to use it with e.g. Altium Designer, Mentor or OrCAD. I'd rather > like the answer to "Can I use it with <X>?" to be "Yes" for as many > values of <X> as practically possible. > > > Greg's proposal of using XML is pretty good as well. At least > > with XML, nobody argues about syntax issues anymore. In addition, > > this means additional information can be added. For example, > > some parts can be ordered from multiple vendors with different > > part numbers. With XML, adding a new tag does not break > > programs that are reading the file. > > The only (he says) problem with XML is that as a hierarchical format, > it's a bit of a pain to parse. That said, parsing is generally handled > with (say) Libxml or ElementTree/Etree, and ends up being more or less > recursive -- if you see a <Component> element, you branch off to > HandleComponentElement() for a bit, which goes looking for the various > tags it needs to build the component. > > It is a LOT more verbose than what I proposed. I'd rather have a > single-line description to create a component, than 20 or 30 lines of > text that all has to be parsed. Though all that verbosity would make it > easier to understand the source script, and I guess you could always > write a Perl, Bash or Python script to write the component script... :) > > > The concept of having a package is good one. Many parts > > come in a multitude of packages. > > Well the concept derives from something along these lines: > - Microchip, Fairchild, National and TI (for example) all make chips > in DIL packages. > - The parameters of a given type of DIL package is standardised among > these vendors. > - Why create four footprint libraries, when you can do what you need > to do with one? > > Admittedly some manufacturers do "tweak" footprints a little, but for > the most part the IC packages are standard. Actually, I seem to recall > there being an IPC standard for SMD footprints... > > > It would be nice to > > specify the part once and select the package separately. > > Pin bindings sometimes vary between parts. > > This is how EAGLE works (more or less) -- you pick a Part in the library > browser, expand it, and then you can see what footprints are available > (f.ex. the Microchip PIC18F452 is available in a -I/P (DIL) and a -I/SO > (SOIC) package). You accept the selection, then it's added to the PCB. > > The catch is that the schematic symbols and PCB footprints are part of > the same library, and you can't link a schematic symbol and pinout set > to a footprint in another library (or at least you couldn't the last > time I tried). The Part provides the link between a symbol and > > IIRC, In KiCAD "symbols" and "modules" are a separate concept, and there > is no "linking object" (the pin numbers come from the Symbol). When you > create, say, a PIC18F452-I/P symbol, you tell KiCAD that MCLR is on pin > 1, and so forth. So if you wanted to change the pin numbers to create a > PIC18F452-I/SO object, you need to copy the existing symbol. Later on, > if a change has to be made to the "symbol" as a whole, you have to > change both of them -- in EAGLE you'd edit the Symbol and both Parts > auto-update. > > I think I've explained that quite confusingly, but it's not an easy > concept to explain anyway... even with a whiteboard to hand... :) > > > More control over drill selection is a good idea. Some vendors > > use metric, others use imperial. Some have a set of "free" > > drills and charge extra for other sizes. Just being able to > > specify the minimum and maximum hole size for for each component > > lead would be a huge advance. > > Well the goal is that if your manufacturer won't take the "standard" > libraries, you regenerate them to meet your specific needs. > > > As an example of something that can be done after the > > basic infrastructure is in place, I've always wanted to do > > a screen scraper for part pricing when I'm ordering parts. > > I typically order from DigiKey, Jameco and Mouser, being > > able to figure out which vendor has the lowest price, can > > save some serious money. (Note, this would be a separate > > program that read the library file formats, fetched the > > prices from the vendors and squirted current pricing > > information into the files as addition tags.) > > I've been working on a component stock database that would do something > similar -- it keeps track of what I have in-stock at a given time. The > plan is that when I want to build something, I could import the > bill-of-materials from KiCAD, then tell the stock DB: "calculate what I > need". It would then run off, query pricing information from known > suppliers, and possibly go as far as working out quantity breaks (i.e. > "9x of part X are required, but it's cheaper to buy 10, so order 10 > instead"). > > It's a long-term project (like all my projects, or so it seems these > days)... > > 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 > > >
