What are some best practices for library management?

As the others said, there is no definite answer to this. But here is how we do it:

There is a global schematic library and a global footprint library. They have the components we use and have the necessary details (like references to the ERP system). But there is still only one symbol for different values (i.e. 1 kΩ resistor and 470 Ω resistor use the same symbol). All symbols and footprints are our own footprints. The libraries are text based (KiCad) and are tracked with git. There is a single person (to be fair, there is only a single person in our electronic design team) that is responsible for the library. Since we don't have too many different parts, we can keep all in the same library. Similar with 3D models. All global 3D models are in a single folder.

Next to that, a project may have its own schematic and footprint library with its own 3D models. In this libraries are parts that are specific to this project, for example a case maybe inside a "footprint", and that case can be specific to a PCB. A other reason to have some parts in a local library is to have a symbol with a different pin layout without everything going into the global library.

How to deal with footprints of the same type (e.g. QFN64) but with slightly varying dimensions as a result of manufacturer guidelines?

Do they have to be different? Most of the time, the datasheet only has suggestions for a footprint but that doesn't mean you have to follow this. If you really need different footprints, create a new name, like SO8 and when you later need to add a different footprint also for a SO8 component, you may name it SO8_small.

posted about 1 year ago

CC BY-SA 4.0

1y ago

H_H‭

21 reputation 0 2 2 4

I don't know about "best practices", but I make all my own library parts.

I use Eagle, and the library parts that come with Eagle are quite inconsistent in things like pad shapes, what is shown on the silkscreen, size of lines and text, what goes into the various layers, etc.

It might be tempting when you first start with a new EE CAD tool to use their existing libraries, but you can't guarantee quality and consistency that way. Vetting someone else's library parts would take about as much time as just creating your own. Maybe a hobbyist can get away with it, but a professional surely shouldn't.

I can understand that making your own library parts might feel overwhelming at first, but that's only because you haven't gotten good at it yet. Just like other parts of the software, you need to sit down and get good at it. Otherwise, you'll be making bad tradeoffs about what's easier for you to do instead of what's best for the circuit and the customer.

Here's an anecdote. When I made the first board for a customer with Eagle over 20 years ago, I was of course still learning the software. I hadn't established my own conventions yet or standardized how to do things across projects. Near the end of the design I realized I needed an extra NAND gate. Instead of looking in the datasheet and making my own part, I used the stock Eagle 74xx part. Surely that would have been tested thoroughly by now. They wouldn't screw up a quad 4-input NAND gate chip, right?

They didn't screw up. The circuit worked correctly. However, when I handed the customer the board, the very first thing he said was "Why does this chip have oblong pads, and all the others round?". That was the NAND gate. He understood that it didn't really matter, but it still made me look stupid and careless. After that I never again used a stock part and have made all my own.

Since then I've developed a set of standards for library parts. These include silkscreen width, text sizes for name and value, and that the component designator also goes into the tDocu layer for making the board drawing with my canned scripts. Standardizing library parts is more than just following the same rules in making new parts. In Eagle at least, it also includes how attributes are used in creating the BOM, what information goes on different layers for the board drawing, etc. Some of these conventions are assumed by scripts and ULPs (user language programs that run in Eagle).

Common problems I've seen with stock parts are poor labeling and layout of pins in the symbol, and just copying the manufacturer's suggested footprint for the package. Manufacturer suggested footprints are often not very good. They don't know whether you've got a tight design, or would rather be able to have 20 mils past the ends of pads for a place to hold a scope probe tip. The suggested hole sizes are often larger than needed, even when all the tolerances are taken into account.

Now that I've said you should make your own parts, you're welcome to use my libraries if you use Eagle. If you install the my Eagle Tools release at www.embedinc.com/pic/dload.htm, then you get most of my part libraries. This release includes scripts, ULPs, key bindings, and documentation files that are all consistent with my library design standards.

posted about 1 year ago

CC BY-SA 4.0

1y ago

Olin Lathrop‭

8059 reputation 18 332 961 469

There is no definite answer to this but, if you want my advice, you store all symbols and footprints locally with your project. Of course you may begin by using standard parts from a global (comes-with-the-installation) location that isn't under your control but, as soon as you can migrate the ones you use to a local library that is under your control. Then you can transport the whole project (and libraries) without fear of it relying on libraries that were part of the installation and not part of a new set-up.

I will now say that I don't like the way Altium does things and will never use it again in this life or the next.

posted about 1 year ago

CC BY-SA 4.0

1y ago

Andy aka‭

2319 reputation 19 75 268 282