On Jan 21, 2009, at 10:58 AM, DJ Delorie wrote:
>
>>> Certainly a good idea, except that it doesn't offer a way to feed-
>>> back
>>> to gschem for things that the user *must* (in their opinion) select.
>>> For example, what resistor values are available? In what
>>> tolerances?
>>> If you pi
So to take this adding too much complexity argument to street and
shoot it.
if we have plugins, this is simplified.
if a plugin can register a hook on a component place, this can call
an interface to the Data On Materials (DOM) database.
For those who only think of mySQL when program
> > Certainly a good idea, except that it doesn't offer a way to feed-back
> > to gschem for things that the user *must* (in their opinion) select.
> > For example, what resistor values are available? In what tolerances?
> > If you pick a 10uF capacitor at 10v, what's the smallest package it
> >
On Jan 21, 2009, at 12:43 AM, DJ Delorie wrote:
>
>> It seems to me you're arguing for a plugin mechanism for gnetlist,
>> too.
>
> Perhaps, or something more global. I.e. it would be nice if you
> *could* query these extra databases from within gschem or gattrib, for
> example, to see what the
On Jan 21, 2009, at 6:19 AM, Stephan Boettcher wrote:
>
> How about a new application, gbom, similar to gattrib, that allows
> entry of a BOM.
Please, let's not turn a clean flow into a tangle.
There are two entities here: the BOM, which is output, and should
hardly ever be edited directly (l
How about a new application, gbom, similar to gattrib, that allows
entry of a BOM.
gbom would import attributes from a schematic and the engineer could
fill all the remaining fields, with the help of matches in a
database.
gnetlist shall merge the bom with the schematic.
The database defines wh
> It seems to me you're arguing for a plugin mechanism for gnetlist,
> too.
Perhaps, or something more global. I.e. it would be nice if you
*could* query these extra databases from within gschem or gattrib, for
example, to see what the inferred attributes are, or to see what the
options are so
On Jan 19, 2009, at 7:47 PM, DJ Delorie wrote:
>
>> If BOM is the central place of information, then it may be very
>> useful to have a way to transfer some information back into
>> schematics or pcb file. For example we may change value or footprint
>> in the BOM and want to transfer this inform
> If BOM is the central place of information, then it may be very
> useful to have a way to transfer some information back into
> schematics or pcb file. For example we may change value or footprint
> in the BOM and want to transfer this information back to
> schematic. Is there a method available
On Sat, 2009-01-17 at 08:04 -0500, Bob Paddock wrote:
> >
> > 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 *alway
On Jan 17, 2009, at 4:38 PM, Bob Paddock wrote:
>> You don't need to change the schematic. One way to do this is to keep
>> a directory of second source symbols.
>
> That presupposes that you know the second source when you are working
> on the project. Part might be obsoleted years from now.
>
On Jan 17, 2009, at 7:38 PM, Bob Paddock wrote:
>> You don't need to change the schematic. One way to do this is to keep
>> a directory of second source symbols.
>
> That presupposes that you know the second source when you are working
> on the project. Part might be obsoleted years from now.
>
On Jan 17, 2009, at 6:40 PM, John Luciani wrote:
> When I had to send my schematic to a layout group I created a script
> that made a single pdf file containing the schematics, a bom and
> embedded pdf datasheets for each part. Each bom line item was
> a hyperlink to the embedded datasheet. When
> You don't need to change the schematic. One way to do this is to keep
> a directory of second source symbols.
That presupposes that you know the second source when you are working
on the project. Part might be obsoleted years from now.
New second source symbol would have to be created when
a pa
On Jan 17, 2009, at 6:27 PM, Bob Paddock wrote:
>>
>> 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 fulfill
On Jan 17, 2009, at 6:27 PM, Bob Paddock wrote:
>> 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 at
On Sat, Jan 17, 2009 at 5:11 PM, John Doty wrote:
>
> On Jan 17, 2009, at 6:04 AM, Bob Paddock wrote:
>>
>>> 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 s
> 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.
> > Als
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
> 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 inst
Ales surprised me at the code sprint by calling me a "heavy symbol"
advocate. Let me try to make clear my real position.
The question is not "light" versus "heavy", but where to put the
"mass" so it doesn't become a burden, especially for design reuse.
The more I use gEDA, the more this is a
21 matches
Mail list logo
