On Dec 7, 2007, at 4:08 PM, Steve Meier wrote: > John Doty wrote: >> The interesting idea so far in this discussion has been to let the >> BOM be source rather than product. >> >> > Dang, That was the idea I intentionally left out of my last diatribe. > And you cut right to it. I agree, that the world being bom specific as > opposed to schematic specific is interesting even if i havn't got a > clear vission oh what being bom specific means. I was going to ask, > that > does being bom specific mean.... that we build new designs with an a > bias to the components we already have?
That's one consequence. But consider what happened to me yesterday: I had made up a 100 slot symbol representing one pin of a 100 pin connector. I had two of these connectors in a design, with pins spread over many pages. So far so good. But yesterday, I got a look at the space (in a vacuum chamber) where these boards need to fit. It wasn't as previously described to me, and it really needed a somewhat different connector with a different part number and footprint. OK, now what? It's only two parts, but it's a *lot* of symbols I had to track down and fix. Fortunately, there were no others with that device= or footprint= attribute, so a multi-file global search and replace in nedit did the trick. The joys of text files: thanks, Ales. But what if I'd needed to fix one connector, but not the other? The way we have it now, part attributes are attached to symbols. But symbols aren't parts, so that's wrong. And often, attributes should be common to many parts of the same type. Right now, we, by default, reference light symbols in a common library, and then attach attributes to them. That's wrong, too: if I'm going to use a bunch of, say, OP220's in a design, I want all of them to have the same package and temperature spec. So, right now, I want to reference an editable heavy symbol here. I want neither the library symbol nor a bunch of separate embedded instances (hear that Peter? At best, your scheme gives me a separate instance per page. No good in a multipage schematic). But maybe the heavy symbol approach isn't right either. Right now, the mechanics of browsing the libraries for a graphic, copying that to your project library, rescanning symbols to make it visible (arrrggh!), and then finally picking and placing it and going down into it to fix it up are clumsy. But if you don't do that, you may be in trouble down the road when you need to change a footprint or something. Or when somebody "fixes" a common library symbol in the next release. The place where this all comes together is the BOM: that's where all of the non-graphical information about the parts is. But right now, we derive that from the graphics. That's wrong, too: the graphics should represent graphical aspects of the design. Symbols and their connections. But the graphics are an inefficient place to control and edit the textual aspects of the design. Another thing to cogitate on is textual netlist input. In the old Viewlogic days, I sometimes made text files that were pin maps for connectors. Pin number to net name. I had awk scripts that could merge them with Viewlogic's text netlist format, and also make tbl/ troff pages for documentation. Very handy. But in gEDA we have many different netlist output formats, and the only netlist input format is .sch. > > Seems like the purchasing department/ inventory management groups > might > like the idea? > > I would rather find a way to describe a problem economically... The > cost > of using one component over another as long as the availability and > capability of the componet doesn't become an issue, should determine > the selection of the component. > > Or, should the potential future cost of a component be includded in > the > selection of what goes into the new design? > > You have heard the joke that if you took all the economists in the > world > and lined them up head to foot they would not reach a conclussion? > > Hey add hardware engineers debating the meritts of languages to that > last thought ;) > > Steve Meier > > > _______________________________________________ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user