Re: gEDA-user: uEDA .. was .. Re: Heavy Symbols and such

[John Doty <jpd@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user