Eagle 9.6.2 import in 8.0.1

Long time almost daily user of Eagle with many projects under my belt, mostly 4- and 6-layer.
The importing function runs into problems, which could be fixable. I’m not dissing KiCAD, but there are many differences. Nomenclature is the first that needs to be considered.
Some concepts are similar but not identical.

  1. Main window in Import cannot be re-scaled, but child window can.
  2. Import lists in import “Edit Mapping of Imported Layers” cannot be sorted.
  3. Import list contains every layer in Eagle, used or unused, including those in Schematic, which are not used in Board.
  4. No Layer set in Schematic, the import mixes all original colors into one, layers and line properties are all the same.
  5. Does not handle curved Nets in schematic.
  6. No place to save/recall/make/change custom import function
  7. No way to change errors in import, other than redo the process.
  8. No visibility of imported design rules DRU. No specific DRU object.
  9. No separate import function for ERC/Rules/Board setups.

EagleCAD 9.6.2 has not been updated in 4 years, and will cease being supported in 2026 in lieu of a new Mechanical CAD hybrid monstrosity. I expect prodigious exodus from old users. Making the transition smoother would help, maybe a separate board section dedicated to this purpose.

@mf_ibfeew is extremely familiar and conversant with both Eagle and Kicad.
Using the @ symbol will alert him to see this thread when he next visits the forum. He will certainly make some comments. :slightly_smiling_face:

1 Like

He will certainly make some comments

Yes, definitely. The opportunity to answer a eagle<–>kicad question must be used.

Sadly for the OP I have decided to not use the import function at all. The decision I made for our company is to use kicad for all new projects and remain on eagle for all existing projects. If a older project gets much work (new version) then it’s build from scratch in Kicad. My reason for this decision was: no import function ever will work 100% reliable, and getting a result where I don’t know which part is different to the original eagle project (==undetected error) is much worse than starting from scratch, because i can’t trust the imported result completely. (but that’s only my opinion and not really for discussion, we have other forum members who use import from altium regularly and are satisfied enough with the result).
As a result of this decision I have no real experience with the import function (apart from playing around and bug-confirmation on gitlab). So I’m able to confirm a issue in the import process (if you provide eagle files), but I’m not helpful in the import process in general.

