Make net-ties first-class citizens in 6.0

Bug #1799318 reported by José I. Romero on 2018-10-22
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KiCad
Wishlist
Unassigned

Bug Description

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.

tags: added: pcbnew
José I. Romero (jose-cyborg) wrote :

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) wrote :

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

Changed in kicad:
milestone: none → 5.1.0
José I. Romero (jose-cyborg) wrote :

an incompatibility*

Jeff Young (jeyjey) on 2018-10-23
Changed in kicad:
assignee: nobody → Jeff Young (jeyjey)
status: New → In Progress
KiCad Janitor (kicad-janitor) wrote :

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

Changed in kicad:
status: In Progress → Fix Committed
Jeff Young (jeyjey) on 2018-10-23
Changed in kicad:
importance: Undecided → High
José I. Romero (jose-cyborg) wrote :

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) wrote :

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.

Changed in kicad:
status: Fix Committed → New
Jeff Young (jeyjey) wrote :

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) wrote :

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

Seth Hillbrand (sethh) wrote :

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) wrote :

@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) wrote :

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

Changed in kicad:
status: New → Fix Committed
Seth Hillbrand (sethh) wrote :

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) wrote :

@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) wrote :

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) wrote :

@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) wrote :

@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) wrote :

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) wrote :

@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) wrote :

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) wrote :

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) wrote :

>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) wrote :

> 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) wrote :

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

Seth Hillbrand (sethh) wrote :

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

Changed in kicad:
milestone: 5.1.0 → 6.0.0-rc1
status: Fix Committed → Triaged
Jeff Young (jeyjey) on 2019-03-07
Changed in kicad:
assignee: Jeff Young (jeyjey) → nobody
Jeff Young (jeyjey) on 2019-04-09
summary: - Net ties do not work anymore
+ Make net-ties first-class citizens in 6.0
Changed in kicad:
importance: High → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers