PcbNew 5.1 updates shorting tracks differently than 5.0

[Seth Hillbrand]

Testing with Alexis' motherboard project from [1]. Open KiCad, launch pcbnew. Zoom in to TP202. Note that it is connected as shown in the attached image. Netname is /CPU0/INIT_B for both the pads and the trace.

Next, update pcb from the schematic.

Now, the trace is connected to /CPU0/INIT_B while the pads are connected to /Northbridge/INIT_B

[1] https://github.com/c4puter/motherboard

Application: kicad
Version: (5.1.0-243-gd70ae19cb8), debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.64.0 OpenSSL/1.1.1b 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-4-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.67.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.64.0
    Compiler: GCC 8.3.0 with C++ ABI 1013

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

[Anton (antonpupkov)]

Not quite clear what's up

[Jon Evans (craftyjon)]

This took me wayyy too long to figure out:
There is no bug here; the design as checked in to Git is not consistent.
The behavior with old and new netlisting algorithms appears to be the same, so I'm going to close this out.

[Seth Hillbrand (sethh)]

@Jon-

I'm concerned by this.

I don't have any issues with the netnames being changed as a result of the algorithm change. But the main issue I saw with this report was that the nets changed their names while the pads did not. This disconnected the pads from the traces. Are you saying that this is expected behavior?

[Jon Evans (craftyjon)]

This is a "problem" in pcbnew and has nothing to do with the new netlisting code in eeschema.
Because of the nature of the design change in the schematic, the pcbnew netlist updater is faced with a situation where both the old and the new net names exist, which seems to trip up the connectivity updater which is responsible for renaming tracks and vias when pads change their name.

We could reopen / update this issue to see if we can get pcbnew to try harder to update tracks/vias in situations like this, as I agree the current behavior is not ideal. I just wanted to take it off my plate of schematic connectivity bugs since it doesn't appear to be one.

[jean-pierre charras (jp-charras)]

Yes, like you, Jon, I am now convinced there is an issue in Pcbnew in connectivity calculations:
It really looks like it does not always rename tracks connected to pads according to the new net of these pads.
Obviously, any track connected to a pad must always inherit the pad net name.

[jean-pierre charras (jp-charras)]

After tests, I am not sure there is an issue in Pcbnew:

The "strange behavior" about the track that does not inherit the pad net name could be due to the fact it connects 2 different nets.
After removing a track segment to avoid connecting these 2 nets, each sub-track correctly inherit net.

I am thinking the behavior in the case is different between 5.0.0 and 5.1.0 version, but I can't say it is broken.

[Jeff Young (jeyjey)]

Shall we close this one as "Won't Fix"?

[Seth Hillbrand (sethh)]

I'd prefer not. This was a valid board in v5, so we shouldn't break it in v6.

[KiCad Janitor (kicad-janitor)]

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