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

[Rene Poeschl]

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.)

[Wayne Stambaugh (stambaughw)]

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.

[Seth Hillbrand (sethh)]

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.

[Bernd Wiebus (bernd-wiebus)]

Hello

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):
https://www.mikrocontroller.net/topic/484055#new

At the attachmend you fill find a zip file called "KiCad_ERC-Error_14Nov2019.zip" 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
Libraries:
    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:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

With best regards: Bernd Wiebus alias dl1eic

[Rene Poeschl (poeschlr)]

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

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/1881