Inconsistent Net Names when importing from EAGLE

Trying to import a layout from EAGLE 9.6.2 († June 7th, 2026) schematics and layout are imported.
When checking closer the layout has the same net names as the original Eagle layout whereas the schematic has new net names for all automatically generated nets (N$*) from Eagle.

  • On a project with a single sheet schematic net names are transfered if there has been any visible label on that net placed in the Eagle schematic. KiCad places these labels a similar position in the schematic, but removes any label decoration (arrowed frame) from Eagle (GND / Q2_B / N$7).
    grafik
    When using the “Highlight Nets” function in eeschema the nets are only highlighted in eeschema, but not in pcbnew.
  • For Eagle projects with more than one sheet eeschema additionally adds global label symbols to nets with labels that appear on several pages. When using “Highlight Nets” on these nets these nets are highlighted both in eeschema and pcbnew. While other nets still are only highlighted in eeschema.

I have been trying to understand the discussion in gitlab issue #13571 and gitlab issue #14620, but could not really follow along.
I have spend some time fiddling around with it and it seems to me that the problem is this:

  • For each new net Eagle generates a N$* and can remember this even if this net name is not displayed.
  • KiCad names nets according to part names and pins that the net is being connected to.
  • If a net has another name in KiCad it has to be placed as label near the track of the net.
  • When importing from Eagle and using the automatic Eagle net names eeschema woulod have to add and print a label “N$*” to each net since KiCads net labeling works different to Eagle.

What I still do not understand is why net highlighting in pcbnew only works for global labels.

This behaviour will irritate many new users that want to migrate to KiCad.

After some more fiddeling I noticed that if I uncheck the “Replace footprints with those specified in the schematic” in the Update PCB from Schematic dialog
grafik
I can overwrite the automatically generated net names from Eagle in the PCB with the newly auto generated net names from KiCad.

I can live with changing automatically generated net names for an import. However the way to update the net names by unchecking above option doesn’t seem straightforward.
I would appreciate to have some kind of notice to users when they are importing on how to fix issues between schematic and PCB.

Do mention which version of KiCad you are using (Help->About->Copy KiCad information)

Probably not. When autodesk bought eagle a bunch of years ago, a lot of people switched to KiCad, and more followed when autodesk made the thing “cloud only”, stopped linux support, abandoned (or scheduled to abandon?) the “free” version of eagle. Whatever. There are some roubles with conversions, but most I heard people were quite happy to switch to KiCad.

I have done some imports of eagle projects myself. (But it was a few years ago I did this for the last time) Not my own projects, but mostly just to test the importer and it “mostly worked” quite good. So, now that makes wonder what is going on with your project.

Last time I did an import, labels were imported as local labels i KiCad. Apparently labels in eagle are global labels by default.

For labeled nets. I do not know how “Label Decoration” works in eagle. KiCad only has local, global and hierarchical labels (Net directive labels are a different sort of thing). Or maybe KiCad does have “Label Decoration” for global labels. They look differently depending on whether they are input / output / bidirectional / passive. Best I know this is only a visual difference and has no further consequences for the connectivity or ERC. You label in eagle looks similar to what a global label in KiCad would look like. Is this supposed to be a global label?

No. KiCad just uses it’s own naming scheme for auto generated net names (i.e. all nets without a label).

The option: Replace footprints with those specified in the schematic is normally on. In KiCad, the schematic and the attributes attached to schematic symbols (such as footprint links) are the reference. It is possible this does not always work, for example if there is some discrepancy in the library setup, which is something that can happen during a conversion.

The option: Re-link footprints to schematic symbols based on their reference designators is normally off. However, the first time after a conversion it is possible the schematic and the PCB are not synchronized with each other. In that case you have to use this option (Once!) to regenerate the UUID’s that KiCad normally uses to synchronize the schematic and PCB with each other. (These UUID’s are normally not visible to users).

This probably is some synchronization issue. If the old (eagle generated) net names are still used in the PCB, but the schematic has the auto-generated netnames according to the KiCad naming, then you first have to update the PCB to synchronize them.

