Author Topic: component library management  (Read 27764 times)

0 Members and 1 Guest are viewing this topic.

Offline daedalusTopic starter

  • Regular Contributor
  • *
  • Posts: 140
  • Country: gb
component library management
« on: December 13, 2011, 02:31:20 am »
How do you all manage your footprint and schematic libraries? I see from allium's documentation that it supports several different database and svn based library systems, are these any good? Are they just useful for large shops, or do they add value to the individual user too?

I currently use discrete schematic and pcb libraries for my projects, which usually involves rolling a new library for the oddball parts, and using a few dozen libraries of regularly used parts from previous designs.

I don't suppose there is a way to scrape component data from the likes of digikey and populate up a db driven library automatically? Surely this should be doable for R, C, transistors, etc where the digikey footprint descriptor is reasonably complete?
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 38715
  • Country: au
    • EEVblog
Re: component library management
« Reply #1 on: December 13, 2011, 03:19:12 am »
Altium has all manor of ways to handle your component libraries.
They have now moved to the new cloud based vault rubbish which most people hate.
For my own stuff I still use separate .SchLib and .PcbLib files for my schematic and PCB components, linking to a mis-match of PCB footprint libraries, both supplied and custom generated.
When working on contract stuff, I've used whatever system the company has in place.
Some people use one schematic and component library file per device.

