What is the correct approach to creating library of similar parts?

[matrixofdynamism]

When coming to components like LEDs, resistors, capacitors e.t.c there are throngs of manufacturers and suppliers that provide parts that are very similar from PCB design perspective i.e the schematic symbol and footprint. What approach then does one take when designing parts libraries?

Lets take an example, lets say I have a 0805 SMD resistor. Its schematic symbol will be the same regardless of the actual resistor resistance value. There are throngs of manufacturers that manufacture this type of resistor and the physical dimensions of the part and the pad to solder it onto, are going to be almost identical or be so similar that a single footprint can be used for all the parts regardless of who manufactures it.

Now from library design perspective, do we create a different schematic symbol for each manufacturer part number which can change based on the value of resistance and then also create a whole lot of foot prints to match the dimensions of every single manufacturer, or take a simpler approach? If so, what is the simpler approach going to be?

If there is a separate schematic symbol ceated for every single component, then what happens if we need to make a change that applies to all of them? That would mean having to change hundreds or even thousands of schematic symbols.

Here are some LEDs that I need to put into my Altium library for the project. They are all in 1206 package. How do I go about creating the library for these?

inolux

    LED AMBER CLEAR 1206 SMD (IN-S126ATA)
    LED GREEN CLEAR 1206 SMD (IN-S126ATG)
    LED RED CLEAR 1206 SMD (IN-S126ATR)

visual-communications-company-vcc

    LED GREEN DIFFUSED 1206 SMD (CMD15-21VGD-TR8)
    LED RED CLEAR 1206 SMD (CMD11-21VRC-TR8)
    LED YELLOW DIFFUSED 1206 SMD (CMD15-21VYD-TR8)

lumex-opto-components-inc

    LED RED CLEAR 1206 SMD (SML-LX1206SIC-TR)
    LED GREEN CLEAR 1206 SMD (SML-LX1206GC-TR)

bivar-inc

    LED YELLOW CLEAR 1206 SMD (SM1206NYC-IL)
    LED GREEN CLEAR 1206 SMD (SM1206GC-IL)

[T3sl4co1l]

Altium doesn't care, you are course free to do it however you like.

The three schools are something like:

1. Generic parts.  Add the supplier info on the schematic.  Never update from libraries.

2. Library part per component type / supplier / etc.  Quite tedious, but can be justified when extensive reuse is made -- if you're making dozens of designs per year, say, this can be worthwhile.  Can make BOM/alt changes on library level and push to SCH*.

3. Library part per database item.  Optional, integrate with inventory database to obtain part, availability and other BOM data (including preferred and alternative parts) on placement, or live on BOM generation.  This is the "enterprise grade" solution, a lot of work to set up but it means your production chain is better prepared, from start to finish, with selecting, procuring and storing parts for whatever comes through.

For my part, as a small design shop, I use #1 for most things, with #2 when it's specific parts with few alts, mainly ICs.

*Mind that updating SCH removes any specific attributes you've set, so can screw up things like comments, text label positioning/formatting, etc.  Another reason I prefer not to do it.

And you can always go back and copy-paste from some other design, if you've used a particular part before, to avoid entering its data again.  (Not like it's a copyright/IP concern, those aren't nearly so fine-grained, component/block reuse is absolutely normal.)

Tim

[ajb]

I'd strongly recommend DBLibs, even for a single designer situation.  It's the easiest way (possibly with the exception of Nexus/Altium365, I haven't messed with those) of getting a consistent set of symbols and footprints across all of your parts, and generally the easiest way to manage a library.  You can define one 1206 LED footprint, one LED symbol, and then define as many database entries as you have parts, all referencing the same symbol and footprint.  If you need to change the symbol or footprint, just do that once in the source libraries and then do an update in your project. The database can be an Excel file, an Access database, or a full-blown SQL server. The database can include whatever parameters you want.  There have been a handful of threads on here about how to set up the database most effectively, if you do a search here for 'dblib' they should pop up.

When it comes to parts that are effectively interchangeable, you can either:

- Have multiple database entries, one per manufacturer part
- Have one database entry with multiple  sequentially numbered 'Manufacturer' and 'Manufacturer Part Number' fields in your database
- Have one database entry, and just add the manufacturer part options in a list

The first of those options would be kind of a big pain, so I wouldn't recommend it.  The second option works fine, but can add up to a lot of fields to wrangle, both in the database and in the BOM outjobs, and to communicate to a CM.  The third option is what I've been doing, since it's easy to spit that list out into a BOM and tell the CM 'these are the acceptable parts for this position'. 

[free_electron]

I'd strongly recommend DBLibs, even for a single designer situation.

<-this. a simple excel or ms access ( if you have it) file will do.
basic one-to-many concept. draw a symbol once, draw a footprint once and refer to them from within the database table.
That's what the big systems do as well (like Altium vault).

[DeanA]

I'd strongly recommend DBLibs, even for a single designer situation.  It's the easiest way (possibly with the exception of Nexus/Altium365, I haven't messed with those) of getting a consistent set of symbols and footprints across all of your parts, and generally the easiest way to manage a library.  You can define one 1206 LED footprint, one LED symbol, and then define as many database entries as you have parts, all referencing the same symbol and footprint.  If you need to change the symbol or footprint, just do that once in the source libraries and then do an update in your project. The database can be an Excel file, an Access database, or a full-blown SQL server. The database can include whatever parameters you want.  There have been a handful of threads on here about how to set up the database most effectively, if you do a search here for 'dblib' they should pop up.

When it comes to parts that are effectively interchangeable, you can either:

- Have multiple database entries, one per manufacturer part
- Have one database entry with multiple  sequentially numbered 'Manufacturer' and 'Manufacturer Part Number' fields in your database
- Have one database entry, and just add the manufacturer part options in a list

The first of those options would be kind of a big pain, so I wouldn't recommend it.  The second option works fine, but can add up to a lot of fields to wrangle, both in the database and in the BOM outjobs, and to communicate to a CM.  The third option is what I've been doing, since it's easy to spit that list out into a BOM and tell the CM 'these are the acceptable parts for this position'.

Thanks ajb,

Your approach is exactly how I would like to setup my company database and dblib.  Can you outline a little bit more how your database is structured? Is it MS access database you are using?  Can you show an example of the kind of BOM you generate to send to the CM?  How do you generate the BOM, from within Altium or a report from the databsae?

[ajb]

I'd strongly recommend DBLibs, even for a single designer situation.  It's the easiest way (possibly with the exception of Nexus/Altium365, I haven't messed with those) of getting a consistent set of symbols and footprints across all of your parts, and generally the easiest way to manage a library.  You can define one 1206 LED footprint, one LED symbol, and then define as many database entries as you have parts, all referencing the same symbol and footprint.  If you need to change the symbol or footprint, just do that once in the source libraries and then do an update in your project. The database can be an Excel file, an Access database, or a full-blown SQL server. The database can include whatever parameters you want.  There have been a handful of threads on here about how to set up the database most effectively, if you do a search here for 'dblib' they should pop up.

When it comes to parts that are effectively interchangeable, you can either:

- Have multiple database entries, one per manufacturer part
- Have one database entry with multiple  sequentially numbered 'Manufacturer' and 'Manufacturer Part Number' fields in your database
- Have one database entry, and just add the manufacturer part options in a list

The first of those options would be kind of a big pain, so I wouldn't recommend it.  The second option works fine, but can add up to a lot of fields to wrangle, both in the database and in the BOM outjobs, and to communicate to a CM.  The third option is what I've been doing, since it's easy to spit that list out into a BOM and tell the CM 'these are the acceptable parts for this position'.

Thanks ajb,

Your approach is exactly how I would like to setup my company database and dblib.  Can you outline a little bit more how your database is structured? Is it MS access database you are using?  Can you show an example of the kind of BOM you generate to send to the CM?  How do you generate the BOM, from within Altium or a report from the databsae?

If you search for 'dblib' on this forum you'll find threads where I and others have described our database systems.  I use an Access database, with four hierarchical category fields to enable sorting in Altium's component browser.   I do not put part-specific parameters beyond basic value, tolerance, and in the case of capacitors the dielectric in as database fields, because IMO that's a waste of time.  Headline specs for the part get added to the description field, and if those aren't enough then there's a link to the datasheet (done per Altium's schema, these links appear as right click options on the part symbol in the schematic).  I use an Altium outjob to create my CM BOMs using an Excel template.  I have a database field for alternate part numbers which is just a list of entries in the format `Manufacturer: Part Number`, that ends up on the BOM so that the CM has approved alternates right there.  You can include whatever other fields you want in the database, like internal part numbers, lifecycle info, normalized purchase cost, etc. Really the sky is the limit when you've got a full database as the back end, and you can do whatever tie in to other systems (like company ERPs) you want. 

[ajawamnet]

I've used this approach for decades:
http://www.ajawamnet.com/ajawamnet/parts/parts.htm

A 10K 0603 5% resistor is simply called out as 10K-06 comment  on the schematic. No additional parameters required, just the two key fields - 1. the ref des, and 2. the Comment field. A simple CSV output in the outjob is all it takes. 

With Altium, the lighter the load the better. So this puts little strain on it, since the libraries are smaller and more manageable.

As I outline - quite a few benefits to this approach. One is that my clients have the ability to incorporate my work into their MRP for the entire product.  They can easily address supply chain/EOL issues with Approved Vendor List (AVL) .

[DeanA]

I've used this approach for decades:
http://www.ajawamnet.com/ajawamnet/parts/parts.htm

A 10K 0603 5% resistor is simply called out as 10K-06 comment  on the schematic. No additional parameters required, just the two key fields - 1. the ref des, and 2. the Comment field. A simple CSV output in the outjob is all it takes. 

With Altium, the lighter the load the better. So this puts little strain on it, since the libraries are smaller and more manageable.

As I outline - quite a few benefits to this approach. One is that my clients have the ability to incorporate my work into their MRP for the entire product.  They can easily address supply chain/EOL issues with Approved Vendor List (AVL) .

Thank you for that.  I'm investigating a very similar approach with a dblib and Access database backend which will basically just have a Part Master table linked to a Part-Manufacturer Table so I can generate BOMs that list the parts showing the approved Manufacturer(s) and Manufacturer Part Number(s) for each part.