PCB DRC Control – How to find all reported errors?

PCB DRC Control – How to find all them reported errors?


What do you mean with

When you right clicked an error it shows you the cause of two of them in the popup menu.

Euhm, read the text in the popup menu?

In the screenshot from @01:32 I also see that your (overlapping) location of C32 is exactly the same as from C27, and these are not the default locations for the Silksreen references. Where do these capacitor footprints come from?
A quick way to “repair” a lot of these is to edit the library symbol with the footprint editor, and then update the PCB with that new capacitor footprint.

Over 650 errors may seem daunting, but it’s quite normal. I see a lot of Silkscreen overlap, and a silkscreen cleanup pass is a normal part of each PCB design. It’s not very productive to try to get each of them from the DRC menu. Instead, Hide all layers except one of the silkscreen layers, and then move / rotate all silkscreen texts to a proper location.

I also see a bunch of “Unconnected track end” warnings. You can possibly clean these up with PCB Editor / Tools / Cleanup Tracks & Via’s. This automatic cleanup may clean up too much, so it’s nice to have a backup before you start experimenting with this.

For me the behavior is also different.
When I click on an item in the DRC window, the item gets highlighted and the PCB Editor pans to the error location. I’ve been looking through the settings to find an option for that, but I could not find it.

I did find PCB Editor / Preferences / Preferences / PCB Editor / Display Options / Cross-probing, but even when I turn those all off, the PCB Editor still pans to the error location. I’m guessing that this “cross-probing” is only between the PCB and the Schematic.

Thanks for your reply paul, yes I know all this, but what I mention here is the functions of the software, it’s no direct connection between the DRC popup window and the PCB editor, it doesn’t “jump” to the error when clicking the error in the dialog box.

“For me the behavior is also different.
When I click on an item in the DRC window, the item gets highlighted and the PCB Editor pans to the error location. I’ve been looking through the settings to find an option for that, but I could not find it.”

That is what I also want.

This is how it works for me:

And I still can’t figure out what setting it is that influences it.
I’ve been looking into this before, because sometimes I want to turn the pan off. Each time DRC is run, it automatically pans to the first error in the list, and sometimes I just want to concentrate on a specific area of the PCB and want to re-run DRC to check how many errors have disappeared in only the area i’m interested in.

Application: KiCad PCB Editor

Version: 5.99.0-unknown-ef74421922~134~ubuntu20.04.1, release build

	wxWidgets 3.0.4
	libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3

Platform: Linux 5.4.0-88-generic x86_64, 64 bit, Little endian, wxGTK, xfce, x11

Build Info:
	Date: Oct  2 2021 07:45:57
	wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
	Boost: 1.71.0
	OCC: 7.5.2
	Curl: 7.68.0
	ngspice: 31
	Compiler: GCC 9.3.0 with C++ ABI 1013

Build settings:

This doesn’t work for me, neither, on Windows nightly builds. It works in the other way: clicking on the arrow moves the list highlight in the dialog. But the arrow isn’t centered and highlighted when I click the list item. It has worked in the past.

@Qbort has changed the DRC dialog code recently, maybe it’s a new bug?

I updated to the latest available nightly and it also does not work for me anymore.
I created a bug report for it:

Yep, the way it works seems to have “reversed”.
By clicking on a marker, it also shows the error message in the status area at the bottom of the screen. (I don’t know if it did so previously) In the “old” behavior, you can also highlight the items which generate the DRC violation, see for example the two Footprint REF at 00:09 in the previous screencast, and this can be useful information on a crowded PCB.

1 Like

I also reported it a few hours ago, and got a fast reply it is now fixed and will be in the next nightly build! That’s a great developers response…

Yes the commit you referred to was exactly to fix this bug.

The latest nightly does not yet have the fix included but you should see the fix in a few days (whenever the nightly gets built for your platform)

I see now you just closed the issue I opened as a duplicate (which is probably good).

I did search open issues before making a bug report, and therefore missed the already closed issue.
So for the next time, please create a links to the user forum and back to gitlab when using multiple websites for the same topic.

Also, I do not like it much when movies of KiCad bugs are floating around on youtube out of context. Therefore a request to either remove the video or make a followup as soon as the bug is fixed.

Issue created at: Oct 10, 2021 6:13pm GMT+0200, and “Fix Committed” at
Oct 10, 2021 6:41pm GMT+0200. That’s 28 minutes later.

paul, do you say here I should remove the video from youtube about the DRC bug right now?

I also think it would be better to have those old bugreport videos not lying around. They aren’t useful at all in youtube after the problem has been fixed and can give outdated information to people and even be harmful for searches, hiding actually useful results below them. Videos can be attached here and in the gitlab bugreports directly, and that’s useful, they are even embedded.

Ok eelik, thanks for the info.