[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Parts DB API



On Dec 19, 2007, at 6:18 AM, Peter TB Brett wrote:

> On Wednesday 19 December 2007 12:48:55 DJ Delorie wrote:
>>> For the time being, however, I don't see any reason not to stick to
>>> using some sort of external helper programs for actually accessing
>>> the database, as long as we can get the UI and basic Scheme API
>>> nailed down.
>>
>> I've argued in the past that gattrib should be responsible for
>> attributes, not gschem.
>
> This would be nice, if not for some important points:
>
> 1. gattrib is, sadly, a bit unstable, and not particularly new-user- 
> friendly
>    IMHO.
>
> 2. When designing schematics, quite often you need to shift  
> backwards and
>    forwards between attribute editing/part selection and placing/ 
> moving
>    components.  You can't edit a schematic with gattrib & gschem at  
> the same
>    time, so this involves lots of time-wasting & irritating "Save,  
> close,
>    open" cycles.
>
> 3. With what you're suggesting, you can't look at the schematic & edit
>    attributes at the same time without the hassle of printing the  
> schematic
>    out.
>
> Secondly, I object strongly to the idea of using a BOM as a master  
> document.
>
> 1. How do you cope with the designer deleting a component and then  
> renumbering
>    the ones that are left?

It really needs to be a two layer process.

Consider that a design might contain a bunch of chips, each with a  
bypass capacitor. Now, for sanity, it makes a lot of sense to use the  
*same* bypass capacitor device throughout the design. However, what  
if you need to change it?

The manufacturer may stop making the specific part you chose.

The customer may want their favorite part in there.

You may want to shrink the board by changing them all from 0603's to  
0402's.

Etc.

However,

gattrib is no good for wholesale changes.

Editing the sch files isn't for everyone, and how do you single out  
the bypass caps?

Embedded symbols are a disaster here.

Etc.

The answer, right now, is that you laboriously copy your favorite  
light capacitor symbol to your project library, rename it something  
like "bypasscap.sym", and make it heavy. You have to go through that  
pain when you place your first symbol, or it's going to be a bigger  
pain later. But wouldn't a project parts database be better? Use a  
light symbol, attach a single attribute identifying it to your parts  
database, and put the rest of the attributes there.

That's what I think of as BOM-centric design. Behind the printed BOM  
there would be two sets of relations: refdes->stock-id (from the  
schematic) and stock-id->attributes (from the database).


>
> 2. How do you do design re-use?

For one thing, you avoid embedded symbols. They are poison for re-use.

>
> 3. It adds even further to the bundle of files you have to send to  
> someone,
>    and which they have to artfully arrange in their filesystem, if  
> you want to
>    share your schematics with others.

Conventions for how the bundle is to be structured would help. But  
the bundle is much more manageable than a single file where re-use is  
concerned.

>
>
>                                       Peter
>
>
> -- 
> Peter Brett
>
> Electronic Systems Engineer
> Integral Informatics Ltd
>
>
> _______________________________________________
> 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