No. Net highlighting (and cross probing) works for all nets, symbols to footprints, pins of symbols to pads of footprints.

Is your eagle project publicly accessible? I could have a look at what is needed for successful conversion. It would be nice to have a document with details of how to do such a conversion, but such detailed documents tend to go out of sync with the software quite easily when the software is being improved.

This problem with the importer is worse than this example shows.

In Eagle, nets are objects just like components. Thus they all have names, whether user assigned or not. If the user doesn’t assign a name, it’s given a generated name of the form “N$x” where “x” is a unique decimal number.

KiCad has no concept of nets as objects. When KiCad imports an Eagle project, all the net names on the board are lost unless the net (1) crosses a schematic page boundary, or (2) has an explicit global label object attached to it.

I came to KiCad from Eagle in the middle of a project. My intent was to switch to KiCad for the remainder of the project, but the loss of net names caused so many problems that I had to revert to using my perpetually-licensed copy of Eagle v7 to finish the project.

So, yes, Eagle users do care about this.

Above tests were conducted with KiCad x64 on x64 Version: 8.0.4, release build
For the tests I have created this small test project with ony one sheet:
Blinky.zip (142.9 KB)
With this the nets with labels are converted as follows:


Using the Net Higlight in eeschema there is highlighting of nets in eeschema, but not in pcbnew.
This is strange, as the named nets VCC, GND, Q2_B and N$7 are also present in the PCB-layout.

In the gitlab issues there was a discussion about global labels (Eagle doesn’t know anything about) so I added another sheet to the above project and added some labels in Eagle to link nets between schematics.

Only labels being present on both schematic pages were converted by eeschema to
grafik
for only these nets the highlighting function works:


For all other nets the highlighting does not work!

Regarding the general user experience for somebody doing this the first time would be pretty disappointing.

I perfectly understand that another update step (update board from schematic) is necessary.
But I would like to have a hint being presented that informs the average user how to synchronise schematic and PCB (Keep in mind that Eagle users are used to having f/b annotation).

here is the 2page Eagle project and the conversion output from KiCad
blinky2Page.zip (122.5 KB)

I’ll have a look at your example project and see where it goes.

12:55 Download.
12:56 Created new, empty kicad project.
12:58 Project manager / File / Import Non KiCad Project (This created yet another project).
13:09 After the import (20 seconds?) I’ve been looking around a bit. DRC mentiones some open track ends and a whole lot of minor silkscreen issues.
13:12 Apparently KiCad now preserves all old eagle net names as N$x where “x” is a number. I guess this is an “improvement” since the last time I used this importer. I would probably delete these auto generated net labels.
13:15 KiCad does not preserve all netnames. On page 2 the N$x labels are not present.
13:16 I can confirm that net highlighting only works for the global nets.
13:19 Cross probing of symbols with footprint works.
13:26 Update PCB from Schematic [F8] attempt.
13:30 KiCad wants to delete all footprints from the PCB. I did not let it do that.
13:31 After [F8] (and preserving footprints) cross probing for any nets except the three global names still does not work. But cross probing between symbols / footprint still works.
13:33 KiCad’s project imported has created a library. Symbols in the schematic point to “base names” while the footprints on the PCB (and in the library itself) have numbers added.

paul@cezanne:~/downloads/blinky2Page/blinky2Page/blinky2Page.pretty$ ls -hl
total 36K
-rw-rw-r-- 1 paul paul 7,9K Aug  8 12:57 1X04_325.kicad_mod
-rw-rw-r-- 1 paul paul 3,3K Aug  8 12:57 C1206_348.kicad_mod
-rw-rw-r-- 1 paul paul 4,9K Aug  8 12:57 CHIPLED_0603_259.kicad_mod
-rw-rw-r-- 1 paul paul 3,3K Aug  8 12:57 R0603_334.kicad_mod
-rw-rw-r-- 1 paul paul 3,3K Aug  8 12:57 R0603_348.kicad_mod
-rw-rw-r-- 1 paul paul 3,2K Aug  8 12:57 SML0805_259.kicad_mod
-rw-rw-r-- 1 paul paul 3,2K Aug  8 12:57 SOT23-BEC_398.kicad_mod

13:36 Deleted all the extra numbers from the files in the library.
13:40 After fiddling with settings I discovered why the net highlighting does not work. KiCad uses full path names for label names on the PCB. In the Update PCB from Schematic [F8] I see things like: Reconnect R1 pin 2 from N$5 to /blinky2Page_1/N$5. In KiCad all local net names start with a slash, even if they are on the root page. Global net names (labels) do not start with a slash.

To be continued.

13:50 Re-reading this topic to better understand the problems mentioned.

I have a lot of trouble interpreting your post. for example:

What is “new” here? KiCad places labels with the same net names. I do not understand the difference.

Another example:

Venting your frustration is both useless and contra productive. There are a gazillion volunteers working on the KiCad project, and they are all doing their best to improve KiCad. Such a statement also has 0.0 value for solving a problem. If it does anything, then it’s more likely to get you ignored then to get you more help.

13:55 Delete of KiCad project.
13:56 Fresh import of eagle project.
13:58 I can confirm what I discovered @13:40 KiCad generated a local label Q1_B in the schematic. The corresponding track on the PCB also has the Q1_B net name, but this is only correct if the schematic label was a global label. If it’s not mentioned yet on gitlab, this should be reported so it can be fixed.
14:02 Connection between R5 and LED3 has name N$@ on the PCB, but no label at all on the schematic. Why are all nets on page 1 labeled, but not on page 2? I do not know what this looks like in eagle. Were there any labels in the eagle project? (I don’t have that program) In the screenshots they look light grey, is this some “auto” feature?

14:13 So apparently they do have (manually placed) labels in eagle too.

Conclusions

1. Net names

So I’ve identified / confirmed two problems. (@13:40 @13:58) the net names issue with the difference with global / local net names. This should be (maybe already is) reported on gitlab. On itself it’s not a big issue, as net names get resolved mostly automatically when a project is fully converted (The PCB editor easily adopts any name for tracks that it is given by the schematic).

2. Added numbers in library footprints.

In the schematic the footprint link for R1 looks like: blinky2Page:R0603, while on the PCB (and in the exported library) the footprint has the name: blinkyPage:R0603_384. All the other footprints have added numbers too, as shown @13:33. I do not know why KiCad does this. Because of this name difference, the schematic editor can not find the footprints, and therefore this prevents it from properly updating the PCB with [F8].

Edit: There is already a gitlab issue for this:

14:25. Gosh, that makes it an hour and a half (with maybe 10 minutes of distraction in between).

I found this.

Wayne Stambaugh added an In Progress label to it 4 months ago. If (serious) work is being done on a better importer, then all issues with the old importer get a much lower priority.

In issue #13571 there is a mention of XREF in eagle. I don’t know what those are, can’t help there.

Dear Paul,
Thank you so much for so carefully reproducing the import and your detailled analysis.
I will have to take more time to read and digest.

But regarding two things I want to reply directly to hopefully avoid any further distraction.

Regarding:

I want to point out that I am absolutely thrilled about the KiCad project and cannot say how grateful I am for the countless efforts that the core team and zillions of volunteers have put in this project. And with my statement above I did not want to hurt anybody’s feelings. Sorry for my bad wording.

According to my understanding of the discussion in gitlab KiCad cannot import autogen Eagle net unless adding a visible net label (cluttering the schematic) to each net that doesn’t yet have a label. So mole123 has proposed the (I guess) implemented way net names are being translated.

This leads to a mismatch between net names in eeschema and pcbnew after the importer has finished which I believe is undesireable, especially if you are not familiar with KiCad.
I only proposed that there should be some helping hand explaining how to continue from here!

Regarding:

Sorry for not being clear in my inital post. New meant that an autogenerated net name from Eagle (N$*, picture below RED) would be altered during the Import to the BLUE net names (KiCad naming scheme).

grafik

