Best way to handle BOMs and component libraries in Altium Designer

[Pack34]

I'm getting my feet wet with Altium and I'm looking at converting several designs over. My end goal is that I want to be sure that all relevant component information is stored within the schematic with a primary sourced option and a backup.

Just by playing with the program I can place parts like I normally would with PADs, open up component properties and then I can freely add parameters to each part to capture the relevant manufacturer data.

However, as seen from some of Fedevel's videos and a demo from an Altium rep I can do proper supplier parts searches and embed those within the parts. This would be preferred as it would involve less copy and pasting so maintenance of the design would be easier as information such as the manufacturer name or part description may change format over time. Doing it this way seems to involve creating individual component libraries for each project and then individual components for every part. This seems like it would be quite a pain to develop over time.

I would like to avoid going down the same manual route I had to in my older version of PADs but having individual libraries per design seems like it would be an equally poor method.

[radar_macgyver]

This might be outdated given the Vault stuff they keep talking about, but my preferred solution is to use svndblibs. This requires considerable setup, but it worth it in my opinion. The idea is to use SVN to store the schematic symbols and footprints, and a separate database to hold a list of components with references to the symbols/footprints in SVN. I set up a mysql server for the database, but I think you can also use MS Access. The svndblib control file ties everything together, and indicates which tables in the database contain components you need, and which columns in those tables map to component properties. It was the only way I found to make, for example, one schematic symbol for a resistor and re-use it for all the resistors I need in my designs. Using per-project, or even shared libraries means separate symbols for each resistor value.

I set up my database to include supplier information and supplier part numbers, and include a datasheet link. PDF files generated from schematics will show a pop-up menu when clicking a component symbol, which link to the datasheet. Finally, when generating a BOM, I can have it include supplier information that was sourced from the database.

[T3sl4co1l]

Simplest is looking up the part number (in the Supplier Search panel) and adding link (and parameters if you like) to parts on the schematic.

You can also do this in the library, in which case every part you place will have the same info (of course).  Existing parts are only updated if you update from libraries.

The database systems get more and more complicated, but more and more powerful (see above!).  Using a BomDoc is a good start (really just being a better manager than the BOM Report dialog).  Using a DbLink file, you can easily link to a spreadsheet as a database (or a proper one like MS Access), like for if you have a list of inventory part numbers you want to include in the BOM output.

Tim

[ajb]

I'm a big fan of the DBLib approach.  It has a few quirks, but makes it really easy to reuse library elements and tie in whatever additional data you want.  MS Access is part of Office 365 now, so that's a nice cheap and easy option for building a basic database.  One tip:  It may be tempting to go overboard building a database that has fields for every parameter you might conceivably care about for every type of component.  Don't do that.  You either wind up with a single ridiculously wide table with tons of empty fields on most components, or you need to have twenty different tables for all of the different component types so that you have the right fields for each.  Keep it simple: one table, with part number, value, library links, supplier links, type/subtype/subsubtype fields for basic hierarchical sorting, a link to the datasheet, and a description field that contains the basic topline specs.  MAYBE add a couple of special fields for information that you want to explicitly show on the schematic symbol (eg, MLCC dielectrics), but that's basically it. 

I would avoid adding parameters to parts in the schematic, because those parameters will get nuked if you ever update from libraries or replace the part.  You can theoretically selectively preserve parameters during an update from libraries, but this is not reliable in all cases.

By default, Altium stores all of the symbols, footprints, and component parameters in the SchDoc/PcbDoc files, so you don't need to worry about any of that information being lost if something happens to your library or whatever.  You also have the option of building an integrated library from a project if you want an additional snapshot.

[julianhigginson]

I'm a fan of dblink for having a single large parts database, and a set of organised schematic and footprint libraries that the database references.

I've worked with both excel spreadsheet and SQL database. no access db yet, but thinking of pushing my current excel db to access... I find excel "database" while very convenient and portable, is a little fiddly, and I find if I'm adding parts to my database, plus using them at the same time in altium, programs get in a tizzy about who has write permission, and I have to close altium and then load it up to keep going... I think the altium dblink feature causes the problem by not opening the excel file in read only mode.. when excel actually needs the file in read/write mode in order to let me update info as I go...

I really liked the SQL database option, but having to host a database is kind of a pain. the access db seems to just work on your local pc through the file system, rather than needing a special service setup...

I'd love to have the power of vaults for parts management, but price of it just to have parts management, vs return on what I can do for free makes the value proposition hard to justify...


Sent from my A0001 using Tapatalk

[electricar]

I would avoid adding parameters to parts in the schematic, because those parameters will get nuked if you ever update from libraries or replace the part.  You can theoretically selectively preserve parameters during an update from libraries, but this is not reliable in all cases.

Hello ajb,

do you mean that updating the symbols from the libraries will loose all parameters? I saw a similar behaviour a few times but I thought its due to wrong settings or actions from my side. I'm not quite sure in which case this is happening. Can you please explain the problem a bit more?

Thank you very much in advance!

[ajb]

I would avoid adding parameters to parts in the schematic, because those parameters will get nuked if you ever update from libraries or replace the part.  You can theoretically selectively preserve parameters during an update from libraries, but this is not reliable in all cases.

Hello ajb,

do you mean that updating the symbols from the libraries will loose all parameters? I saw a similar behaviour a few times but I thought its due to wrong settings or actions from my side. I'm not quite sure in which case this is happening. Can you please explain the problem a bit more?

Thank you very much in advance!

I haven't tested it in detail, because I don't like editing component parameters in the schematic in general anyway*, but there are numerous bug reports relating to the handling of parameters when updating from libs or DBs.  It's not clear how many of these reports reflect different bugs or just different manifestations of the same bug, but if you search for "update parameter" on BugCrunch you'll get a lot of relevant results.  In particular, #1844, #2028, #5342, #6193 are relevant.

* Mainly because these are invisible by default and require deliberate precautions to avoid inadvertently changing/deleting them when editing a schematic, even if Altium's handling of parameters weren't buggy.  Ideally, if you wanted to add a parameter to a component in a schematic you'd use something like a directive object to provide a clear indication that a component has special parameters defined in the schematic, and since the directive is a separate object from the component, it wouldn't be affected by any changes--buggy or otherwise--to the component itself.  Unfortunately, as far as I know, there's no way to do this.  There's no reason that the directive+blanket system shouldn't be able to affect components, but for some reason they only work on nets.  Another nice way to do this would be with a spice-style text directive, which would probably look nicer than the current directive objects do anyway, but again, as far as I know there's no way to do this. 

In lieu of a better way of doing it, if you want to add/edit parameters the best way is probably to unhide, lock, and disallow database synchronization on them.  I *think* that this will prevent them from being changed at all during an update, but you'd want to test this to make sure.  And hopefully with them being visible you'll notice if they do get changed accidentally.

[julianhigginson]

the whole point of having special parameters for a specific database item is that when you update from database, all components in the schematic should get the perfect single-sourced truth that is the database's information for their particular part pushed into them!

If you manually modify components in the schematic sheets with ad-hoc parameters, then update the schematic part from a schlib or a database, you should really expect that data to be clobbered. you've just updated a container of information with a new one!

But keep all the relevant part information for each part in one well known safe and secure place (database!) you never have to worry about clobbering data in one instance of that part in a schematic sheet. Because every instance of that part that you use always gets exactly the same information pushed into it when you update from database.

For me, the biggest weakness for parts databases is for some reason they don't work exactly the same with attached models as parameters - so by default when you update a part in a database to use a new model, and push that info to a design you are working on, the old model is still attached to the schematic library part (though the new part is also added, leaving the old one as an option just leaves things ripe to be muddled up by someone else at a later date)

[carljrb]

...and here's the unpopular vote against dblibs!

Either you create one monster table, or lots of tables with custom attributes. Both suck, just in different ways. And access/excel are pretty poor choices IMO. Yes, you can supply a connection string to a "real" database, but that only makes it more of a pain to work with...

The tools to edit and manipulate dblibs in altium are incredibly awful. If you want something that isn't so bad, you'll want to develop a front end to that database. 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.

Without one of those database front end tools, dblibs are a nightmare. Setting lib paths by hand, having to manually copy symbol names and footprint names from each lib and then pasting them in the database by hand... That gets old REAL fast! When I tried dblibs, I wrote code to parse schlibs and pbclibs to extract the symbols/footprint names from them (to fill comboboxes, along with a bunch of SELECT DISTINCT queries to fill others) and even then it wasn't fun at all.

In the end, it seemed like far more trouble than it's worth. Copying symbols from a template or similar part takes a few seconds at most. Most of my attributes are filled by the supplier part search. And when I select a footprint, I even get a preview of it. No need to bother with library paths, copy/pasting symbol/footprint names and all of that. Far less manual editing, lots quicker and less hassle overall.

As for svndblibs, well... I use SVN for my designs (but all my code is in git instead) but even then it's not looking very attractive. It seems like dblibs and all of its downsides, plus the extra overhead of splitting the libs in a ton of different files (probably slower) which all have different revisions, further complicating things. It's probably nice to have comments on commits (what got added/updated/whatever), but unless you also version control the database it's partial at best. I'm not convinced it's any better.

Then again, I don't see a point to vault either. It sure costs a lot of money but it doesn't seemingly solve a problem I have.

[radar_macgyver]

Either you create one monster table, or lots of tables with custom attributes. Both suck, just in different ways. And access/excel are pretty poor choices IMO. Yes, you can supply a connection string to a "real" database, but that only makes it more of a pain to work with...

For what it's worth, I use mysql, and Access as the front-end (link to external database tables). I've meant to write a front end of some sort, but never found the time.

[ajb]

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.