All these different methods have unfortunately lead to me not really having any sort of cohesive personal library. Each new board or design is a bit of a fight and generation of new parts and footprints etc. Ugly  :-[

Dave.
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 10234
  • Country: nz
Re: component library management
« Reply #2 on: December 13, 2011, 05:55:20 am »
I too have a custom schematic and PCB library file where i keep all my own designs and stuff.

Handy hint: 
(In case any Altium users are not aware)
You can copy any existing Altium component schematic/footprint and paste them into a blank entry in your personal component/footprint library. So you don't have to design new components from scratch if there's something similar available.

eg, If you need a 19 pin header but Altium only has 18 and 20 pin headers you can just copy either one from your PCB, then paste it into your pcb library and edit to remove or add extra pads.

I didn't find out about that until a few years after :)
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline daedalusTopic starter

  • Regular Contributor
  • *
  • Posts: 140
  • Country: gb
Re: component library management
« Reply #3 on: December 13, 2011, 01:50:53 pm »
Dave I share your frustration in this regard, I keep finding myself having to remember what project I last used an obscure part in, then go dig out the library and copy the footprint to the current project.

The other issue I end up with is more subtle, for some parts I have a generic sheet symbol / footprint, and a value tag, such as semi passives, which becomes a pain in the ass at BOM time, and other parts such as connectors where there are multiple suppliers but I have modelled the sheet entity/footprint labelled for one supplier, and have to change schematics to get a correct BOM despite the board not really changing. This just ends up with me not bothering to be consistent and having a very manual labour intensive BOM generation process.

I guess one solution to the latter might be to build up a 'multicomp' library for some of the more common parts with multiple suppliers.

In some ways I do see the benefits of using cloud computing for doing component footprint management, but for me the benefit would be getting a community of users to build up good footprints and symbols for common parts and validate their use (like the included libraries, but with user participation). Altium's solution seems to limit this to inside one organisation, which negates any real advantage.

 

Offline seddona

  • Newbie
  • Posts: 2
Re: component library management
« Reply #4 on: May 13, 2013, 05:00:43 pm »
Hi Daedalus,

Just stumbled on your old post. We are working on pretty much what you describe at https://circuithub.com/ . If you have any feedback on your dream solution for this let me know!

Cheers,

Andrew
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8550
  • Country: us
    • SiliconValleyGarage
Re: component library management
« Reply #5 on: May 13, 2013, 08:00:15 pm »
i have a project for an integrated library.
inside this project are tens of schematic library files. resitor smd , resistor thru-hole , transisot rsmd, transistor thru hole, analog , digital , capacitro smd , capacitor thru hole, mechanicals , etc. as well as tens of pcb library documents.
resistors 0805 resistors 0603 capacitors 0805 mechanicals , transistor footprints , ic footprints, etc

the whole project gets compiled into 1 integrated library. that one is loaded as the main library in schematic and pcb.

so whenever i make a footprint or symbol i simply edit them in the individual document , link em and hit 'compile'.
the library patches itself then.

my collegue does the same. we use each others integrated library , but we only edit our own source library.

that means i have loaded vh_library.intlib and am_library.intlib
i own the sources to vh_library , he has the sources to am_library. whenever he edits his sourcefiles the am_library gets updated so i immediately have the updated part. and vice versa.  you can do this with as many people as you want.
the intlibs are stored in a shared folder on the server. altium detects live that the intlib has changed and reloads it ( no need to restart ) so changes are immediate.

doing it this way we also don't mess up each others libraries. has worked without a hiccup for 7 years ...
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2845
  • Country: nz
  • D Size Cell
Re: component library management
« Reply #6 on: January 25, 2015, 09:57:41 pm »
Where have you guys guys ended up on this topic? 

Did you byte the bullet and get the Vault thing?
On a quest to find increasingly complicated ways to blink things
 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: us
Re: component library management
« Reply #7 on: February 07, 2015, 07:55:04 pm »
I'm using a DBLib, and really like it.  It's basically just me doing the electronics design here, though, so not sure how well it would translate to a larger shop.  The way it works is you create SchLibs and PcbLibs separately, typically with a bare minimum of information, and then use a database to link schematic symbols to PCB footprints and define whatever other paramaters (even supplier links) you want.  The big advantage is that it's incredibly easy to create a symbol or footprint ONCE and then reuse it as many times as you want. 

I'm using Access for the underlying DB, but you could use any number of database solutions, or even Excel.  I have a separate table for different classes of components--resistors, capacitors, inductors, ICs, diodes, transistors, connectors, board features (pads, SMD jumpers, etc).  This way each table can have columns specific to each type--power rating for resistors, ripple current for caps, etc--without adding dozens of extraneous parameters to every single part.  In the dblib configuration you can specify which columns are added and how they map to parameters.  Every table has "type", "subtype", and "subtype2" columns which are used for high level filtering, which works better in the library browser if you filter on the same columns in every table.  Speaking of the library browser, it's very fast with DBLibs even with large numbers of components.

The database format makes it very easy to move data into and out of the library.  So for instance, I got really lazy with descriptions for a while, so rather than manually type in dozens of descriptions, I just copied a table into Excel, used a formula to concatenate some key fields into a useful description, and then pasted it straight back into Access.  If you were really keen, you could of course create forms that interact with your database and create such things automatically on insertion of a new component.  Somebody actually sells and Access front end that allows you to drag a link from a supplier into a form and automatically scrapes the component information into the database, though I don't remember what it's called at the moment.  You could also theoretically use the database to connect your Altium library to your ERP system.

There are a few bugs to watch out for, though (as of 15.0.14):
- If you link on a column that is not unique across your database (for instance a simple autonumber column unique in each table), the library browser can get confused and display information from the wrong table.  The workaround is to link on two columns to assure that each component gets a Design Item ID that is unique across the whole database.  My method is to have an autonumber ID column and a column that identifies the table, and link on both.  If your company has internal part numbers that are unique, you could use that on its own.
- Having a parameter named "table" (for instance as part of the previously described workaround) can cause BOM generation to fail.  So name that column something else!
- Using the table browser in the DBLib setup to edit the database can overwrite entire rows with data from other rows, so just don't use it.  Unfortunately this eliminates a convenient way of adding supplier links, but it's not hard to do that in the database directly.

All in all, even with the bugs, DBLibs are really great, and as a small shop I pretty much wouldn't do it any other way.  The one thing that's a bit of a pain is components that have standard symbols and standard packages but non-standard footprints, like oddball transistors and such, since there's no way to abstract the mapping of schematic pin to PCB pad.  So those require special treatment, but in that respect it's no worse than a conventional integrated library.
« Last Edit: February 07, 2015, 07:58:38 pm by ajb »
 

Offline Miles Teg

  • Regular Contributor
  • *
  • Posts: 79
  • Country: fr
  • YAWP!!!
Re: component library management
« Reply #8 on: February 26, 2015, 07:15:20 pm »
Thank you Ajb. I have altium since 2 weeks now and really soon I go in your method. Need some times to get used of the dblib connector functions, but kniw i'm really fluent of adding any component.

Next step will be to create a table or query in access to get suppliers price (my business is high volume) and find the way to link it to supplier link in altium and get automated BOM.

I can't wait! But need to deliver a first layout in the rush.  Planning...
If you see me running, that's already too late.
 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: us
Re: component library management
« Reply #9 on: February 26, 2015, 08:30:55 pm »
Supplier links in DBLibs are as easy as having columns for "Supplier 1", "Supplier Part Number 1", "Supplier 2", etc.  Supplier info then shows up in the library browser just as you'd expect, and can be brought into the BOM automatically.  I've just gotten into the habit of adding that info in for each component as I add it to the database.  Doing it as you go makes it pretty painless. 

One thing I haven't figured out yet is how to get manual pricing into the BOM.  I imagine there must be a way to have that in the database and pulled in during BOM generation, but haven't put much effort into that.
 

Offline Miles Teg

  • Regular Contributor
  • *
  • Posts: 79
  • Country: fr
  • YAWP!!!
Re: component library management
« Reply #10 on: February 27, 2015, 02:09:08 pm »
Ho Ajb,
I think we are misunderstanding, but have the same need.
From a Supplier like Digikey, yes I will link it from my components database tables (using the Digikey part number)""Supplier 1", "Supplier Part Number 1".
But for bigger suppliers like Avnet that didn't provide full catalog prices I must enter one by one the quotation for the requested component in my own database.
For example, I ask a price for a STM32F1 for 30k pcs/years. And they give me a 3 steps break price.

I will enter these prices in acces tables and build an access query to build a flat result that Altium could open.
I think I can add "my company" (or "your own company ERP" like Altium doc says) in the DXP->Preferences->Data management-> Suppliers
You have choice like Mouser, digikey... and ODBC. Here I think I can link to my database.
And I think this relate to your need of entering manually prices in the BOM.

You build your component in your access DB, you set your on price. You define yourself as a supplier.
You Link your components database dblink to your com ptables.
You link your prices tables as a supplier. And I think you're done.

Can't wait to try.
If you see me running, that's already too late.
 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: us
Re: component library management
« Reply #11 on: February 27, 2015, 06:28:51 pm »
Ahh, gotcha.  Yeah, that's exactly the kind of thing I was thinking of.  I'd love to hear how it works out for you.  I'll be looking at trying to do something similar once our current ERP migration has settled down a little more.
 

Offline Miles Teg

  • Regular Contributor
  • *
  • Posts: 79
  • Country: fr
  • YAWP!!!
Re: component library management
« Reply #12 on: March 06, 2015, 01:59:58 pm »
Preferences --> Suppliers --> ODBC

"The ODBC supplier can be enabled only using Alitum Vault Server"

And I believe this is a paying one...

 :wtf:

 :palm:

I don't care of the vault system. I just want the software to just read a local access DB like it does so well with the library DBLink.

 :--

If you see me running, that's already too late.
 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: us
Re: component library management
« Reply #13 on: March 07, 2015, 10:23:49 pm »
Well that's some bullshit. 

I wonder if there's a way to incorporate pricing from component parameters.  That could be an okay second choice, though surely not as powerful as an ODBC supplier link.

I also ran across this recently, which handles custom pricing in a BOM template via Excel macros.  Doesn't help with getting that information into Altium, but at least gives you complete pricing in the exported BOM:

https://github.com/mbedded-ninja/Altium-Bom-Template
 

Offline Miles Teg

  • Regular Contributor
  • *
  • Posts: 79
  • Country: fr
  • YAWP!!!
Re: component library management
« Reply #14 on: March 13, 2015, 07:07:52 am »
Hello!

For my current project (with only one determined factory managing components sourcing and PCB fab) I put the price in my access component database directly on each component entry.
This information could be use by the BOM file system in altium. And I just Ctrl-A Ctrl-C in the BOM view (not the calalog). And Ctrl-C in excel.
And I get the summary fast.

On my schematic I also add two user parameters like "Fct1" and "Fct2"  Like Fct1="USB Charg" and Fct2="Ship". And I include these parameters in the BOM copy/paste.
Dynamic cross table it on excel, and now I've a repartition of the cost by function and sub function. handy to make functionnal/price choice with my management.

For the price. I think I will next replace my table linked in Altium by query made from Access. So I will be able to change the result of queries in access following paramters I could change easily in access, like the factory I'm working with and the production qty.
Not the most clear and neat solution. but could be fast and efficient.

Need an IT trainee to work on my database  ::)
If you see me running, that's already too late.
 

