dangling tracks not deleted

Bug #1787190 reported by Franck78 on 2018-08-15
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
KiCad
Low
Seth Hillbrand

Bug Description

Hello,

These tracks are missed by the cleanup function (dangling tracks)

They are not locked.
There is no manual edit/tweak, only Pcbnew work.

Application: kicad
Version: 5.0.0, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.37.0 OpenSSL/1.0.2j zlib/1.2.8 libidn/1.28 libssh2/1.4.3
Platform: Linux 4.4.140-62-default x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,STL containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.61.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.37.0
    Compiler: GCC 4.8.5 with C++ ABI 1002
Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=OFF
    KICAD_SCRIPTING_MODULES=OFF
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

Franck78 (fbourdonnec) wrote :
Franck78 (fbourdonnec) wrote :

the file producing the bad tracks

tags: added: pcbnew
removed: cleanup track
Wayne Stambaugh (stambaughw) wrote :

This may be due to the fact that someone decided that keeping the net set for orphaned traces. I suspect this change is causing the issue here. The question is do we want this behavior or the old behavior where the net was set to zero and removed when clean up tracks was run. I personally liked the previous behavior but I'm guessing if we change it there will be unhappy users. Anyone of the devs have an opinion on this? Should the priority of this bug report be wishlist or low?

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

Personally I don't like keeping the net set for orphaned traces. I often find myself re-using an existing path through the board for something else, and keeping the net keeps other tracks from connecting to it when I re-jigger things.

Wayne Stambaugh (stambaughw) wrote :

Perhaps an option is in order here unless a way can be figured out that solves both problems.

Franck78 (fbourdonnec) wrote :

ah ah, I don't understand any point of view (Wayne, Jeff).

If the segment is locked then don't delete it.

Just use existing options for what they are.

No sure how to produce 'orphaned' segment to verify on another pcb.

A dangling track is a track with a end point connected to nothing, regardless its net.

In this board, *there are no dangling tracks*:
each remaining track has its 2 ends connected.
(This is due to the fact a track end is seen as connected if this end is near (dist < track width) the end of another track, or inside a pad).

Therefore the short track segments have both ends connected to the other track, because the other track width is big enough to contain these 2 ends.

Yes, this is a corner case, but fixing this kind of corner case can create other corner cases.

Franck78 (fbourdonnec) wrote :

Something changed between v4 & v5 simply because I used this cleanup function numerous times, to the point of resolving an annoying segfault.

V4 NEVER left a single piece of unused track (going nowhere). Particularly the pile of microsegments that the router can produce while using moves.
And it also removed any kind of segments going nowhere but connected to a pad. And you know the router is able to produce near perfect circle segments entirely blended in a pad!

Cleanup is cleanup. Don't understand why it would preserve three segments in the middle of nowhere.

I use it as follow, numerous times:
-cut two or more tracks
-cleanup
-reroute the previously messy zone.

Seth Hillbrand (sethh) wrote :

@JP- Which tracks are you referring to? I /think/ the ones in the middle are dangling and should be deleted but maybe I missed what you are seeing?

Seth Hillbrand (sethh) wrote :

Wait, sorry JP, I understand now. You are right.

Changed in kicad:
assignee: nobody → Seth Hillbrand (sethh)
importance: Undecided → Low
milestone: none → 5.0.1

quite often 5.0.0 'forgets' to delete little stubby parts of traces left under pads or just barely sticking out from under the pads, the same applies when a via is placed 'near the end' of a slightly longer trace... cleanup dangling traces simply 'forgets' those.

also it doesn't merge overlapping traces, at all. you can happily place 2 or more vias or traces on top of each other and trying to delete them results in 'specify track 1 track 2 track 3 or via 1 via 2 or via 3'

it also doesn't merge the traces into an overlapping ground zone, when making the ground zone (which is basically just a very big trace) the old traces are still under it, so nothing got 'merged' there either.

