kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

Brian Sidebotham wrote:
> 2009/11/13 Manveru <manveru@... <mailto:manveru@...>>
>
>
>
>
>
> 2009/11/13 Wayne Stambaugh <stambaughw@...
> <mailto:stambaughw@...>>
>
>
> ... Maybe this is where some
> type of database implementation would be useful that some of
> the other
> developers have suggested. That way all your local
> information, part
> numbers, manufacturers, vendors, cost, etc. would be
> independent of the
> actual component libraries themselves. If you could separate
> it out
> that way or by some other method, it would probably be easier
> for other
> to accept.
>
> Wayne
>
>
> 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.
>
> --
> Manveru
> jabber: manveru@... <mailto:manveru@...>
> gg: 1624001
> http://www.manveru.pl
>
>
> Hi 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.

Dick


> Best Regards,
>
> Brian.