Offline ivonenand

  • Contributor
  • Posts: 38
Re: component library management
« Reply #15 on: May 25, 2015, 04:44:29 pm »
Hi guys,
I have a question for those of you, who work in companies with 2 or more licenses. So far I've been the only electronics engineer in our company; I've created all of the libraries that I use myself and so I've never had to deal with multiple people working on the same libraries at the same time. For now I use only *.schlib and *.pcblib files.

So now we'll be hiring an aditional engineer and purchasing a second license. We'll be working on different project, but we'll of course be using the same libraries. So what happens when one of us wants to add a part to a library? What if we have the same library file opened at once? One could add one part, but it would get lost if the other one saves it.

How do you guys solve this problem?

Regards,
Ivo
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: component library management
« Reply #16 on: May 25, 2015, 09:44:04 pm »
Configure Altium to lock open files.  This prevents overwriting other work, but blocks changes.

You can manage policy however you like.  Work from independent libraries.  Manage independents and merge later.

You don't really even need to merge libraries into one massive hunk, you can have as many loaded as you like (though it gets rather slow to keep tens or hundreds referenced).

There's SVN support too, but I don't know that the merge option is helpful.  On a related note, there is a grid-delimited method for concurrent PCB work (at least as of v14), but it looks really sloppy to work with, and would only be any use for truly massive projects with several engineers at once.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline Gribo

  • Frequent Contributor
  • **
  • Posts: 644
  • Country: ca
