Make net-ties first-class citizens in 6.0

[José I. Romero]

Following the trick in this tutorial https://www.youtube.com/watch?v=YmUivtQGiH0 does not work anymore as DRC will now unconditionally recognize graphical elements in copper layers as elements that affect the connectivity.

Note I am not against the DRC being able to detect graphical copper, but this change breaks valid designs that were using this "feature", as it is the only way to make net ties in Kicad. One way this could be fixed is to allow the graphical copper to be turned off per design (probably easiest), or per footprint as it is done in some professional ECAD software.

Note that this does not only affect net ties but also components realized with graphical copper, like PCB inductors will present this problem also.

[José I. Romero (jose-cyborg)]

Version information

Application: kicad
Version: (6.0.0-rc1-dev-928-g51deb9d56), release build
Libraries:
    wxWidgets 3.0.2
Platform: Linux 4.9.0-8-amd64 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.62.0
    OpenCASCADE Community Edition: 6.8.0
    Compiler: GCC 6.3.0 with C++ ABI 1010

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

Looks like this commit might have originated the change, this is post 5.0, so it _will_ create a compatibility with 5.1 unless there is some change https://git.launchpad.net/kicad/commit/?id=7b4f9cef506b6f39d0b813a5889add5d69c13664

[Nick Østergaard (nickoe)]

As this looks like a regressions stability wise for 5.1 I will mark the milsetone for it as well.

[José I. Romero (jose-cyborg)]

an incompatibility*

[KiCad Janitor (kicad-janitor)]

Fixed in revision a96dbde7389a8f4d409aee38d42666a5821efc9a
https://git.launchpad.net/kicad/patch/?id=a96dbde7389a8f4d409aee38d42666a5821efc9a

[José I. Romero (jose-cyborg)]

Unfortunately this fix alone did not do it for my net ties. I have attached a minimal fragment that shows the issue. If you try routing towards the net tie in the PNS it will not let you reach it. If you try routing from the net tie you get a nag dialog saying you cant start from a keepout.

One of the traces is routed, you can run DRC and see that there are errors related to the graphical element touching the track.

Version info:

Application: pcbnew
Version: (6.0.0-rc1-dev-1009-g96e65c7f2), release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.52.1 GnuTLS/3.5.8 zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Platform: Linux 4.9.0-8-amd64 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.62.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.52.1
    Compiler: GCC 6.3.0 with C++ ABI 1010

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_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=OFF

[Tomasz Wlostowski (twlostow)]

Gentlemen, let's discuss this before making any fixes. I would like to see what options we have before the P&S code becomes aware of any workarounds like the net ties one.

[Jeff Young (jeyjey)]

Yeah, this fix will only work if your net-tie pads are at least {clearance} larger than your connecting copper. Since your pads are the same size as the width of your copper, it fails.

Most of the examples I saw were connecting two zones. How common is something like José's usage?

[Seth Hillbrand (sethh)]

I think this is the common case as this is what is included in the libraries.

[Seth Hillbrand (sethh)]

I take it back. A bit more examining, José's net tie uses a segment instead of a polygon. The polygon works fine. The library netties also use polygons

[Jeff Young (jeyjey)]

@Tom, I've attached a very simple fix which handles both DRC and PNS. It isolates the workaround (net-tie footprints must contain "net tie" at the start of their keywords) to a single line. Let me know what you think.

[KiCad Janitor (kicad-janitor)]

Fixed in revision 34395515437118f4eff0f04792aa04316f9232cf
https://git.launchpad.net/kicad/patch/?id=34395515437118f4eff0f04792aa04316f9232cf

[Seth Hillbrand (sethh)]

Hi Jeff-

This fix is pretty delicate and requires a specific keyword to change the router behavior. It feels like we're putting a file format into the keywords? Is there no other way?

[Wayne Stambaugh (stambaughw)]

