Author Topic: DBLib with individual tables for each component type: Thoughts?  (Read 491 times)

0 Members and 1 Guest are viewing this topic.

Offline twistedresistor

  • Contributor
  • Posts: 37
  • Country: 00
DBLib with individual tables for each component type: Thoughts?
« on: October 09, 2019, 07:04:43 am »
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?
 

Offline ddavidebor

  • Super Contributor
  • ***
  • Posts: 1135
  • Country: it
    • Fermium LABS website
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #1 on: October 09, 2019, 12:36:09 pm »
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
Davide Bortolami,
Fermium LABS srl
 

Offline nickb

  • Contributor
  • Posts: 7
  • Country: be
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #2 on: October 09, 2019, 02:02:16 pm »
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.
 

Offline Gribo

  • Frequent Contributor
  • **
  • Posts: 420
  • Country: ca
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #3 on: October 11, 2019, 04:18:53 pm »
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.
 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 1681
  • Country: us
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #4 on: October 11, 2019, 04:41:54 pm »
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. 

Quote
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

Quote
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:

 

Offline warpco

  • Contributor
  • Posts: 11
  • Country: ru
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #5 on: October 24, 2019, 08:30:22 pm »
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.
 

Offline Pseudobyte

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #6 on: October 29, 2019, 02:54:44 pm »
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.
« Last Edit: October 29, 2019, 02:56:19 pm by Pseudobyte »
“They Don’t Think It Be Like It Is, But It Do”
 
The following users thanked this post: warpco

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1265
  • Country: us
  • Yes, I do this for a living
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #7 on: November 06, 2019, 05:53:29 pm »
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.
 

Offline Pseudobyte

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #8 on: November 06, 2019, 09:07:29 pm »
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.

“They Don’t Think It Be Like It Is, But It Do”
 

Offline Ice-Tea

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: be
    • Freelance Hardware Engineer
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #9 on: November 06, 2019, 09:31:51 pm »
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?
eBay shop with all the gear you need!
FS: Agilent 54825A, R&S CMU200, CRTU, SMIQ06L, Marconi 6201B, Lecroy WP 950, 9354TM, 9354M, 9374L LC584A, Tek THS720P, TDS7154B, Anritsu MG3671A 2.75G I/Q RF gen, Keithley 238 SMU, HP 8642B, 8903A, 8110A, 8156A
 

Offline warpco

  • Contributor
  • Posts: 11
  • Country: ru
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #10 on: November 07, 2019, 10:22:26 am »
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".
 

Offline Pseudobyte

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #11 on: November 07, 2019, 04:16:31 pm »
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.

“They Don’t Think It Be Like It Is, But It Do”
 

Offline Ice-Tea

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: be
    • Freelance Hardware Engineer
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #12 on: November 07, 2019, 04:47:06 pm »
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...
eBay shop with all the gear you need!
FS: Agilent 54825A, R&S CMU200, CRTU, SMIQ06L, Marconi 6201B, Lecroy WP 950, 9354TM, 9354M, 9374L LC584A, Tek THS720P, TDS7154B, Anritsu MG3671A 2.75G I/Q RF gen, Keithley 238 SMU, HP 8642B, 8903A, 8110A, 8156A
 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 3529
  • Country: ca
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #13 on: November 07, 2019, 05:12:53 pm »
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.
Facebook-free life and Rigol-free shack.
 

Offline Ice-Tea

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: be
    • Freelance Hardware Engineer
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #14 on: November 08, 2019, 12:26:33 pm »
It's supposed to be hard on the eyes. None of the 'oh, didn't see that' rubbish.  :-DD
eBay shop with all the gear you need!
FS: Agilent 54825A, R&S CMU200, CRTU, SMIQ06L, Marconi 6201B, Lecroy WP 950, 9354TM, 9354M, 9374L LC584A, Tek THS720P, TDS7154B, Anritsu MG3671A 2.75G I/Q RF gen, Keithley 238 SMU, HP 8642B, 8903A, 8110A, 8156A
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf