element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
    About the element14 Community
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      •  Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Autodesk EAGLE
  • Products
  • More
Autodesk EAGLE
EAGLE User Support (English) EAGLE GUI (5): Missing menus
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Autodesk EAGLE to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 5 replies
  • Subscribers 189 subscribers
  • Views 978 views
  • Users 0 members are here
Related

EAGLE GUI (5): Missing menus

e14 Contributor
e14 Contributor over 14 years ago

As already stated in 'EAGLE GUI(2)', the menu of EAGLE is missing LOTS

of functions. That does of course not mean that EAGLE doesn't HAVE these

functions (it does!), but just that any new user will not KNOW that

these functions exist at all, because they can nowhere be SEEN in the GUI.

 

This is not such an overwhelming problem in the schematics editor

(though there are things to do there, too), but mainly in the board

editor. There, a new user will be frustrated by the lack of the

following functions (amongst lots of others):

  1. Polygons can be drawn, but the resulting copper is never shown.

     Well, of course it is - with RATSNEST, but that is not obvious.

     The menu command to do that even IS available, but in English,

     it is called RATSNEST, and no newbie knows what THAT means,

     and in German, it's called 'Calculate airwires'. Both obviously

     have nothing to do with the copper pour. Only in CadSoft's

     programmer's minds do airwires and copper pour have things in

     common. NOT in the typical user's mind. Seeing this menu entry,

     I myself would NEVER, EVER use it to try to visualise the

     copper pour. Fortunately, this is at least properly mentioned

     in the help pages under the obvious POLYGON command. But

     remember that NOT needing to read help pages or manuals is

     always better than being forced to do so by the program.

  2. Hiding undesired airwires (e.g., for GND, +5V, -5V) is only

     possible via right-clicks on each signal, choosing PROPERTIES

     and then AIRWIRES HIDDEN. Gosh, it took years to find that

     out, and it's so complicated. Why isn't this easier? Well, of

     course it is - with RATSNEST, but that is not obvious. NO

     menu command for hiding or showing signals is available. The

     user has to

      - GUESS that this function DOES exist,

      - GUESS the command name that perhaps will do it and

      - read through all the corresponding help pages

     until, after half an eternity or reading the complete manual

     (whichever is shorter), he either arrives at the correct

     command line syntax, or (highly probable) gives up earlier.

  3. After realising that RATSNEST does THREE completely

     unconnected things (they are ONLY connected in a programmer's

     mind), which are

      - optimising airwires,

      - redisplaying the copper pour and

      - hiding and showing airwires,

     the user may be frustrated that these things are ALWAYS done

     with RATSNEST. Sometimes, a ground polygon is one of the LAST

     things one creates, so at first, there may be lots of airwires

     that are optimised with RATSNEST, and later, after routing

     everything, there will be the ground polygon that will be

     recalculated by RATSNEST. So far, so good. But on DENSE

     layouts, copper pour might become VERY dependent on small

     variations of element positions, so the ground polygon must

     be created FROM THE BEGINNING - and with all airwires still

     there. ALWAYS seeing the ground polygon is frustrating,

     because screen display is not so nice, then, and the time

     needed for polygon recalculation is even MORE frustrating

     if you just want to recalculate airwires with RATSNEST. But

     you NEED that crappy polygon, and why the heck are polygons

     and airwires always calculated at the same time? GRRRR! Well,

     of course they are NOT - with SET POLYGON_RATSNEST OFF, one

     can change that. Unfortunately, though being available in the

     help pages, this behaviour must be changed SO often during

     dense routing that the user types the keyboard to death with

     that syntax.

  4. Did I already mention that, in case of a calculated polygon

     whose copper pour should NOT be shown, the user will

     spectacularly FAIL to find any menu item to HIDE the

     copper pour? That's a case for the command line again.

 

Please don't misunderstand me: As I have proven lots of times, I LIKE

EAGLE's command line, because it's SO wonderful for experts. But it's a

nightmare for beginners, because you have to KNOW what you MAY type, and

how should a new user know the SYNTAX for a certain function if he

doesn't even know of the EXISTENCE of that function (because it's

missing in the GUI)?

 

Therefore: Do NOT only provide menu items for strange and mysterious

commands, but a menu item for every ACTION that the typical user might

often want to use, and name it accordingly (NOT with the command name,

but with the ACTION), so that the user may FIND it.

 

For example, I provide our students with the following (nested) buttons

