Re: gEDA-user: Light? Heavy? Reuse...

[John Doty <jpd@xxxxxxxxx>]

On Jan 17, 2009, at 6:04 AM, Bob Paddock wrote:

>> We need a way to import symbols from the library to the *project*,
>> not just to the schematic. The schematic may ultimately be shared by
>> many projects, with different parts requirements.
>>
>> 2. Institutions often have preferred parts lists, stockrooms, etc. It
>> makes perfect sense for an institution to make a heavy symbol library
>> representing its preferred parts.
>
> Everyplace that I've been institutionalized *always* put this  
> information
> in the Bill Of Material.

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 schematic proper is looked at by the designer,
> maybe the person doing PCB layout if not the designer,
> a few people in the design review phase, and the technical that has  
> to repair
> the broken boards.  Three to five people at most, and not very often.

Yes. That's the real world I know. The designer is schematic-centric,  
but nobody else is.

>
> 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...

It's a one-liner in AWK to hide all value= attributes. So if that was  
an issue, I'd just make copies of the source schematics with the  
values hidden, make graphics from those, and present those to the  
reviewers. A trivial automation problem in the gEDA architecture.  
Radical flexibility.

>   Also you want absolutely nothing in
> your documentation flow, say a part going obsolete where you must  
> change
> the BOM, is going to flow back up the process to force a change in the
> schematic.

Indeed.

> 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.

>
> The BOM is going to be looked at by maybe the above people, plus
> purchasing, warehouse, sales to estimate delivery dates, production
> (board stuffing), QC for testing boards (they only look at the  
> schematics
> if something fails, and that had better be rare in your process).
> BOM is going to be looked at *every time* there is an new order
> for this widget by some part of the institution, even if is only an
> automated step, with a cursory human glance.

Yep.

>
>> The schematic may ultimately be shared by
>> many projects, with different parts requirements.
>
> The BOM by definition has to contain the correct parts for the  
> variation
> of the schematic that you are building, or it is useless.  BOM will
> always have the fully
> specified part number, or you can't order the parts..  In our work
> flows it always contains at least
> a generic footprint reference like "0603" plus a reference to a  
> fully specified
> footprint document.  Not all "0603" are the same footprint,  
> unfortunately,
> but the generic reference at least gives you some concept of size.

One customer of mine wants the BOM bound together with a copy of the  
manufacturer's datasheet for every part.

>
> In the past databases have come up as a solution to 'heavy', and that
> makes sense
> from the technical aspects, but it can't be something like a MySQL  
> server.  The
> inmates that are running IT in these institutions balk at installing
> anything with the
> word "server" in the name (I was told I was competing with them  
> when I did it,
> my system was fast and easy to use and theirs was not),
> and they sure are not going to let you contaminate "their" database
> system with footprint data
> or its ilk.  Usually the version control system is pressed into
> service because IT almost grasps why it is needed.

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.

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