kicad-developers team mailing list archive
Mailing list archive
Re: Eeschema library editor - seperate value + name
Dick Hollenbeck <dick@...>
Fri, 13 Nov 2009 07:29:56 -0600
Thunderbird 184.108.40.206 (X11/20090817)
Brian Sidebotham wrote:
2009/11/13 Manveru <manveru@... <mailto:manveru@...>>
2009/11/13 Wayne Stambaugh <stambaughw@...
... Maybe this is where some
type of database implementation would be useful that some of
developers have suggested. That way all your local
numbers, manufacturers, vendors, cost, etc. would be
independent of the
actual component libraries themselves. If you could separate
that way or by some other method, it would probably be easier
I would like to see such functionality as separate tool - it
should allow to manage the parts inventory according to part
number and values (for discrete parts). So it should allow to
match netlist/BOM with part numbers from the suppliers with exact
part used on schematics - so you enter such data once, and you
have it. In case of library update the relation between part name
and value and suppliers part name would not change. It is worth
consider adding such tool to KiCad suite.
Going further we can imagine far future, where for example Digikey
delivers the database containing part numbers from their data base
matched to part name (standardized) and value (f.e. resistance).
This could be web service with query/response API.
jabber: manveru@... <mailto:manveru@...>
I think we are straying into the other discussion about a new symbol
library management system which is not really my intention. If it is
possible to give the ability to create heavy symbol libraries with
what KiCad already has available then I think it would be a bonus. It
should not impact anything that is done in the future with a new
symbol library management system.
Manveru's idea may be mis-understood here by you Brian. Isn't what he
is saying basically that the BOM can include these extra data fields you
need, and that they do not need to go into the schematic at all?
I hear him saying that a post processing merge into the BOM could add
fields from some other data source. That way you do not have to update
your schematic library any time you find a better price on parts
somewhere else. You simply edit your BOM generation database.
The BOM generator in Kicad is not nearly as good as it could be. I have
written one in Java that I use and it spits out a CSV which then I load
into a spreadsheet.
In any case a merge can be done on part value and name, and Manveru is
saying put this merge outside of Kicad's current scope.