the part where it 'forgets' little stubby things partially or wholy hidden under pads, in turn, seems to affect the 'assisted routing' ai in that it seems to try to steer around those remaining trace stubs sometimes, taking sharper corners at ic sockets, causing issues with routing another trace between 2 pins in doing so. also the 'leftover' stubby parts are still considered endpoints by the ratsnest, resulting in 'not very straight' ratsnest lines in some cases. only way to see those little leftovers is to either select the whole area a DIP socket is in and then they show up 'under it' or just move the whole thing and delete them one by one by hand. it's very annoying.

it's actually visible that the merging doesn't work well, as the signal names on the traces are not aligned in the same way for overlapping/joined traces as they are for traces that were drawn in one go. if they were indeed merged, they should all look the same and have the net-names on the same place on the screen.

new traces and vias started in the middle of nowhere appear not to be 'unasssigned' but have their own 'net' so you can't just draw the bus first and then connect things to it. one would think that the desired behaviour for drawing a line or via in the middle of nowhere is for it to have -no- net at first and then join any net that connects to it first. not refuse being connected to anything else.

i think the 'desired behaviour' would at the very least include all the tiny little stubby dots under pads and sticking out the wrong end of vias to be gone. it does clean up all the large bits, sometimes it takes a few goes, but the tiny leftover of traces hidden under pads and (less often) at vias remain. the cnc mill won't give a crap about it (after all metal is metal and it doesn't care wether it's metal due to it being an ic socket pad or an ic socket pad with a trace under it) but sometimes they're visible as they do stick out a bit, and they affect the way in which the trace drawing chooses it's path.

@Seth,

Be careful, this is not an easy fix.
Target it to 6.0, certainly not in 5.01, due to the fact there are many tricky corner cases, and it is a minor issue.

Small track segments fully inside pads are related tricky issues.
Nevertheless, they do not create issues (apart aesthetic problems).

A 'desired behavior' is not always easy to reach and is depending on the guy who write that.
I prefer 'usable behavior'.

Seth Hillbrand (sethh) wrote :

JP-

6.0 it is.

My thinking was this: a track that is _only_ connected to a single other track should be considered dangling. Please let me know which corner cases you are thinking of and I'll see what kind of test harness I can rig up to check them.

The small traces inside pads I feel should be addressed by a completely separate cleanup step that isn't yet extant.

Changed in kicad:
milestone: 5.0.1 → 6.0.0-rc1

Your thinking is good.
The attached case shows a track segment that could be removed.
However, do not remove this small useless track segment does not create DRC issues.

Franck78 (fbourdonnec) wrote :

v4 add not any problems removing all those small pieces of nothing. Unless I'm completly dumb as suggested.

Here is another image of the PCB. With maximum things removed. So, no proximity or whatever preventing deletion.

You want to know what is the problem ? Zones. Refill the zones, apply cleanup and almost all trash is deleted. But not all.

=>Silently refill zones before cleaning.

And I agree with Seth. Any track/via connected to the rastnet is to be deleted.

@Prince Sven, you pretty well described the feeling. Even my eyes can perfectly see those to segments aligned and not merged.... and not the program.

Franck78 (fbourdonnec) wrote :

@JP, where is the corner case in your design ?

Eventually the algorithm will determine that bigger segment have unconnected termination and can be removed, then the medium. Then another pass while determine that the smaller segment is now connected nowhere and also removable.

And yes the smaller segment is undetectable, not annoying.

What do you want to demonstrate here ?

On another 'bug' (net classes width) it's a problem not removing tracks. Here it's a problem removing tracks...... Choose a side.

Jeff Young (jeyjey) wrote :

@cb3rob, have you tried a track starting in the middle of nowhere in 5.0? I'm pretty sure I fixed that so that it gets no net. (It's possible my memory is shot and it's in 5.1....)

Jeff Young (jeyjey) wrote :

I also fixed the path-chaining algorithm in 5.0 to continue chaining through stubs found inside a pad as long as the stubs continue to approach the pad centre. Whether or not that affects under what conditions we *create* the stubs I can't say.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers