Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

66%
+2 −0
Q&A What are some best practices for library management?

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...

posted 8mo ago by Olin Lathrop‭  ·  edited 7mo ago by Olin Lathrop‭

Answer
#2: Post edited by user avatar Olin Lathrop‭ · 2023-10-01T16:25:39Z (7 months ago)
  • 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 well 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 <i>"Why does this chip have oblong pads, and all the others round?"</i>. That was the NAND gate. He understood that it didn't really matter, but it still made be look stupid and careless. After that I never again used a stock part and have made all my own since.
  • Since then I've developed a set of standards for library parts. This 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 <a href="http://www.embedinc.com/pic/dload.htm">www.embedinc.com/pic/dload.htm</a>, 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.
  • 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 <i>"Why does this chip have oblong pads, and all the others round?"</i>. 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 <a href="http://www.embedinc.com/pic/dload.htm">www.embedinc.com/pic/dload.htm</a>, 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.
#1: Initial revision by user avatar Olin Lathrop‭ · 2023-09-30T14:53:19Z (8 months ago)
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 well 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 <i>"Why does this chip have oblong pads, and all the others round?"</i>.  That was the NAND gate.  He understood that it didn't really matter, but it still made be look stupid and careless.  After that I never again used a stock part and have made all my own since.

Since then I've developed a set of standards for library parts.  This 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 <a href="http://www.embedinc.com/pic/dload.htm">www.embedinc.com/pic/dload.htm</a>, 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.