@Jeff, I meant to comment on this sooner but it just got lost in the noise. Your solution is a bit fragile. I'm assuming you based your decision to search for "net ties" in the footprint description because all of the footprints in the KiCad NetTie library have "net tie" in the description. The problem is this behavior will not work for users who have made their own net tie footprints and failed to add "net tie" to the description. Even worse would be the case were "net tie" was in the footprint description but the footprint wasn't actually a net tie. Granted the risk is low but not zero. If we cannot find a better way to handle this, we may have to live with it until v6 when we can update the footprint file format to support net ties.

[Jeff Young (jeyjey)]

I completely agree with the comments. However, we need some sort of work-around until we can change the file format.

We tried the pure heuristics approach (comment #4), which was nearly successful but in the end didn't quite do the trick (comment #5).

I'm certainly open to other suggestions. The "hack" part is a single line of code, so it's easy to change to something else.

I did also consider using a flag (which we store in the file), but that seemed like a hack on top of a hack.

[Seth Hillbrand (sethh)]

@Jeff-

The previous commit you made (#4) works for the official net ties library. That should cover almost everyone.

For the rest, I'd suggest we add a temporary "Ignore footprint copper" checkbox in the DRC dialog. Then people with problematic, custom footprints can still check the box and get their same DRC as they saw in 5.0.

Thoughts?

[Jeff Young (jeyjey)]

@Seth, the #4 commit only works when the pad is at least {clearance} larger than the connecting copper shape. If it's not then the router won't let you route to the pads and DRC will complain.

I think the advantage of the #11 solution is that it works with the existing libraries, it's safe, and it gives us a "get out of jail" card to give to users who have issues before 6.0 is ready.

The "ignore footprint copper" is arguably no less of a hack while definitely being less safe (for those who use it, anyway).

[Seth Hillbrand (sethh)]

Hmm... I don't have any issues with the official library net ties and just #4. Either in routing or DRC. (video attached)

Were you seeing different behavior?

[Jeff Young (jeyjey)]

@Seth, I think the difference is that your net-tie pad is already assigned the correct net. Set it to no net (as if it just came from the library), and I think you'll find that it doesn't work.

[Seth Hillbrand (sethh)]

Hmm... Maybe (can't check right now) but that's because I have it in the schematic.

If the requirement is that users need to assign their net before the net tie works, that might be acceptable, no? Or is there a use case I'm overlooking?

[Jeff Young (jeyjey)]

To be honest, it never occurred to me to put them in the schematic. Doing so has other advantages, such as being specific to a pair of nets. Trouble is its discoverability is pretty poor.

[Seth Hillbrand (sethh)]

>Trouble is its discoverability is pretty poor.

Funny, that's what I was thinking about your suggestion! :) Good to have different approaches.

Can we solve the discoverability with simply documenting how to do Net ties?

We can also ask Alexis to revise her previous video on the net tie work around she did for v4.

[Jeff Young (jeyjey)]

> Funny, that's what I was thinking about your suggestion!

Sure, but there's a difference: the #11 trick only needs to be discovered when the out-of-the-box net-ties fail to work. So it's more about us having a fall-back to give to users in those cases than discoverability.

The discoverability of the #4 solution is required even when using out-of-the-box net-ties.

So I'd still lean toward #11, although I wouldn't veto #4 with some doc.

[Jeff Young (jeyjey)]

@Alexis, your thoughts here would be great if you have a moment....

[Seth Hillbrand (sethh)]

I'm going to re-set this issue so that we don't lose track of the full fix.

I also re-pushed the graphical mod from #4 to allow polygons in other footprints like the solder_jumpers

[David Mosberger (r-davidm)]

What's the latest on this?

I tried to use the NetTie_2 symbol in kicad-nightly (as of last night) but I couldn't associate a footprint with it and after updating the PCB, the rats nest only shows one of the nets. Am I missing something completely obvious?

[Jeff Young (jeyjey)]

The bug database has moved to GitLab: https://gitlab.com/kicad/code/kicad/-/issues/2265

[David Mosberger (r-davidm)]

Got it, thanks.

[KiCad Janitor (kicad-janitor)]

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