Issues related to zones and nets

Layout
1

We’re currently evaluating whether we ditch Orcad for KiCad, and we stumbled on the following issues related to zones.

Issue #1

When disconnecting a via or a track from a pad, the via/track will lose its associated net. This also means that vias will lose their connection with a copper zone.

What makes this especially dangerous is that this effect does not take place immediately: The consequences are visible only after closing Pcbnew and re-opening it, so you might not even notice that something went wrong (for example, a via which previously connected two ground planes on different layers does not connect them anymore).

Steps to reproduce:

  1. Track from R1 GND pad to via in ground plane:

    1593×420 13.8 KB

  2. Remove part of this track and press ‘B’:

    1538×350 12.9 KB

    (via is still connected)

  3. Save your design, close Pcbnew, reopen it, and press ‘B’:

    1585×420 13.8 KB

    (via lost connection)

Relevant *.kicad_pcb part before closing and re-opening:
(segment (start 132.3 64.75) (end 128.1 64.75) (width 0.25) (layer F.Cu) (net 1))
(segment (start 128.1 64.75) (end 127.35 65.5) (width 0.25) (layer F.Cu) (net 1))

After closing and re-opening:
(segment (start 119.85 64.4) (end 120.7 65.25) (width 0.25) (layer F.Cu) (net 0))
(via (at 120.7 65.25) (size 0.8) (drill 0.4) (layers F.Cu B.Cu) (net 0))

Note that the nets of the track segment and the via changed to 0.

Issue #2

When connecting two zones with a track, the track does not get the net of the zones, and it will have no connection.

Steps to reproduce:

  1. Two zones on the GND net.

    1690×537 13.6 KB

  2. Draw a track from the first zone to the second and press ‘B’:

    1619×413 13 KB

    (clearance around the track, zones are not connected)

Issue #3

It is not possible to manually assign a net to a track or to a via, so you can’t use vias to, for example, connect two overlapping ground planes without connecting all vias with tracks to ground pads. This is an old problem, see https://bugs.launchpad.net/kicad/+bug/999057

–––

My question is: Are those behaviors intended the way they are (which would make KiCad unsuited for our purposes), or do the developers consider them to be bugs?

We would be willing to contribute code to fix those issues, but only if there’s a chance that our patches would be accepted (and we don’t want to maintain a company-internal fork).

1 Like
2

I think not many KiCad developers visit this user forum, here is KiCad developers mailing list: https://lists.launchpad.net/kicad-developers/
I’m sure your patches will be more than welcomed!

1 Like
3

You only found three? Yes zones are particularly problematic and have been for quite some time. Re-reading the netlist or rebuilding board connectivity can also cause a zone to lose it’s net association sometimes causing the zone to disappear, the outline is still there but it is no longer filled. And as you point out, stitching vias between zones don’t work without a track to connect them to the same net as the zone.

This is one of the frustrating aspects of KiCAD. While it is a nice tool there are still serious long-standing bugs that have not been dealt with. Meanwhile the developers are busy changing the drawing canvas, adding spice simulation, changing file formats, library formats, etc. I’m all for improving KiCAD and some of the new features available in the new OpenGL canvas are certainly nice. But at the moment, with the latest stable release, we’re stuck with something half way between legacy and some future version which still has many of the legacy bugs. In my opinion we would be better off if they had maintained the legacy version and not released the new version until it was ready. But that’s just my opinion. :unamused:

4

I think i read somewhere, that the legacy code was not really maintainable. (And it depends on some outside libraries which are kind of outdated.)

5

These issues are listed are valid, but there are ways around them.

Issue 1 isn’t a biggy for me, because I’m going to run DRC before I send a board out every time and it’ll throw an unconnected error.

Issue 2 is solved by this well-known work around: https://www.youtube.com/watch?v=vQ-p9Yl6Rm8

Issue 3 is either solved by drawing a trace between R1-Pad2 and W2 (my preference) or using a method similar to Issue 2 in which you create a small single-pad SMT part.

That being said, this is an open source project and I’m sure the developers would be happy to merge in code to fix these issues. More users means more exposure, which can help draw new developers (it seems like recently there have been a few more names on the mailing list). A big draw for the folks I work with was the text file format of the design files, which lends itself well to Git integration.

2 Likes
6

It is not quite that bad.
The problem is that ‘B’ is not really that smart, it just refloods.
What you need is DRC, which should actually be called
Design Regenerate and Rule Check, a rename I have already suggested.
This should also be done, just before PLOT. Do not do just B before plot!!!.

Given the Data base impacts of missing DRC before plot, it has been suggested this is the default, but the developers are strangely averse to such discipline, seemingly preferring novices learn the hard way…

A design load does the same regenerate.

What is regenerate ?
If you look at kiCad database, there are no polylines on traces, so net-ownership needs a scan-pass to find traces that overlap PADS, and traces that touch.
This is actually quite smart, and allows NET import to rename whole nets. Other CAD pgms have problems with conflicts in the same situation.

