kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

Hi All,

Dick, your improvement makes a lot of sense. I think I'm right in
thinking that what my patch would do in the case of importing a 3rd
party library would be to import the field names from that library,
without adding the template field names . Being able to add the
template field names on too is a big bonus. This briefly crossed my
mind when I was doing the patch, but I didn't want to try and take on
that much change in one go. I'm glad you've taken that on to improve
things still further.

It sounds like it will be a great feature upgrade.

Werner.

I've added some comments below your message:

On 14 June 2010 18:42, Werner Almesberger <werner@xxxxxxxxxxxx> wrote:
> Dick Hollenbeck wrote:
>> You seem to be especially concerned about a manufacturer field within
>> the symbol becoming obsolete.
>
> Yes, or the field having an almost arbitrary value from a vast
> set, e.g., in the "any 100 k resistor" case.
>
>> But for the mean time WRT template fieldnames, you are not required to
>> add a "Manufacturer" field to your template fieldnames.
>
> Yes, I understand. Seeing all those "manufacturer" examples was
> just a big red warning light popping up. Sorry for diverting the
> thread.
>
>> One idea is that the BOM generator could maybe take a CSV file as INPUT,
>> and the CSV file would map symbol value to manufacturer, vendor, and
>> maybe price.
>
> I think CSV files would make a nice interface, particularly if
> combined with some editing facilities in the BOM generator that
> help to maintain referential integrity.
>
> This would also allow the BOM generator to be developed apart
> from the main KiCad codebase, which is probably a good thing in
> the long run. (And it might give me a chance to play, too :-)
>
> The tables that further describe parts and distributors could
> be maintained outside the KiCad core. Since they're not
> project-specific, they could be shared among projects and even
> among users.
>
>> Attached is a sample output from my Java based BOM generator.  The trick
>> I used here is to only define the Manufacturer/Vendor once *per
>> schematic* (the library is not involved).  The collating pass merges all
>> components sharing the same value.
>
> Looks very nice. How does your system know that C1 is a
> TAIYO YUDEN TMK105BJ104KV-F ?
>
> - Werner

In a commercial environment an MRP (Manufacturing Resource Planning)
system is generally in place. This MRP system provides a translation
from an internal company part number (CPN) to another companies
orderable part number (OPN). However complicated you want that to get,
it is the MRP systems job to do that work.

In most commercial instances, manufacturers, manufacturer part
numbers, vendors, vendor part numbers, prices (with price breaks),
lead times, and all other relevant information is in the MRP system. A
single CPN might well have several OPN's linked to it. The single
stable number is the CPN which would be included in the schematic
symbol and would not need to change when a different vendor needs to
be used, or even if the part would need to be changed to a different
manufacturer's alternative. All transient information about that CPN
is managed in the MRP system.

In a personal use case, it is much more likely that the individual
will add a vendor + vendor part number. Or they might just add the
manufacturer + manufacturer part number. With a low throughput of part
ordering this is easily manageable for the individual.

Both these cases in fact can be dealt with, and the generation of
symbols will be eased for both when this work is complete.

So if you have a use for transient part changes you'll need to be
implementing a form of MRP which can manage this information and link
it back to the stable part numbers generated from the schematic
symbols.

A BOM generator in KiCad should really not be over complicated. It
should be able to consolidate parts that have the same CPN, and
provide a total quantity for that CPN. It should do that for each
unique CPN. There shouldn't be much more than that required.

Usually an MRP system has a way of importing simple CSV BOM's, and all
of the fancy/complicated part information handling is taken on by the
MRP system.

Of course, this could all seem backwards to a lot of people, this is
just logical to me. The last time I brought up the subject of heavy
symbol libraries on the list most people told me I was crazy!

Best Regards,

Brian Sidebotham.