kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@...>]

2009/11/13 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

Hi Dick,

I admit the first line about making a separate tool did not inspire me
much and may have detracted my attention from the rest of the mail. I
would like KiCad to support this natively, and not for me to have to
rely on various scripts I've written. It should have no negative
effects on the current working.

The company part number would be a hidden field, i.e. not printed on
the schematic. So yes, the BOM could include a field that I have
allocated as the company part number. However, this cannot be done
whilst using aliases at the moment because only the Name and Value
fields are different between aliases and the Root component.

Our company part number is just a link to our MRP (Material
Requirements Planning) system. Our purchaser can then add multiple
suppliers for any of these parts in that system (and add photos,
datasheets, and a host of other things). Our company part number never
changes once it's allocated. So there would be no need to go back and
alter these part numbers due to changing suppliers. That kind of thing
definitely does need to reside outside of KiCad.

I think Improved Component Aliasing, Separate Value/Name for symbols,
and Single File library's are all improvements for KiCad.

Perhaps I can have a think about it, and then get back with a more
concise list of tasks that would need to be done?

Best Regards,

Brian.