Eagle CAD library search function

I'm not an Eagle user, but I've used a few different PCB CAD packages and search is always atrocious. What they really need is a relational database with keywords, footprint names, etc. so you could search for "transistor array" or "uln2803" and even specify the package (e.g. "soic", "dip")

Open a console/terminal and type:

cd eagle_dir/lbr

grep -i Uln2803 *.lbr

In my case it returned:

uln-udn.lbr:<deviceset name="ULN2803A" prefix="IC" uservalue="yes">

So, check the library uln-udn.lbr.

Kind Regards,

Joop

So what you're saying is, Eagle's search is so bad, it makes grep look good. I guess I don't disagree.

(Disclaimer: I'm not dissing grep, but it is just a text-search tool, and a good component search tool requires more than that.)

- Bob

Bob Alexander wrote:

 

So what you're saying is, Eagle's search is so bad, it makes grep look good. I guess I don't disagree.

 

(Disclaimer: I'm not dissing grep, but it is just a text-search tool, and a good component search tool requires more than that.)

 

- Bob

Grep is one of the best search tools (for text) available.

Because components are stored as text, it makes grep the best search tool for components.

I do agree that the search tool of Eagle is bad. The reason it doesn't bother me is that, for searching, no matter how good Eagle's search tool will be, the console & grep will always be faster, easier and more flexible.

I do agree that the search tool of Eagle is bad. The reason it doesn't bother me is that, for searching, no matter how good Eagle's search tool will be, the console & grep will always be faster, easier and more flexible.

Don't let Eagle's developers off the hook that quickly. They could easily improve their search tool to match grep's functionality. They could surpass grep if they switched to a relational database for storing their components - though that would not be easy for them to do.

In any case, they should be embarrassed that someone is using *nix command line tools to replace their own functionality. Eagle has been around for over 25 years. There's no excuse for a generic *nix tool to do Eagle's job better than Eagle.

- Bob

Bob Alexander wrote:

 

Don't let Eagle's developers off the hook that quickly.

I don't, see my other posts in other threads.

Bob Alexander wrote:

 

They could surpass grep if they switched to a relational database for storing their components

Please no. Eagle uses an open specification for their xml files. You are free to use what ever database you like.

Regarding the libraries that comes with Eagle, I believe it's mostly used by novices. Me, and I guess lot's of other (advanced) users,

design their own libraries. Let them (the Cadsoft team) focus on more important things like a correct IDF export, push and shove routing,

netnames visible in board traces, etc.

They could surpass grep if they switched to a relational database for storing their components

 

Please no. Eagle uses an open specification for their xml files. You are free to use what ever database you like.

Please yes. :-) I'm not an Eagle user, so I can't comment on whether they have bigger problems than their component library, but I've found component library management to be atrocious in the CAD programs I've used (and I played with Eagle briefly). Some of the problems:

• Sometimes a component is in a library based on its function, sometimes it's in a library based on its manufacturer. It's obvious where to look for a PIC18, but where do you look for a voltage regulator or generic logic chip when you don't care who the manufacturer is?
• Sometimes, user-created libraries have a jumble of miscellaneous components in them (i.e. all the components that user uses) and sometimes they have only one or two components in them (because the user tried to organize unrelated components into different libraries, and he doesn't use enough components for any library to get large).
• If you get libraries from different sources, there are bound to be duplicate components.
• You can't put your user-created components in Eagle's library files, even if that makes sense (e.g. you've created a component for the newest Microchip microcontroller, so putting it in Eagle's Microchip library would make sense) because your component will be deleted when you upgrade Eagle ...
• ... so you put it in your own file in one of your own directories. Next time you want that component, where do you look? In Eagle's Microchip library or your own library?
• Since you can't store new components in Eagle's library, everyone ends up inventing their own library directory(ies). Even with grep, searching for a component among different directories (in different trees) is cumbersome.
• Sharing a design requires sharing libraries. Which libraries do you need to send to the other person? Can the other person integrate your libraries with his, or has his IT department or development team locked things down? Even if you don't have duplicate components, will he have duplicates once you give him your libraries? If he modifies the design and sends it back to you, now you might need his libraries too.
• People like to boast that it's easy to create new components; they do it all the time. Well, sure, I've done it too. But no matter how easy you think it is, it's still harder and more error-prone than using a pre-existing component. And it's a waste of time for hundreds of people across the country to be creating the same component.

In short, component management is crying out for a database solution. Maybe even a cloud solution - and I say that as someone who hates relying on the cloud for vital services (e.g. writing documents, developing software and hardware).

- Bob