Eagle import DRC shows unconnected pins. Way to fix?

I have a GPL project that I imported from Eagle 7.x. using 5.1.6. Unfortunately, I am on Mac OSX 10.13. My iMac (10.12) at home cannot be upgraded, even though it is I7, due to Apple’s checks, I might be able to defeat that, but have not tried. So 5.1.6 is the current usable one, due to forcing OSX 10.14.

First, I am really impressed with the import process. I got a board out of KiCad which looks good, and a schematic which is (mostly) what was input. Very good job, indeed!

The board looks good, the schematic looks good. However Schematic DRC complains about unconnected pins. DRC on the board complains about trace overlap when a trace goes to a pad. I see that the schematic is not seeing the connector pin for that pad connected to the trace, so it complains. An attempt to fix it on the PCB by deleting the segment and re-routing shows that dramatically.

I am still learning KiCad. It could be something simple on my part, but after 8 hours of YouTube, Google, and Forum searches, I am not convinced it is me. I think it is just a matter of some very little additional polish needed in the import process. (Or in the ability to force connect close pins to close wires on the schematic with some user intervention).

KiCad seems to have an issue with connecting close but not there traces to pins if you are using something other than 50mil.

The original schematic is not on 50 or 100mil, it is on 10 mil. (I know, bad deal, but it is similar to other projects dumped in my lap.)

I went to a spacing of 1 mil and moved the connector to fix the “off trace” connection (for instance) and received a “dot” on the wire, but when I reran the DRC it still said the pin was not connected.

Eagle lets you do a “move” on a part, back and forth, and then on the schematic it creates a connection when the wires are close but not yet connected using dots. You can then delete the dangling net components and move on. Any similar process for KiCad? I was unable to discover such a method.

I really don’t want to re-draw the schematic in KiCad if I can avoid it. These unconnected errors bother me, even though the board looks usable. I would hesitate to release this as a KiCad with unconnected pins.

I can provide the eagle project if interested.


Eeschema has “No Connection Flags” in the right toolbar ( and in Eeschema / Place / No Connect Flag)

Some think these are silly, but I find them quite useful. Any open pin is flagged as an ERC violation in KiCad, unless it has one of these flags, and this helps against accidentally leaving pins open.

(Eeschema has ERC = Electrical Rule Check, while Pcbnew has DRC = Design Rule Check).

Posting the exact text of an error message makes it easier to diagnose what the actual error is. I assume that the design rules are not setup properly, and this results in a clearance violation. You can set track widths and the clearance around it with Pcbnew / File / Board Setup / Design Rules / Net Clases.

Yes indeed. This is a long existing limitation in KiCad. Eeschema depends on an exact match between the attachment points of pins, and the start points of the green wires that connect them, and the easiest way to satisfy this constraint is to draw the whole schematic on a grid of “50”.

Setting your grid to “1” in KiCad makes it almost impossible to connect wires to schematic symbols. As a compromise you could set your grid to “10” for these imported schematics. This makes it a bit finicky to attach wires to pins, but it’s still doable.

In the screenshot below, the connection to pin 7 is 1 grid point away, while the connection on pin 44 is made properly.

When KiCad recognizes the connection, then the small circle and square disappear.

You can drag off grid schematic symbols onto a coarser grid, by first setting the grid (to for example the default “50mil”) then hover the mouse cursor over a schematic symbol (or wire, or a corner of two wires), then press g for “grab” and move the mouse cursor a bit.

Sorry, I was not clear.
The pins with “no connection” have wires going to them. They should be connected.

The ERC overlap error is the trace going to the pad associated with that pin, which kicad thinks has no connection even though there is a wire. Hence the overlap error.

The issue I am reporting is not regarding the problems inside kicad with these details, even though they are annoying.

The issue is the import failed to connect these wires even though they were connected in the Eagle files.

SORRY, the ERC is the complainer about the pad overlap. The DRC is the complainer about the pin connection.

I will try to get screen shots later today, not sure how to put an image into the message.

The best thing to try would be to see if the Eagle design is imported correctly in the nightly build (or 6.0-rc1). There have been many improvements to the Eagle importer since 5.1.

If the nightly build still has this problem, please open a bug report and we will investigate.

ok. Will have to figure out how to upgrade my Macintosh to 10.14, even though Apple says my iMac cannot be upgraded. Ugh.

Ah, I missed the fact you were running an old version of macOS. Unfortunately I’m not sure what else to suggest – due to limited resources we are unable to solve the challenges of building for older macOS as well as continuing to support the new ones that keep getting released…

OK. I was able to get a 10.14 Virtual machine up and running.

YOU CHANGED THE RULES AGAIN. It requires a 10.15 machine now!!!

I think you can make things work for older macintoshes by using something like vmware (or the free oracle VirtualBox) and run an earlier MacOS. You can host an entire development environment in that. I have done that to build and/or test some of my code that I want to run on older machines.

Apple’s dirty little secret is there is not a lot of change between versions and the older code runs quite well on newer versions, but complains when launching.

I will try to install a 10.15 machine now. Is it just because you guys are trying to keep up with Apple’s latest?

Question: Can I build on an older mac, or has that bus left the station? I am debating internally, as time is always at a premium.

Not us, but Apple and our upstream dependencies.

As far as I know, KiCad itself can build on older macOS. The problem is getting all the dependencies sorted out: Homebrew drops support for older macOS, so you may have to build some from source at older versions.

LOL. So it can be built on older versions, but it can’t be built because Apple changed the rules. Believe it or not, I more or less understand your viewpoint. There are only so many hours in the day. I am on High Sierra due to the hours in a day issue. Every new install breaks something on the Mac, as it does in Windows.

Regardless, I was able to get VirtualBox working, and installed Catalina and got KiCad nightly installed. (VirtualBox is almost there . Requires a lot of babying and searching. Sierra started the issues with “sip” (which you have run into, just look up “csrutil”) and Apple has continued this in Catalina. This is part of Apple’s virus protection schema.)

Good news. The error reported on the overlaps of the copper on pads are gone on the DRC after the new imports.

The Schematic still shows multiple NoConnections, because the original schematic is not on 100 mil or 50 mil. There are a couple of unconnected (air wires) on the copper, but that is expected, they are air wires on eagle, unfinished routes.

So, the question is, if the Eagle shows it is connected, and it creates a good board from Eagle, and all of the Eagle DRC / ERC shows good, should the import work? (Or is that “not a problem” because it is not on your 50 mil “requirement?” If this is the issue, can a bug report be filed requesting a script that, under user control, connects these by moving wires or parts or both? Zooming on KiCad is iffy. the board shifts under the mouse and requires many movements to track the zoom. Makes it difficult to re-orient from 10 mil to 50 mil.)

If this is something that should have worked with connected schematic wires, then I will figure out how to fill out a bug report and will give you the schematic and board. If not, I will ignore this issue and not pursue KiCad for a while. I would probably use it under VMWare and Linux if I do move forward, but that is a bit slower.

It doesn’t matter whether or not things are on a 50 mil grid. It matters whether or not wire endpoints exactly overlap with pin endpoints. The 50 mil grid is just the standard way to make it easy to achieve that requirement. If the importer is creating a KiCad schematic that doesn’t match up with the Eagle schematic, that is a bug to fix – if you open an issue with the schematic in question, we can investigate it.

There are different zooms available. Check in preferences / preferences.

In particular, it sounds like “center and warp cursor on zoom” which can be disabled. However, it’s also a very nice feature once you get used to it.

OK. Re-ran the import and the ERC looks good now. The initial import shows dotted line for nets, changed to solid after the ERC.

The disabling of Center and Warp Cursor solved the (to me) wandering schematic issue on zoom. At age 66, my eyes are terrible. I zoom in and out a lot. It is a good selection for me.

I consider this issue solved if you are not a hobby user with outdated hardware. If you are, tough luck on Macintosh. KiCad is now moving into professional territory.


If you consider the “Center and Warp” function as:

Then it means you did not understand this function.

I fully agree with:

The way it works is that when you zoom with the scroll wheel, then the schematic is panned to center the current cursor location to the center of the screen.

In a more “conventional” function you just zoom while keeping the center location of the cursor the same. Effectively this means that if you want a close-up of the upper left corner, you first move to the lower right, then zoom out so the upper left corner comes into view, then move to the upper left corner and zoom in there again.

With the “Center and Warp” function, you start by moving the mouse cursor in the direction of where you want to go, then zoom out, which also pans your area of interest to the center of the screen, and when your “upper left corner” is visible, you move the mouse cursor there and zoom in, which also puts this area of interest in the center of the screen.

I like this method a lot, but I do admit I had some difficulty to get used to it.
But you first have to understand how it works.
Second step is to get used to how to use it effectively.
Then you get hooked and do not want to go back to those “other” methods.


I can’t remember the last time I used Pan.


I mentioned different zooms because you seemed concerned about instabilities in zoom.

As the others suggest, it is well worth persevering with.
Navigation soon becomes zoom out - move mouse - zoom in.
Shortly, you will start cursing all the other programs because their zoom doesn’t work as effectively as Kicad. :slightly_smiling_face:

I think I have seen that kind of zoom before, but it worked slightly differently.

The KiCad zoom moves the mouse cursor zoom point to the center of the screen. Then the next mouse click moves the current mouse cursor zoom point to the center of the screen.

So, you have to only click one wheel click at a time. I am way too spastic for that.

The other zooms I have used did that, but then re-centered the mouse to the middle of the screen, which is what happens when you uncheck the box in the preferences.

To me, this falls into the category of editors. It is almost a religion. I would never come between a designer and his editor (or his zoom preference)!


1 Like

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