Re: component library management
« Reply #17 on: May 26, 2015, 11:42:31 am »
You can use DB libraries, with as many users as you want, using the same libraries, and synchronizing automatically.
I am available for freelance work.
 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: us
Re: component library management
« Reply #18 on: May 26, 2015, 03:06:54 pm »
DBLibs aren't a complete solution, though.  They still rely on underlying SchLib and PcbLib files for the library symbols, so you'd still have to manage those some other way.  The database does take care of any changes to parameters or supplier links, and as long as you're only adding parts that use existing schematic symbols and pcb footprints then everything happens in the database and you're covered.  As for editing the underlying files, you might be able to use the built-in SVN functions to handle conflicts there, but I'm not sure if you can effectively merge multiple changes to a single document that way.  Probably best to use a single file for each symbol/footprint, which is what Altium recommends anyway.  That minimizes the opportunity for collisions, and implementing SVN on top of the individual files (and getting in the habit of using it!) should take care of any other problems you would have.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: component library management
« Reply #19 on: June 01, 2015, 05:31:16 pm »
DBLibs aren't a complete solution, though.  They still rely on underlying SchLib and PcbLib files for the library symbols, so you'd still have to manage those some other way.  The database does take care of any changes to parameters or supplier links, and as long as you're only adding parts that use existing schematic symbols and pcb footprints then everything happens in the database and you're covered.  As for editing the underlying files, you might be able to use the built-in SVN functions to handle conflicts there, but I'm not sure if you can effectively merge multiple changes to a single document that way.  Probably best to use a single file for each symbol/footprint, which is what Altium recommends anyway.  That minimizes the opportunity for collisions, and implementing SVN on top of the individual files (and getting in the habit of using it!) should take care of any other problems you would have.

Why not build one integrated library which includes all of the vetted parts you'll use? One guy gets declared the librarian and controls library updates. Put the built library where everyone can grab it.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf