Actions
Forum Thread Details
  • State Not Answered
  • Replies 2 replies
  • Subscribers 171 subscribers
  • Views 200 views
  • Users 0 members are here
Related

Major change required for library management.

Former Member

I have been using the Light edition of Eagle 6.5.0 now for some time and am saving money towards going for the full edition; however the Library System for Schematics and PCB foot prints if I am using it correctly and I'm sure I am is terrible. To that end I am wanting to float this idea to the developers and am after any suggestions for possibilities of improving it further.


Firstly as much data as possible should be re usable so my idea so far comes down to this:

 

in SchematicPartsDataDir, LibName.lbr <- this would contain the basic data for the pin/smt pad numbers and names for a given part and a reference to a footprint in the schematic footprints library for that part.

in SchematicFootprints, <- this would have a list of all the available footprint types so they would only need to be defined once and not replicated over all the available Libraries - only a reference would be needed.

in PCBPartsDataDir, LibName.par <- this would contain the basic data for the pin/smt pad numbers and names mapped to given points of the physical pcb symbol, or in the event the symbol could be socketed the socket itself.

in PCBPartsFootPrints,  <- this would have a list of all the possible PCB footprints so that again the data could be reference via PCBPartsData and be reusable.

to speed up searches in the SchematicPartsDataDir, SchematicFootprints, PCBPartsDataDir, PCBPartsFootPrints a database would be maintained by eagle containing data appropriate to each section in order to speed up searching.

the ability either as a script or a built in to merge two libraries from the same manufacturer together using a window with 3 panes so the user can select source A, source B, and output to destination C.

 

Advantages:

Schematic and PCB footprints would become reusable.

Searches would become easier and probably faster.

Library sizes would shrink.

Libraries, Schematics, PCBs and all related data would be easier to maintain.

Its easier to fix it now and have a better system working forward than being stuck with a limited library system.

 

Disadvantages.

Possibly would break compatibility with existing libraries.

Would take the developers times to do.

Would cost Cadsoft some money.

 

Reversal - of disadvantages.

Would allow easier and greater development of the Cad libraries with a hugely increased number of parts.

Would probably increase sales as word of the new LMS got out.

It would provide Eagle with the most advanced library editing solution I have seen on the market.

 

So what is everyone else's opinion on this ?

Parents
  • 0

    Am 08.12.2013 01:28, schrieb Chasse Court:

    Advantages:

    Schematic and PCB footprints would become reusable.

     

    They already ARE now: Just drag a COPY of it into the library where you

    need it.

     

    Searches would become easier and probably faster.

     

    No. At the moment, I know EXACTLY where a decice, symbol and footprint

    are situated: All together in their own library. In you proposed

    solution, they might be distributed over lots of files.

     

    Library sizes would shrink.

     

    With hundreds of gigabytes available on the smallest harddisk available,

    I don't care for the few megabytes the copies need.

     

    Libraries, Schematics, PCBs and all related data would be easier to

    maintain.

     

    You're correct in case an error is found in a footprint that has lots of

    copies in other libraries. Currently, ALL of these copies would need to

    be updated (but, as far as I remember, there is a ULP for that

    available). Your suggestion would have an advantage there. But it would

    also have unwanted side effects mentioned below.

     

    Disadvantages.

    Possibly would break compatibility with existing libraries.

    Would take the developers times to do.

    Would cost Cadsoft some money.

     

    Yes.

     

    Would allow easier and greater development of the Cad libraries with a

    hugely increased number of parts.

     

    One reason why I like the CadSoft libraries is that they're simple, easy

    to understand, and do NOT have millions of references, which would need

    complicated databases etc. to make it work at all. Other CAD tools work

    that way, and it seems a mess maintaining...

     

    So what is everyone else's opinion on this ?

     

    As mentioned, some of your points are quite valid, but nevertheless, I'm

    against that idea, due to the following disadvantages, that in my

    opinion are REALLY important:

      1. 'Pointers' to other files always create dependencies on these

         other files. It would then NOT be easy to share libraries (but

         I don't use other people's libraries, anyway), because a dependency

         manager would be necessary, which seems awkward.

      2. DESIRED changes in ONE footprint could very easily lead to UNDESIRED

         changes in another library. E.g. 'that footprint from CadSoft is

         JUST what I need, so I reference it in my own library. But if

         CadSoft afterwards CHANGED that footprint, because they found some

         error, that footprint (which fit PERFECTLY for my component) would

         ALSO change and suddenly NOT fit anymore.'

      3. If some PAD NAME changes are done in one footprint (which can be

         done VERY easily at present), if would immediately BREAK the

         connection to an unknown number of other libraries that reference

         these pads, rendering these libraries UNUSABLE.

     

    Therefore, I view the proposed changes as quite DANGEROUS for the user.

    The possibility of errors would DRASTICALLY increase, and most of these

    errors would not even be visible until a broken reference or an

    undesired footprint change occurred in a project. The only possibility

    to ensure that references etc. do NOT break would be to NEVER, EVER

    change the libraries, which seems somehow counterintuitive...

     

    I would appreciate the POSSIBILITY to have a reference to an 'original'

    footprint from another library, but each library should have its own

    footprints anyway, which would ONLY change if the user EXPLICITLY stated

    'I want to update this footprint (or ALL of them) with changes in the

    referenced library' (the ULP 'update-packages' already does that). The

    same is valid for the symbols (for which NO ULP exists, I think).

     

    Just as an existing layout could be completely destroyed by automatic

    library updates, so could a library with such references, if the

    proposed changes occurred automatically. Therefore: Some additional

    library tools to ease the changes MANUALLY would be welcome, but NOT the

    completely automatic functions proposed.

     

    Andreas Weidner

     

  • 0 in reply to autodeskguest

    Well surely Eagle could be made so that stock PCB part layouts where included in one place and then referenced by schematic libraries, the level of duplication at the moment must be horrendous and the Eagle parts editor is actually quite tedious to use.

     

    But I am asking what is wrong with one library containing all the stock footprints for PCB's and if a user wants to customize they abstract from it.

     

    I feel it would be easier and less maintenance having stock footprints and having the user abstract from a set for individual use.

Reply
  • 0 in reply to autodeskguest

    Well surely Eagle could be made so that stock PCB part layouts where included in one place and then referenced by schematic libraries, the level of duplication at the moment must be horrendous and the Eagle parts editor is actually quite tedious to use.

     

    But I am asking what is wrong with one library containing all the stock footprints for PCB's and if a user wants to customize they abstract from it.

     

    I feel it would be easier and less maintenance having stock footprints and having the user abstract from a set for individual use.

Children
No Data