in the text menu:

  - POLYGON: Calculate polygons

    which does nothing but

      SET POLYGON_RATSNEST ON;

      RATSNEST;

  - POLYGON: Ripup polygons

    which does nothing but

      SET POLYGON_RATSNEST OFF;

      DISPLAY ALL;

      RIPUP @;

      DISPLAY LAST;

  - [plus several other polygon commands to help CREATE polygons

    connected to GND]

  - RATSNEST: Calculate polygons

    which does the SAME as above, just in case somebody cannot

    remember in which text menu it resides

  - RATSNEST: Ignore polygons

    which does nothing but

      SET POLYGON_RATSNEST OFF;

      RATSNEST;

  - AIRWIRES: Hide GND supplies

    which does something similar to

      SET POLYGON_RATSNEST OFF;

      SET CONFIRM YES;

      RATSNEST ! GND;

      SET CONFIRM OFF;

    (But currently still with a ULP, because at that time I created

    that, the SET CONFIRM syntax was not yet invented. I will change

    this to the above syntax in the future)

  - AIRWIRES: Hide V+ supplies

    which does something like

      SET POLYGON_RATSNEST OFF;

      SET CONFIRM YES;

      RATSNEST ! V V VCC* VDD*;

      SET CONFIRM OFF;

  - AIRWIRES: Hide V- supplies

    which does something like

      SET POLYGON_RATSNEST OFF;

      SET CONFIRM YES;

      RATSNEST ! -V V- VEE* VSS*;

      SET CONFIRM OFF;

  - AIRWIRES: Hide all supplies

    which does something like

      SET POLYGON_RATSNEST OFF;

      SET CONFIRM YES;

      RATSNEST ! GND V V VCC* VDD* -V V- VEE* VSS*;

      SET CONFIRM OFF;

  -

  - AIRWIRES: Show all signals

    which does something like

      SET POLYGON_RATSNEST OFF;

      RATSNEST *;

 

This way, the user

  5. SEES that such a thing is possible,

  6. can use it IMMEDIATELY for common cases, and

  7. look the syntax up further if those predefined cases are

     just not enough for the design.

 

And YES, the above is not optimal, because the previous state of

