dangling tracks not deleted

the file producing the bad tracks

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?

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.

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

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.

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.

@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?

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

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'.

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.

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.

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.

@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.

@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....)

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.

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