Since there's more focus on the BOM recently, I thought I'd share a use case that shows what one can do with the existing BOM: for gta02-core, I've written an external BOM processing system that associates BOM entries with items from inventories and generates "shopping lists" optimized for volume discounts.
Inventories tell the system where a certain part can be obtained and at what price. E.g., a distributor's catalog or local stock. To match parts, the system uses various strategies. If the value matches a part's ID, that part is taken. If not, a user-provided set of substitution rules is applied. Then a value match is attempted again. If we still have no part, the system tries to match characteristics. For this, the rules determine what kind of part we have (e.g., a resistor), then extract the characteristics given in the schematics (e.g., R = 4.7 kOhm), and provide defaults for those not given (e.g., tolerance <= 5%). With this information, it searches tables that list the characteristics of parts. There are also equivalences. Those can be equivalent parts, e.g., the same chip from a second source; different names of the same part, e.g., a vendor's and a distributor's part number; if you wish, project-specific substitutions of not truly equivalent parts; etc. Last but not least, parts can also have a textual description, which appears in the "shopping list" and which can be used to make crudely annotated schematics that show for each component what part has been selected (for review.) The workflow (with a few project-specific extras): http://people.openmoko.org/werner/gta02-core/bom-workflow.pdf The BOM processing system: http://svn.openmoko.org/trunk/eda/boom/ A project-specific environment: http://svn.openmoko.org/trunk/gta02-core/bom/ An example of a "shopping list": http://svn.openmoko.org/trunk/gta02-core/orders/ee-bom-fic-20100208.txt An example of the annotated schematics: http://people.openmoko.org/werner/gta02-core/gta02-core-bom-all.pdf If you're looking for reasons not to like it, here are a few: - it's all written in Perl, - to tie things together for a project, you use a Makefile (1), - the substitution rules are vaguely inspired by sendmail.cf (2), - the "user interface" is made up of the command line and your text editor. There are also some misfeatures in the functionality, e.g., it's blissfully ignorant of shipping cost, lead time, etc. (1) The one we have is about as bad as it gets: http://svn.openmoko.org/trunk/gta02-core/bom/Makefile Some of the more obscure bits, like INTERPRETATION, exist to deal with a number of idiosyncrasies I wouldn't wish on any other project. (2) Well, I wimped out on the syntax: http://svn.openmoko.org/trunk/gta02-core/bom/gta02-core.sub Now, this is a system that's flexible enough to handle complex projects. It's fully automated, so changes in the schematics propagate all the way to the shopping lists without any user intervention. (That is, unless you need to introduce new parts or such.) Its functionality and complexity probably goes beyond what you'd want to have live inside KiCad, but the BOM export provides all the data this needs from KiCad. (Field names will be a nice improvement, taking some of the guesswork out of the substitutions.) - Werner _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