POLYGON_RATSNEST is not restored (I don't know how to do this currently)

etc. But it's still FAR better than having NOTHING!

 

So, just for fun, a screenshot of SOME of the missing items from the

German 'Tools' menu of the board editor (I used a different distribution

than mentioned above to get rid of the strange word 'ratsnest'). All of

these items can be VERY easily included (the syntax is already THERE -

it must only be included in the GUI), with ONE exception:

   - Hide/Show signals...

This would show a (not yet existing) dialog containing a list of ALL

available signals and let the user select which of these to show or

hide. Of course, THAT would need additional thinking and a bit of work,

but the above stuff is REALLY primitive to implement. As should be tons

of other already existing functions that are NOT visible in the GUI yet.

 

Andreas Weidner

 

  • Sign in to reply
  • Cancel
  • kcadsoft
    kcadsoft over 14 years ago in reply to e14 Contributor

    On 11/27/11 18:01, Morten Leikvoll wrote:

    Ref filled polygons.

     

    In 2011, where games does millions of polygons pr second, it also makes

    little sense if these arent filled instantly.

     

    The time consuming part with signal polygons is the

    actual processing. This means that every pad, wire, rectangle

    and other objects must be "subtracted" from a signal polygon.

    This involves a lot of calculations - and that takes some time.

     

    Klaus Schmidinger

    --

    _______________________________________________________________

     

    Klaus Schmidinger                       Phone: +49-8635-6989-10

    CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

    Pleidolfweg 15                          Email:   kls@cadsoft.de

    D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

    _______________________________________________________________

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • e14 Contributor
    e14 Contributor over 14 years ago in reply to e14 Contributor

    I think you would be surprised how powerful even the cheapest gfx is today

    when it comes to simple textured fills like this. There is of course no

    reason for wirefills being faster in any gfx, because they are also drawn

    as polygons at the end of the API.

     

    The only possible downside I can see is that you may sometimes want to hide

    the fills, but that is not a big challenge to solve.

     

    On the other hand I also see the potential for huge optimization when

    calculating contours. Eagle should "ratsnest" them as you design. This is

    not a big win for small boards, but the ratsnest time gets really annoying

    on huge HDI multilayer, where you may have to use thin fills over large

    perforated areas. And if you split the fill onto fine and coarse areas and

    later need to shuffle pieces of the board around you will waste a lot of

    time re-tuning them.

     

    I should also mention that gerber supports fills, but it doesnt handle

    openings inside the contour like Eagle creates. Maybe Eagle should split

    its fills into contours without openings so the gerber fill can be

    utilized.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • e14 Contributor
    e14 Contributor over 14 years ago in reply to e14 Contributor

    Am 27.11.2011 18:01, schrieb Morten Leikvoll:

    In 2011, where games does millions of polygons pr second, it also makes

    little sense if these arent filled instantly.

     

    Those game algorithms are VERY fast, because they rely on two things:

      1. The enclosed volume's surface is defined by a threedimensional

         mesh consisting only of TRIANGLES (which are by necessity plane

         and convex), making HIGHLY optimised code possible.

         EAGLE polygons don't fulfil that, but, in order to keep compatible

         with Gerber, vector plotters and other stuff, consist of a whole

         bunch of VECTOR LINES. Of course, graphics engines ALSO convert

         polygons into lines, but lines of exactly one PIXEL thickness,

         with no additional scaling necessary.

         It WOULD perhaps be possible to just calculate the OUTLINE of

         an EAGLE polygon WITHOUT the fill lines, and let the fill be

         handled by the operating system FOR SCREEN OUTPUT. Perhaps that

         quickens the pace enough for instant filling, but I somehow doubt

         it. For Gerber output or other stuff, the current (slow)

         calculation seems the only decent option to me.

      2. The actual texture calculation is often done directly inside

         the graphics core of the graphics card. Office PCs often don't

         HAVE such a graphics card, and EAGLE shouldn't rely on the

         hardware having one. E.g., I use VERY nice (and somehow

         psychedelic) OpenGL screensavers on my new office PC (which

         HAS a graphics card now), but cannot use them on some OTHER

         PCs I administrate (those have only on-board graphics),

         because without graphics card they are MUCH too slow for fluent

         animation...

     

    Andreas Weidner

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • e14 Contributor
    e14 Contributor over 14 years ago

    Ref filled polygons.

     

    In 2011, where games does millions of polygons pr second, it also makes

    little sense if these arent filled instantly.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • e14 Contributor
    e14 Contributor over 14 years ago

    No quote from  Andreas' post as it is lengthy but it touched on a point dear

    to me; the Text Command Menu

     

    One of the first things a new user does is turn off the Text Command menus

    as they see them as replication of the much prettier icons on the other side

    of the window.

    They agonise over accessing functionality,  start to use ULPs  but somewhat

    amazed they have to run the 'script things' to get stuff done and  never

    realise  the power of the Text menu unless demonstrated  to them. Slowly

    they deduce that some instant functionality could be achieved by setting up

    the Text Command menus and attempt to create them themselves. This can take

    you a lot of time. It is very easy to get the syntax wrong with a typo and

    it takes a long time to sort out why a menu does not work when this happens.

    Later when you want to make a change there is the trepidation of the time it

    could take if you get it wrong, again.

     

    Eagle would benefit from a native functionality  in this area. If it is

    there, people should  find it very quickly and attain the power of the

    customised Text Command  Menu. I would go as far as to say that Eagle

    'requires' the user to customise this tool bar to be productive and yet that

    message is not advertised to the new user.

     

    I did some work some months ago in this area to make it easy to generate the

    Text Menu. Still a work in progress that may not be completed but I can

    layout the desired menu with commands in Excel where it is easy to visualize

    multi layer structures. Then export as a CSV file. A ULP processes that file

    and generates a script which when run generates/displays the working menu.

    Really fast. Some experimentation was done to get this all happing in Eagle

    so an external spread sheet was not needed but I struggled with the

    dialogs/controls  available via ULPs to sensibly display the layered

    structure of the menus. The idea was not progressed any further when icons

    became available for the menus.

     

    What I felt important was an easy way to update the menu very quickly  while

    working. This is something Eagle could do tidily if this functionality was

    native in Eagle.

     

    Eagle is powerful but it is hard to learn how to access that power. You

    cannot find functinality in drop down menus because the functionality  does

    not exist until multiple features are strung together or ULPs are accessed.

    The above is an area where this could be corrected with big rewards for

    relatively little effort.

     

    Warren

     

    --

    Viewed / responded via the newsgroup at

    news.cadsoft.de

     

     

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube