Suggestion: ERC report for pin not driven should prioritize real power input pins over power symbols

Bug #1821436 reported by Rene Poeschl
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Right now it kind of depends on the exact placement and number of pins which pin ERC points to on error.

I think having a priority for which symbols to prioritize in the error message might add a lot. Especially for the pins not driven error message as pointing to power symbols is kind of useless if there are other non driven pins on the same net. (If i for example have a voltage regulator on that net then i would expect the power input pins of that regulator to be the source of the error not the GND symbol connected to it.)

See screenshot for two slightly different schematics with vastly different error messages. On the second one i added an invisible pin with number 4 to the L7805 symbol which meant that now the GND symbol was pointed to as the source of error. (That pin is not even connected to the same net as the gnd symbol.)

Tags: eeschema erc
Revision history for this message
Rene Poeschl (poeschlr) wrote :
Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

This is probably due to the way the netlist generator orders symbols. I suppose we could check for the first non-power symbol pin in the net to display in the ERC warning message.

Changed in kicad:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Seth Hillbrand (sethh) wrote :

If we collect the full list of pins on the net, we can sort the invisible pins to the end and then pick the first in the list. Since we don't have a dedicated power flag, we can't just skip the power input items or even the invisible power inputs. But we could de-prioritize them.

Jon Evans (craftyjon)
Changed in kicad:
assignee: nobody → Jon Evans (craftyjon)
Jon Evans (craftyjon)
Changed in kicad:
milestone: none → 6.0.0-rc1
tags: added: eeschema erc
Revision history for this message
Bernd Wiebus (bernd-wiebus) wrote :


There is an similar issue with power symbols/flags
If i connect +5V, PWR_FLAG and GNDREF direct, as an example, and i run an ERC with default settings, i get NO Error, but i should.
This is done with the default settings of the ERC Matrix.
Of course, if i put a power flag to the different voltages separatly, i get an error message if i connect #5V and GNDREF direct. (Not at the point where the error happens, but somewhere at the declaration, which is also nasty)

But somehow there should be a check that there is only one label bound to a net. In my opinion it is not good to name a net with different labels. If i want to tie different labels, as an example analog ground and digital ground, it should be done with a sort of "net tie". (But this will rise another issues with copper in footprints and DRC at PCBnew) So at least a warning should be thrown.

It happens for me with an older version of KiCad: 5.0.2+dfsg1-1, release build, (details further below) but some discussions show me, that the problem will exist in newer versions also.

Link to this discussion (german, sorry):

At the attachmend you fill find a zip file called "" with a KiCad Projekt "Test1" which contains the bad schematic, a picture "Picture_BadSchematic_Test1_14Nov2019.png" with the bad schematic and a picture "Picture_ERC-Defaults_Test1_14Nov2019.png" of the dafault ERC matrix.

And now the version in detail:

Application: kicad
Version: 5.0.2+dfsg1-1, release build
    wxWidgets 3.0.4
    libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Platform: Linux 4.19.0-6-686-pae i686, 32 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.67.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.62.0
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:

With best regards: Bernd Wiebus alias dl1eic

Revision history for this message
Rene Poeschl (poeschlr) wrote :

Your request has nothing to do with this bug report. Make a separate report.

Revision history for this message
KiCad Janitor (kicad-janitor) wrote :

KiCad bug tracker has moved to Gitlab. This report is now available here:

Changed in kicad:
status: Triaged → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.