Actions
Forum Thread Details
  • Replies 12 replies
  • Subscribers 190 subscribers
  • Views 1327 views
  • Users 0 members are here
Related

Product Improvement Suggestions: Shared Libraries, Pad Editor, ...

dlotton

Let me first say that Eagle is an excellent design tool and very reasonably priced.  I applaud you for multiplatform support.  Microsoft does not rule the world! image

 

 

First:

One of the things I've found eternally frustrating about Eagle is trying to use common shared libraries with other engineers.  It would be nice if the necessary hooks were added to eagle to support shared libraries in a safe way.

 

The scenario I've encountered (in more than one office) is when you have multiple engineers who may be creating/editing parts in an Eagle library.  If the engineers use a shared drive to share libraries you then have a situation where the last person to write to a library could overwrite changes made by someone else.

 

Our workaround has been to have each engineer maintain their own library private lirary and if you need to use a part that someone else has already created, you get a copy of that engineer's library and copy the part into your own library.  Not to mention the hassle factor in doing that, but now you've got the same part in multiple libraries and if you discover a problem with a part or make a change to a part you have to make sure everybody knows about the change and updates their libraries accordingly.

 

This isn't an easy problem, I know.  There are many things to consider, such as, the scenario where a change made to a library part for a new design may cause problems in an old design.  This might be mitigated to some degree with a dialog box that notes changes when an  "update library" command is performed and allows you to update or skip particular parts.

 

Ideally, with a shared library, editing would create a lock at the device/symbol/package level, not the entire library level.  This would allow multiple users to simultatieously create/edit different parts within the same library.  If someone tries to edit a device/symbol/package that is being edited by someone else, they would be refused.

 

One solution might be a SQL-type server (mySQL, SQLite, etc.) for shared libraries.

 


Second:

A pad editor would be nice for creating custom pad shapes.  I've had a few occasions where I needed an irregularly shaped pad, or an SMT pad with a via embedded in it to transfer heat.  Placing a via on an SMT pad throws a DRC error, which is annoying.

 

 

Third:

A feature I've found very helpful in Cadence is design rules enforcement during manual routing.  Basically, when hand routing traces Cadence enforces minimum spacing rules (e.g. when routing a trace and you get within the minimum spacing the trace being routed is deflected by the interfering trace/copper/pin/via/etc (it can optionally 'shove' the offending feature out of the way)).  It is almost like a single trace, guided, on-the-fly auto routing.  The router tries to follow where you're clicking with the cursor, but obeys spacing rules and tries to route around DRC conflicts.  Very nice feature.  Maybe the feature would come with th epurchase of the autorouter module.

 

 

 

 

Just some feedback for your development staff.  Kudos!  Keep up the great work!

 

Thanks,

 

Dave L.

Parents

  • I also considerd the first quesion. but can use svn or git done it. I feel this is better than database.

     

    are we really need pad editor ? why dont use device achieve ? I means you can create a device for it.

     

    the third suggestions is great, but its implement maybe hardly. wait for Richard Hammer's reply.

  • in reply to huayuliang

    1) We had an environment where we had multiple engineers actively building new parts.  We tried using SVN to manage shared libraries and it really isn't a good solution.  You still have the problem of the last person to commit 'wins'... i.e. last person to commit their changes overwrites changes others made since SVN cannot merge binary files.  Yes, the previous version of the library still exists in the repository, but you still have to manually merge the separate changes into a  single library and you have to do all this outside of Eagle.  An integrated multiuser library solution would be a godsend.  Though, I understand that it isn't a trivial thing to implement and there is the issue of backward compatibility with old designs, etc.

     

    2) I don't understand what you're suggesting regarding using a device.  I don't know of a way to create an irregular pad shape for a lirary part.  The only options I know of, for example, are rectangular SMD, or rounded rectangular SMD pad.  What if I want a 'T' shaped SMD pad, for example?  ...or what if I want a square SMD pad with four vias to transfer heat?  There are ways to get there in the board layout phase, but you have to do these things manually for each instance, and you probably have to ignore some DRC errors, which isn't good practice.  A pad editor would be a 'nice to have', but I've gotten by without it.