Regarding your numbered list:

  1. I don’t understand. I think you need some screenshots showing the windows/dialogs. Note that some dialogs seem to be size restricted as intended by the programmers (my guess).
  2. would be a new feature request on gitlab
  3. confirmed. The board import should be restricted to layers which are used on the board only. But I think this is not totally easy, as the eagle board file itself defines the schematic layers as available (in the header section of the board file). So ignoring this would be a arbitrary limit (albeit useful) limitation in the import function. Maybe it could work if all unused layers are omitted in the import function. It’s worth a gitlab feature request.
  4. yes, these are limits of the schematic importer. One gitlab issue per “missing” feature please.
  5. yes. As kicad currently does not support curved wires (==nets in schematic) it’s hard to import these curved nets from eagle. There is currently no sign to implement curved wires in eeschema (kicad schematic editor), so I’m not sure if this can be implemented at all.
  6. don’t understand
  7. yes. But only valid for the board import (as the schematic import is not configurable at all)
  8. and 9. there is no option for a 1:1 conversion of eagle drc rules (== dru files) as not all values in the eagle drc dialog could be mapped to corrsponding kicad values. There once was a open gitlab issue (add Board Setup option to import Eagle .dru (design rules files) (#5722) · Issues · KiCad / KiCad Source Code / kicad · GitLab), but it was moved to backlog directory. It’s still possible to thumbs-up the issue, so it might get reopened at some time.

If you are really interested in the importer you should open a gitlab issue for these shortcomings. One complain per issue. As I’m also reading on gitlab I may confirm the issues for you (confirmed issues usually get more attention). If you want to do this: I recommend to use the builtin function Kicad–>Help–>Report bug. This automatically creates a new gitlab issue and prepopulates already the required “version information” section.

Look also at these results from the gitlab search function (which is not the best search function on the world) regarding eagle-related open issues:

These links show already known (and reported) restrictions on the eagle import:

  • no part attributes
  • schematic label / netname import could be improved, label positiong is often unfortunate
  • eagle custom pads are not supported
  • eagle modules are not supported at all

Additionally (found as I played with eagle import):

  • board setup/drc/ dru file completely ignored
  • clearance of netclasses ignored
  • netclasses not supported in schematic import

Last topic:
A dedicated section in this forum would be too much (my opinion), but a dedicated eagle<–>kicad comparison/transition article in the FAQ section could be useful.
Maybe I start with searching my own answers in this forum and collect them in a short article.

2 Likes

Thanks for the long and detailed reply :slightly_smiling_face:

Some clarification:
A. 1. When using the Import Function the whole screen is covered and has a child (pop-up) window that can be re-scaled, but the parent window is locked full screen, This is annoying with only one screen available, for comparing other setups, as they lose focus. Multi monitor NP.

B. 6.The import cannot be pre-customized in a config file, or other way, before the Import function is started. It can be changed, but only during import, and this likely repetitive event cannot be stored. The above impediment does not make it any easier either.

C. 8. and 9. As you stated the import is not 100% reliable, and this is due to paradigm diffrences between the program. The DRC/board setup in Eagle with a 10 tabbed GUI for various settings does not have an equivalent in Ki. This lack of definitions leads to guesses and generalization in the Import with attendant misses and errors.

The not automatic synchronization between Schematic an Board has likely been treated elsewhere, and I was surprised to find it also being bidirectional in Ki, and as a philosophical design issue, I cannot think of any reason to have a ton of code pushing new parts into a schematic from board. Seems like a waste of time.

Other things to get used to the lack of a central Library > Device > Symbol > Footprint > Pin-Pad-connection hierarchical function. As Symbol can be generic and have many different Footprints, sometimes with different pin-pad connections, it looks like in Ki a new symbol is needed for each different footprint, which would imply some library clutter.

I did a search on these issues which did not yield much.

I’m not saying Eagle is perfect, far from it, but it is/was workable, up at least until 2026.
Ki has the potential of becoming a killer app, but I understand it takes resources (i.e. paid staff), and finding commercial sponsors may be hard. Looking at the Linux world may be clue on how things could, perhaps, work better. Overworked devs I understand are giving push-back on issues what they think are not a priority, or not have time for, or totally reject.
That’s where plugins and ULP’s would/could be useful.

It is possible other similar programs can have good ideas too.

How much experience do you have with KiCad? On first sight, it looks like you are running into the “eagle is not KiCad” problem. There is no exact one to one translation for all eagle features to KiCad.

My own knowledge of eagle is very limited. I tried it for about an afternoon, then decided I did not like it, went on to evaluate the next EDA suit and finally settled on KiCad.

I did import a few eagle projects into KiCad. The biggest was Rosco_m68k, the creator of that project was interested in KiCad, and I wanted to test the importer, so I did the initial conversion from eagle to KiCad for him. (Took about 5 minutes), and did a bunch of cleanup (a few hours). Labels were a bit of a mess (there was no alias list back then in KiCad back then) but overall the conversion of the schematic was quite decent, and the PCB conversion was excellent.

I agree with mf_ibfeew, that such an conversion could introduce subtle errors, but I also know that humans are inherently flawed beings. In my opinion, doing the import, and then spending some time for a thorough review is probably a better path then re-doing the whole thing from scratch in KiCad. Especially because a big part of it is automated. For example, if the connectivity in the schematic changes because of an import error, then DRC will flag this difference on the PCB. DRC will also check for track clearances and much more. I don’t know if the net classes and design rules get imported with the project, so that is an area to check / verify. After you’ve done a few conversions, you will probably know both the parts that convert well, and take this into account during the review.

There are also more tools you can use to check the conversion. I have seen for example visual comparisons by overlaying pixel based exports from KiCad schematics and PCB’s. If you can do something similar from the eagle project, you can put both versions in such a program / plugin. Copper zones will probably have small differences, because KiCad use’s it’s own algorithms to generate internal zone geometry.

Hello Paul, and thanks for your input.

I looked at Ki like 12 years ago and decided not to drop Eagle. I have since made ~300 designs with Eagle, and it was not super easy to learn, but I think I have a decent grip on it.
Due to Autodesk’s sad “path forward” I’m looking to replace Eagle, and systematically going thru various aspects of Ki, and how it translates into what I know.
I’m trying it out by import on a 4-layer board with 860 SMD pads and 350 thru hole pads, 2500 drill hits total, PCB about 90x130mm. Schematic and Board .xml files are about 1MB each, a medium size board for what I do.

As I’m going thru the various aspects of the program I’m documenting my findings, which I will post, which may help others in this sphere.

As I found the importing function not working too great, I made a comparison of the two ERC/board setup definitions and found that Ki has 14 copper/drill settings and Eagle has like 64. The Eagle settings are saved in a file, and are offered by various PCB fabricators for simplicity.
I have to find some workaround for this, and I will suggest that Ki up’s their game.

1 Like

I agree,
the import works well enough for my old (and simple) eagle projects but I never continue them directly. I am happy I can read my old schematics and have a look at the old layout as a starting point for a new KiCad layout.
I think KiCad could now even display a picture of the existing layout “below” the new one as a template (ok, that is not useable for complex multilayer boards).