DBLib with individual tables for each component type: Thoughts?

[twistedresistor]

Hi,

just wanted to hear your opinion on library organization. I'm debating using separate tables for each component type e.g. diodes, resistors, capacitors, transistors with their respecting parameters.
Basically what DigiKey does.

Right now I have one table with all components. Using fields Voltage, Current, Power, Tolerance, TempCo. This makes sense for most of the components.
The big advantage to this is, that I can display this few parameters on the BOM which allows to find alternate parts, or quickly verify the properties of the component in case the MPN is non-descriptive.

Using a individual parameter set for each type of component would allow to store more specific information, but also blow up the BOM exponentially.

What are you guys thinking? Also where do you draw the line: do you stop at IC or do you use seperate tables for opamps, ADCs, MCUs?

[ddavidebor]

It will not help you in BOM organization, the BOM columns are fixed for each project, you cannot change them depending on your table columns.

David

[nickb]

I'm using an excel file as my database (hope to switch to sql at some point) and have split up the lib in component types with their specific parameters.
In Altium it looks like separate libraries, it's probably a personal taste but I like it this way, allows for some filtering when looking for a specific component.

[Gribo]

My DB is setup with multiple tables, one per component type, however, the BOM includes only the minimum required parameters to manufacture the board (RefDes, PN, supplier, footprint etc.)
The electrical parameters appear as a single string in the description column. This way, the BOM stays neat, and most of the information is included.

[ajb]

I'm going to lazily copy and paste what I've said previously on the topic, but the TL;DR is that in my opinion putting a whole bunch of parameters into your dblib is a waste of time, and if you're not doing that then there's no point in having separate tables per component type. 

There's also a temptation to do a separate table for each part category, and put in a whole bunch of different parameters so that you can select parts parametrically when inserting parts into a design, but IME that's a huge waste of time.  I mostly just put the headline specs in the description for the part, and if I need more detail than that I have a link to the datasheet just a right click away.  Stuff that is critical to selecting a part on a basic level goes into the hierarchical type/subtype fields, so for instance I have Caps->MLCC and then dielectric is a subtype of that, so I can easily put C0G parts where I need them and cheaper dielectrics where I don't.

https://www.eevblog.com/forum/altium/how-do-you-maintain-part-categories-and-especially-sub-categories/msg1707500/#msg1707500

Even if it's quick and simple to do, both database design mentalities (super table with tons of empty columns, or tons of tables) kind of make it a royal pain. Most dblib users end up settling for a very minimal set of attributes because of that, which to me sounds like a bad compromise.

  How many attributes do you really need to keep in the library anyway?  Anything less than transcribing the entire datasheet into parameters is going to be some sort of compromise, and it's not like you can stick an operating curve into a parameter, and those can be quite important in evaluating a part's suitability.  Even if you do transcribe every single parameter, you can't always directly compare these between different parts because they may be specified under different conditions--so it's back to the datasheet anyway.  I won't tell you what works best for you, but personally I've come to the conclusion that putting anything beyond headline specifications into the library is not a good use of time no matter what sort of library you use.  When the basic specs aren't enough, that's why you have a link to the datasheet in the library.

I'll agree that Altium's dblib management tools are bad enough to not even be worth mentioning, I too have been meaning to create a DB front end (hasn't everyone?), but I just do everything in Access and don't find it appreciably more difficult or tedious than any other method of library creation.  The file paths are annoying, but for basic things like resistors it's mostly a matter of copying and pasting a row and editing a couple of fields.  For anything else it's not much more work, really, because I don't bother with more than a couple of key parameters.

https://www.eevblog.com/forum/altium/best-way-to-handle-boms-and-component-libraries-in-altium-designer/msg1070898/#msg1070898

If you just want hierarchical organization of components, you can do that by having hierarchical category fields and using those to sort in the library browser:

[warpco]

The electrical parameters appear as a single string in the description column. This way, the BOM stays neat, and most of the information is included.

Always wanted to ask. I almost have no experience in PCB design so I can be wrong. I think that specifying electrical parameters in BOM doesn't make sense. What are they needed for? To find a component on a supplier website? Nope. You use part number for this. To find a substitution if the original component is not available? Seems reasonable, but let's think deeply. What parameters determined the choice of this component? Voltage? Temperature? SOA? Sulfur-resistance? Some-weird-parameter-specified-only-on-a-sketchy-plot-in-the-datasheet?

Can you put ALL these parameters in the description? Obviously not. Can you know in advance which parameters will be important? Also not. To find a substitution you should read the datasheets and/or talk to the electronics engineer who designed the board. So why you need to specify the parameters at all? I think it's better to put more general information in the description. Something like "General purpose chip resistor", or "High precision chip resistor". This, at least, will give you an idea of which parameters are important and which are not.

[Pseudobyte]

Always wanted to ask. I almost have no experience in PCB design so I can be wrong. I think that specifying electrical parameters in BOM doesn't make sense. What are they needed for? To find a component on a supplier website? Nope. You use part number for this. To find a substitution if the original component is not available? Seems reasonable, but let's think deeply. What parameters determined the choice of this component? Voltage? Temperature? SOA? Sulfur-resistance? Some-weird-parameter-specified-only-on-a-sketchy-plot-in-the-datasheet?

Can you put ALL these parameters in the description? Obviously not. Can you know in advance which parameters will be important? Also not. To find a substitution you should read the datasheets and/or talk to the electronics engineer who designed the board. So why you need to specify the parameters at all? I think it's better to put more general information in the description. Something like "General purpose chip resistor", or "High precision chip resistor". This, at least, will give you an idea of which parameters are important and which are not.

So the benefit comes when you use a good contract manufacturer. I happen to work at a CM where we deal with a wide variety of customers who all think the way they do things is the best way (hardly so). We get BOMs in daily that have mismatched descriptions to manufacturer part numbers. We use tools in house to scrub BOMs for these discrepancies. I cannot count how many engineers have thanked us for catching these issues. In many occasions the description is correct but the part number is wrong. When you have the description as its own field you add another way to ensure your assembly is being built correctly. If you did not include description information you are setting yourself up for having the wrong parts on your board.

If you have no description the CM will buy the PNs you put down on your BOM. That is okay as long as you as an engineer are confident that each MFG-PN corresponds to the right component you chose for your design. I know too many designers that like to quick change component value information on the schematic and not update the part number (you are setting yourself up for failure if you do this)

Also descriptions that include mismatched footprints for the actual package size of the part number are a good example too. We catch many of these issues.

[Bassman59]

So the benefit comes when you use a good contract manufacturer. I happen to work at a CM where we deal with a wide variety of customers who all think the way they do things is the best way (hardly so).

So as a CM, what should we (the board designers) provide to you to ensure that we get boards built correctly? I'm genuinely interested.

[Pseudobyte]

Files:
BOM
Gerbers & NC Drill
ODB++
Assembly Drawing top and bottom
Fabrication Drawing
Schematic PDF
Pick and Place Data

Nice to have: 3D PDF, bookmarked assembly drawings

BOM Fields to include:
QTY, Designators, Description, MFG-PN, MFG, Populate, Footprint

As far as the description field is concerned you should include:
package size and any critical part parameters (value, tolerance, coefficient, temp range, pin count, etc.)

Another note:
Do not omit placement data for non-populated components. This information should be conveyed via BOM only. This is important if your CM uses AOI technology. Making sure you placed the correct parts is only one part of the equation, you also need to make sure that you don't place parts where they shouldn't be.

[Ice-Tea]

I tend to color key BOMs:

GREEN: CM may substitute for component of equal rating (example a 10uF 16V X7R)
ORANGE: CM may substitute for component but must seek permission
RED: CM may not substitute under any circonstance, full MPN only

Pseudobyte, how do you feel about that?

[warpco]

I tend to color key BOMs

Don't know about Pseudobyte, but I like this idea. No matter with or without critical part parameters in description field, color marking can be really helpful. Also, you can make it more clear (to my mind) by using additional column in a BOM table instead of color marking. Something like "replaceability" column with three possible values: "Allowed", "Upon request", and "Not allowed".

[Pseudobyte]

I tend to color key BOMs:

GREEN: CM may substitute for component of equal rating (example a 10uF 16V X7R)
ORANGE: CM may substitute for component but must seek permission
RED: CM may not substitute under any circonstance, full MPN only

Pseudobyte, how do you feel about that?

It wouldn't be a bad idea. At my place of business it wouldn't matter. Customer BOM is gospel, any deviation is documented and approved by our customers. So if we wanted to substitute parts because the part you selected is unavailable we would ask you to approve any change or select the new part yourself.

[Ice-Tea]

So if we wanted to substitute parts because the part you selected is unavailable we would ask you to approve any change or select the new part yourself.

You're going to make a lot of friends here...

[Bud]

I tend to color key BOMs

Don't know about Pseudobyte, but I like this idea. No matter with or without critical part parameters in description field, color marking can be really helpful. Also, you can make it more clear (to my mind) by using additional column in a BOM table instead of color marking. Something like "replaceability" column with three possible values: "Allowed", "Upon request", and "Not allowed".

I'd prefer text. A colored spreadsheet will be hard on the eyes if you sort it by a parameter other than color key.

[Ice-Tea]

It's supposed to be hard on the eyes. None of the 'oh, didn't see that' rubbish. 

[VK3DRB]

As far as the description field is concerned you should include:
package size and any critical part parameters (value, tolerance, coefficient, temp range, pin count, etc.)

Another useful field to include is VERIFIED. That means the component has been verified as having the correct footprint. Verified means it is only "good" after you receive a PCB with the component on it, the CM has no issues, and it tests OK. That means you can use verified components on other designs with a high level of confidence. The reason I say this is one company I worked for some years ago had a few bad footprints polluting the libraries, causing mistakes on more than one PCB. The company was poorly managed, with "one country, two systems" of libraries... two teams that did not trust each other and kept their own libraries, duplicating a lot of effort.

Another note:
Do not omit placement data for non-populated components. This information should be conveyed via BOM only. This is important if your CM uses AOI technology. Making sure you placed the correct parts is only one part of the equation, you also need to make sure that you don't place parts where they shouldn't be.

Use Variants - a very powerful tool that not many are aware of, unfortunately. Then the "not fitted" components do not appear in the BOM or pick 'n place tables. And it is as clear as daylight on the schematic.