Somewhat related to #1, - KiCad does not rebuild a floating-trace-within-zone, it does check for trace-trace connections, so if you route that from existing traces, that should be fine.

Yes, there are request in to allow KiCad PCB to create connections without NET import.
See also other posts, around using PCB without a SCH eg netlist generate tools.
Some simple PCBs do not need any NETLIST to create.

Given the kicad database, this change should be relatively easy.

My feeling is, anything you can do with a simple-edit of the kicad_pcb file, you should be able to also do via the GUI.
Assign/change NET names is one of those things.

Re placing Vias - again, related to that ‘regenerate’ - you cannot drop a via onto mid-trace, and expect it to stay connected.
The test used is a trace end within the Pad, and Route-Add via, will break the trace, so it has corners, and now they are inside the via.

There is scope here, to add some smarts to an Add-via, so it looks for traces, or even adds segments, so that net-ownership can be preserved on regenerate.

expanding this - you can use that regenerate feature, to help here
Example:
I just added 4 free vias, using ^D, NET name is blank.
Next, I allow DRC violations and disable Shove.
Now, Add-track can connect those Vias,and lastly, I route to a GND pin.
Running D®RC now assigns GND tags to those traces and vias.

You could call this connect-by-later-attach.

4 Likes
7

If you are serious about this, there are things that can be done within the existing menu-frameworks, that can get part way to a more free data entry.

Another test example:

Manually add traces to a connector.
This can be done, and will save/plot, but fails DRC because NET names do not exist.

Some tests:
Import of a File with some manually added lines
(net 39 "Net-(J2-Pad3)") (net 99 "AddJ9a") (net 100 "AddJ9b") (net 101 "AddJ9c") (net 102 "AddJ9d")
is OK, and View,Nets shows all 4 new net names - b&c I also connected to PADS
a & d are unallocated.
Note it has auto-packed the net number on load.

785×440 30.4 KB

Above is what I get after I Edit PIn1, to paste AddJ9a, before I run DRC.
After I run DRRC, that 0 flips to 1
If I paste AddJ9a into Pin2, & DRRC, I get 2.
ie I can attach a new net name, with 0-pins, to any pins with traces.
DRRC also will auto-name those NETS, as part of regenerate.

Conclusion: the missing piece from manual-file edit, is the ability to add a free (new) net name.

I see a couple of choices (maybe both?)-

  • Expand present View NET form, to allow ADD NEW NET line
    (becomes the same as my paste into kicad_pcb)
    & why not allow edit-net-name in there too, with a warning it can diverge from SCH, if one exists.
  • On Pin Edit - paste Net-Name, instead of present “ERROR unknown net name”
    change to a simple choice
    Warning Unknown Net Name “namegiven”, [cancel] [Add to net list]

The second choice, allows free-trace connect, with assigned net names.

Next step (but more work) would be a ROUTE menu addition that was
“New track & Auto Net”

This would auto-assign a new net-name, based on the starting pin, using the standard rule "Net-(J2-Pad3)"

I have a script that can export NET files from a PCB, so this can be audit-tracked/checked.

8

Only a dedicated KiCAD fan could marginalize such issues! :wink:

You mean it only does exactly what it is supposed to do?

Call it what you want but DRC couldn’t care less that your thermal vias are isolated from your thermal zone. It doesn’t even mind that a zone is not filled at all.

WTF?

It should not be necessary to allow DRC violations in such a case. If a via is not assigned to a net then the first connection made to it should assign it the net name of that track.

But more importantly net associations to vias and zones should not be lost when the boards connectivity is rebuilt just because they are not enforced by the netlist.

It seems silly to me to marginalize these issues just because there are workarounds, some of which are more inconvenient than others. Of course there are workarounds otherwise KiCAD would not be as useful as it is. But that is certainly no justification for not fixing the underlying issues!

As I have said elsewhere, I think the KiCAD developer’s time would be better spent bringing PCBNew to a more complete state rather than changing EESchema which is currently not nearly as handicapped as PCBNew.

9

@1.21Gigawatts, if you got problems with the direction/focus of the KiCAD development team, please clear this with them on their mailing list and get involved - I’m sure they need any help they can get, especially if it’s pull requests for features.
Try to stick to the topic and problem of the thread. The OP is not helped with this derailing.
Thanks.

2 Likes
10

By agreeing with the op that these issues should be addressed I am derailing? Okay, interesting perspective. My apologies, I will refrain.

11

You need to re-read my posts.
I have attempted to explain how the data base works, and knowing that can help users understand and
predict what it will do.
I have even tested some things, and added suggestions on how the existing kicad can be modestly changed, to avoid some of these issues, since the OP did ask/offer to do a code patch.
Feel free to add your own patch.

?? Err, actually, DRC does manage zones, because part of DRC is to refill.
Another part of DRC is to regenerate the database, so yes, it does also care about via placement.
You seem to have totally missed the point here.