ERC no longer works with hidden power pins

[Ron Burkey]

After upgrading KiCad today (my previous update had been last week or the week before, I believe) eeschema's ERC no longer works the way it had been with hidden power/ground pins on my components. The same schematics which passed ERC last week, now show hundreds of errors.

I have many, many schematics affected by this problem, but an example of a schematic that was error free last Friday but error-ridden today (Monday) is here: https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005263-

(I don't know if it makes any difference, but the schematic is structured as follows, in so far as power and ground are concerned. There are two sheets, tied together by a parent sheet. There are 3 power/ground buses, called FAP, 0VDCA, and +4SW. Each of these buses has a single PWR_FLAG, located on the parent sheet. All of the components with hidden FAP, 0VDCA, and +4SW pins are on the two child sheets.)

Application: kicad
Version: 5.1.0-unknown-a81512c~82~ubuntu16.04.1, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.11 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-53-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Ron Burkey (rburkey)]

As an afterthought, it occurred to me to wonder if the netlists are affected by the same problem. They are not. A netlist generated today is identical to the one generated last week, and indicates that the hidden power/ground pins are connected correctly.

[Jon Evans (craftyjon)]

This should be fixed in the next build (after c07de84) -- please advise if it isn't.

[Ron Burkey (rburkey)]

On 04/08/2019 10:22 AM, Jon Evans wrote:
> This should be fixed in the next build (after c07de84) -- please advise
> if it isn't.
>
> ** Changed in: kicad
> Status: New => Fix Committed
>
> ** Changed in: kicad
> Assignee: (unassigned) => Jon Evans (craftyjon)
>
> ** Changed in: kicad
> Importance: Undecided => Medium
>
> ** Changed in: kicad
> Milestone: None => 6.0.0-rc1
>
Cool! Will do.

[Ron Burkey (rburkey)]

The fix has now shown up in the nightly build, but the ERC is extremely flaky with respect to hidden power/ground pins in components. Sometimes it works, and sometimes it does not.

It is difficult to characterize when it works vs fails, because KiCad often aborts and exits without warning when running the ERC, but it seems to me that it works more often when the net label and the PWR_FLAG are on the _same_ wire segment, and usually fails when the net label and PWR_FLAG are on different wire segments (but still on the same net). Netlists are correct in either case.

I've attached an image combining a couple of screenshots illustrating this. (They happen to be from this design: https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006541B.)

In this design, components have a hidden +3VDC pin and a hidden 0VDC pin. The long arrows are the PWR_FLAG components. At the top of the attached image, there's a configuration in which ERC gives hundreds of errors that the +3VDC and 0VDC pins are not connected. As you see, the net labels for those buses are separated from the PWR_FLAGs by an extra wire segment.

At the bottom of the attached image, there's a configuration in which the ERC gives 0 errors. I have moved the +3VDC PWR_FLAG to the same wire segment as its net label, but not the 0VDC PWR_FLAG. Remarkably, _both_ types of no-connect errors (+3VDC _and_ 0VDC) vanish from the ERC.

I actually had to move the +3VDC PWR_FLAG a couple of times to get it to work, so my observation that just putting the net label and the PWR_FLAG on the same segment can't be exactly right.

[Ron Burkey (rburkey)]

I forgot to add the new versioning info in my last post:

Application: kicad
Version: 5.1.0-unknown-e90452d~82~ubuntu16.04.1, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.11 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-53-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Jon Evans (craftyjon)]

Hi Ron, can you please check again after df600fc (so tonight's nightly)

[Ron Burkey (rburkey)]

Yesterday I had checked about 30 or so schematics, Jon, with perhaps 2/3 of them passing ERC and 1/3 failing. (That's just a general idea, not exact counts.) I only rechecked 5 of them with last night's build. 4 that failed yesterday still fail today, and 1 that passed yesterday still passes. It's probably of no use to you, but their URLs are:

* Fail 1: https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006556r
* Fail 2: https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006557D
* Fail 3: https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2003305B
* Fail 4: https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/2005269-
* Success: https://github.com/virtualagc/virtualagc/tree/schematics/Schematics/1006559D

Unfortunately, I don't understand the build system, so I don't really understand how to verify that the latest build I just installed (from PPA "deb http://ppa.launchpad.net/js-reynaud/ppa-kicad/ubuntu xenial main") incorporates your fix or not. There always seems to be a delay of a few days or even a week from when I see notices that a fix is incorporated to when I can actually verify it is working properly.

Application: kicad
Version: 5.1.0-unknown-ca7aec2~82~ubuntu16.04.1, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.11 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-53-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Jon Evans (craftyjon)]

Hi Ron,
Your version 5.1.0-unknown-ca7aec2 does not include my latest fixes.
It looks like this was built an hour or so before my fixes went up, so it should be in the next one.

[Ron Burkey (rburkey)]

It looks like what I thought were nightly builds are not nightly builds at all. So ignore my previous comment. I'll get back to you when I have the actual nightly build installed.

[Jon Evans (craftyjon)]

They are nightly, I was just not remembering the time the build is triggered each night. I put in my fixes after the build was already started, so unfortunately they won't be included until the next nightly.

If you want to check a version against the commit history without using Git on your local computer, you can browse the repository using Launchpad or the GitHub mirror (GitHub has nicer UI): https://github.com/KiCad/kicad-source-mirror/commits/master

The string after the "unknown" in your nightly versions is a Git hash (ca7aec2), it uniquely identifies each commit. If you find the matching commit in "master" branch (for nightly builds), you will know the latest change that is in your build.

[Ron Burkey (rburkey)]

That's a relief! I'll try again tomorrow.

[Ron Burkey (rburkey)]

Jon, I've gone through and rerun every ERC that failed for me, I believe. There were quite a lot of them, and they all seem to work fine now.

Great job, thanks!

(Since it looks like you did the fixes for bug #1824359 as well, I can also comment that those warnings have gone away for me as well.)