Reply
  • in reply to huayuliang

    1) We had an environment where we had multiple engineers actively building new parts.  We tried using SVN to manage shared libraries and it really isn't a good solution.  You still have the problem of the last person to commit 'wins'... i.e. last person to commit their changes overwrites changes others made since SVN cannot merge binary files.  Yes, the previous version of the library still exists in the repository, but you still have to manually merge the separate changes into a  single library and you have to do all this outside of Eagle.  An integrated multiuser library solution would be a godsend.  Though, I understand that it isn't a trivial thing to implement and there is the issue of backward compatibility with old designs, etc.

     

    2) I don't understand what you're suggesting regarding using a device.  I don't know of a way to create an irregular pad shape for a lirary part.  The only options I know of, for example, are rectangular SMD, or rounded rectangular SMD pad.  What if I want a 'T' shaped SMD pad, for example?  ...or what if I want a square SMD pad with four vias to transfer heat?  There are ways to get there in the board layout phase, but you have to do these things manually for each instance, and you probably have to ignore some DRC errors, which isn't good practice.  A pad editor would be a 'nice to have', but I've gotten by without it.

Children
  • in reply to Richard_H

    yes! a special people is needed to take care the librarys now.

     

    thanks your advice.

     

    Best Reguards!

  • in reply to huayuliang

    As somebody in this thread already supposed:  The library management has not been designed for multi-user access. From our customers I know that there are some who work with a version control system like svn, as already mention here.

    Others delegate one person that takes care on libraries. This means all users can access libraries that are, for example, available on a network server, but they don't have write access.  So, if a user makes changes in a library or adds a new component, he has to store it in a private directory first. Afterwards he forwards his library to the "library manager" and he can add it to the source libraries.

  • in reply to Richard_H
    how do you thinke the difference version libraries shared in a group?
  • in reply to huayuliang

    You are right, I ignored the DRC error, consider this, a pad editor is needed.

     

    As far as i am informed, user-definable pad shapes are planned for the next major version 6.

  • in reply to dlotton

    You are right, I ignored the DRC error, consider this, a pad editor is needed.

     

    about librares share, true, but I have no experience on multiple people share them library synchronous。

     

    if choice a database, I recommand SQLlite.

  • in reply to e14 Contributor

    In my case both scenarios are pretty common, editing existing parts and creating new parts.  Each user builds a lot of new parts and the approach we've ended up with is each user having their own private library.  When we want to use a part that someone else has already created we get a copy of the other's library, then copy the part from the other's library into your own.

     

    Copying parts from one library to another is not difficult, but it is tedious and interrupts work flow, and there's opportunity for parts in the separate libraries to get out of sync (e.g. someone fixes a problem in their library it is not automatically propagated to the other libraries). This is more prevalent in a shop where you have multiple users contributing to parts creation, but the issue also present when a single user is using Eagle on multiple systems (e.g. laptop and workstation).

     

    There are definitely ways to work around the current limitations, but bottom line, they are workarounds.  The current library system was not really designed for an environment where multiple users contribute to library part creation.  What I'm advocating is an INTEGRATED, multiuser-safe library solution.

  • in reply to dlotton

    Agree about the shapes - although there's not many occasions that I'd need that.

     

    For the libraries, what sort of changes are made? Is it adding new devices/packages to the library, or fixing problems with existing ones?

     

    If it's the former, couldn't each user have their own library that only they can edit - then it's a simpler matter of copying the library between the users (I do this with my laptop and desktop with a script).

     

    The latter would be much more complicated: don't make so many mistakes would be a flippant answer image.

     

    I've done a bit of work with the Eagle library format (for my search), and while it's not too difficult to parse (it took me about 3 hours for the basic code, and then another 3 for some of the more unusual cases), I wouldn't want to modify a file in any way - there's still a few rules that I'm not sure about!