> Yes. But let's distinguish between the design data (the "source > files" for the design) and the BOM, which is a report generated from > these files.
The BOM can contain much more than just the gEDA/PCB based files. It may mounting hardware, enclosures, notes, warnings (see below) etc. > > Also in a project where there is government approvals involved you > > want as little detail as possible in the schematic, be generic (MSHA does > > not even want to see values on the schematic. Need a way to turn that > > 'layer' of > > information off when making one for them). > > Never heard of that one, but... http://www.wearablesmartsensors.com/msha_rules.html : FAQ: 2.1) What are some common administrative drawing omissions that lead to discrepancy letters and approval delays? 8 a. Not putting the MSHA warning note "Do not change without approval of MSHA" on each page of every drawing and each *page* of a parts list or bill of material for Part 18 approval applications. ... d. Illegible or partially legible drawings, sometimes due to print quality and other times due to excessive drawing reduction where nomenclature is too small to read. [That one frequently makes me consider XCircuit, but XCircuit is not that great at producing netlists.] 2.6) I want to maximize my ability to make post-approval design changes without having to submit them for MSHA approval. How can I configure my drawings to allow flexibility for future changes? ... One way to reduce evaluation time is to avoid submitting drawings containing duplicate or unnecessary information. MSHA investigators must compare the submitted drawings with a sample unit to ensure the unit is assembled according to the submitted drawings. The more unnecessary information that is submitted, the more time must be spent comparing components on the sample unit to the drawings. An example where time is wasted is when a detailed electrical parts list and a schematic are submitted with component values and specifications. A cross check then has to be made comparing the parts list with the schematic. Many times discrepancies are found where the component values don't agree. It is better to either put all of the electrical parts list information on the schematic diagram or to leave all parts values off of the schematic and only list them on the electrical parts list. > It's a one-liner in AWK to hide all value= attributes. For you or I or most everyone here, yes. However there may very well be people that simply want to use the tool to get a task done, and have zero interest in figuring out what a attribute is, or where it might be located, or why they should care. > A trivial automation problem in the gEDA architecture. > Radical flexibility. Which can lead to a paralyzing inability to use it. Anything that does limit flexibility is bad. That flexibility should not prevent methods from being built into the tools. > > The fewer documents that change, the less problems you have with > > updating your project with "Them", and less expense. Change *anything* in > > submitted documents with MSHA and your looking at least $1000 bucks. > > That's another reason why, in the gEDA architecture, it makes great > sense to maintain the information that will generate the BOM in > project-specific "heavy" symbols. To a degree. Say you have a Second-Source alternative that fulfills "form, fit, function". You don't really want to have two heavy symbols in your schematic, so that either can be used. Also that can again force a change in your schematic that would be otherwise unnecessary when a part does go obsolete, but a new "form, fit, function" one becomes available. > One customer of mine wants the BOM bound together with a copy of the > manufacturer's datasheet for every part. I do that for every project I design for the inevitable day when something goes obsolete or someone buys out someone else and changes the part numbers. I've run into cases when a manufacture obsoletes a part, they remove the part from their website. You still need to have the original data to figure out the replacement. > Just about every project I do has a software component, too. Given > that the gEDA formats work well with common version control systems, > it makes sense to go that route for both hardware design and software. Yes. The call to the heavy-mass provider should not make any assumptions about where the mass is being stored or how. Send out a request, get back a response, via an API. _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
