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. [email protected] http://www.philpem.me.uk/