(In Eagle the function label can be used to assign and place a net label. These labels manually placed near a wire. Such labels are recorded with <label x="40.64" y="30.48" size="1.778" layer="95"/> in the ` section of the *.sch file. Eagle only knows global nets, so the following are identical)
grafik

My fault! I should have added a picture of the Eagle screen:
grafik

Ok, so you added net labels to page 1 in eagle before you did the conversion, but not to page 2. That explains the difference.

Something I do not understand is why would auto generated net names be worth preserving in the first place. KiCad gives them different names. Does that matter? KiCad can not make a direct conversion between any other program and KiCad. Attempting to do so would force KiCad to make a big mess, for example by adding local labels on all nets. In a KiCad schematic there is just no method at all to name a net without putting a label on it. Tracks in the PCB editor generally do have net names, but they can change any time the PCB is updated, or even when a track is moved and overlaps with another net.

I guess most of the problems with project import is from not understanding KiCad very well. This is of course understandable, as many such conversions will be done when someone who has experience (and projects) in that other program, and wants to continue in KiCad.

Several years ago Rene_Poschl wrote an FAQ article about differences between KiCad and eagle. I don’t know how relevant it is.

Also, any user is free to write some documentation. The FAQ article above is for example editable by many forum users. If you’ve gained some new insigts during project conversion, feel free to update it. Note that changes made are logged with some version control system (probably GIT). This makes mistakes or even deliberate sabotage or spam (it is the internet after all) easy to undo.

What happens when you run [F8] on a freshly imported Eagle project with these settings:
grafik

Those are the settings I used to prevent KiCad from deleting the existing footprints from the PCB. Something was probably different the first time I did it. When I do it now, net highlighting works for the nets with the local “eagle” named labels.

Do note that if I delete all the local labels from the schematic, and then update the PCB again, the connectivity is still OK. Only those net names have changed to KiCad’s auto generated naming scheme. Q1_B has just been renamed to Net-(C2-Pad1)

Looking into the Eagle *.BRD file the number can be found and it seems to be associated somehow to the library that the footprint originated. Maybe this is how they ensure that footprints from various libraries with same name are not overwritten. :thinking:

<library name="transistor-npn" urn="urn:adsk.eagle:library:398">
<description>&lt;b&gt;NPN Transistors&lt;/b&gt;&lt;p&gt;
... ;</description>
<packages>
<package name="SOT23-BEC" urn="urn:adsk.eagle:footprint:28685/1" library_version="6">

results in SOT23-BEC_398.kicad_mod

Yes! Can also confirm this.
Please keep in mind though that users transfering from Eagle are used to the automatic forward / backward annotation (…which is often a pain …). Maybe KiCad Docs would be the place to tell them that [F8] is their friend!

KiCad’s manuals could be improved in this regard. The chapter about importing from other EDA tools is very short. It does not even mention all EDA suites for which KiCad has importers. But the manuals are not the place for extensive tutorials. An article such as I mentioned earlier is a much better place for that. Previous eagle users will have to get used to it that KiCad works differently and a tutorial that explains the differences between KiCad and eagle is a much better place.

According to the links in:

even users with “trust level” basic can update Wiki articles and thus you should be able to update that FAQ article written be Rene Poschl. Updating such articles is a good way to give something back to the KiCad project. And while working on it, you will probably learn a few new things about KiCad too. I never used eagle myself and will not modify that article.

Hi @paulvdh and others,

Please note the second last line of the “New Member Information” FAQ:
NOTE: some Trust Level abilities have been modified by Administration.

Wiki articles are one of the abilities that have been modified by Admin; not by Mods.
Wiki articles are only able to be created and/or edited by Level 3 (Regular) and higher.
Level 0 (New Users), Level 1 (Basic) & Level 2 (Member) are unable to create or edit Wikis.

Dear Paul,
thank you very much for the extensive discussion of this topic and all the time you have invested.
Hopefully Eagle users in this forum might find these lines and manage migration.
I am planning to attend 2024 KiCon in Bochum. I will discuss with the team how I can best contribute.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.