Hi All, Dick, your improvement makes a lot of sense. I think I'm right in thinking that what my patch would do in the case of importing a 3rd party library would be to import the field names from that library, without adding the template field names . Being able to add the template field names on too is a big bonus. This briefly crossed my mind when I was doing the patch, but I didn't want to try and take on that much change in one go. I'm glad you've taken that on to improve things still further.
It sounds like it will be a great feature upgrade. Werner. I've added some comments below your message: On 14 June 2010 18:42, Werner Almesberger <[email protected]> wrote: > Dick Hollenbeck wrote: >> You seem to be especially concerned about a manufacturer field within >> the symbol becoming obsolete. > > Yes, or the field having an almost arbitrary value from a vast > set, e.g., in the "any 100 k resistor" case. > >> But for the mean time WRT template fieldnames, you are not required to >> add a "Manufacturer" field to your template fieldnames. > > Yes, I understand. Seeing all those "manufacturer" examples was > just a big red warning light popping up. Sorry for diverting the > thread. > >> One idea is that the BOM generator could maybe take a CSV file as INPUT, >> and the CSV file would map symbol value to manufacturer, vendor, and >> maybe price. > > I think CSV files would make a nice interface, particularly if > combined with some editing facilities in the BOM generator that > help to maintain referential integrity. > > This would also allow the BOM generator to be developed apart > from the main KiCad codebase, which is probably a good thing in > the long run. (And it might give me a chance to play, too :-) > > The tables that further describe parts and distributors could > be maintained outside the KiCad core. Since they're not > project-specific, they could be shared among projects and even > among users. > >> Attached is a sample output from my Java based BOM generator. The trick >> I used here is to only define the Manufacturer/Vendor once *per >> schematic* (the library is not involved). The collating pass merges all >> components sharing the same value. > > Looks very nice. How does your system know that C1 is a > TAIYO YUDEN TMK105BJ104KV-F ? > > - Werner In a commercial environment an MRP (Manufacturing Resource Planning) system is generally in place. This MRP system provides a translation from an internal company part number (CPN) to another companies orderable part number (OPN). However complicated you want that to get, it is the MRP systems job to do that work. In most commercial instances, manufacturers, manufacturer part numbers, vendors, vendor part numbers, prices (with price breaks), lead times, and all other relevant information is in the MRP system. A single CPN might well have several OPN's linked to it. The single stable number is the CPN which would be included in the schematic symbol and would not need to change when a different vendor needs to be used, or even if the part would need to be changed to a different manufacturer's alternative. All transient information about that CPN is managed in the MRP system. In a personal use case, it is much more likely that the individual will add a vendor + vendor part number. Or they might just add the manufacturer + manufacturer part number. With a low throughput of part ordering this is easily manageable for the individual. Both these cases in fact can be dealt with, and the generation of symbols will be eased for both when this work is complete. So if you have a use for transient part changes you'll need to be implementing a form of MRP which can manage this information and link it back to the stable part numbers generated from the schematic symbols. A BOM generator in KiCad should really not be over complicated. It should be able to consolidate parts that have the same CPN, and provide a total quantity for that CPN. It should do that for each unique CPN. There shouldn't be much more than that required. Usually an MRP system has a way of importing simple CSV BOM's, and all of the fancy/complicated part information handling is taken on by the MRP system. Of course, this could all seem backwards to a lot of people, this is just logical to me. The last time I brought up the subject of heavy symbol libraries on the list most people told me I was crazy! Best Regards, Brian Sidebotham. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
