Feature request: track snap-and-confine-to-pad

I wonder whether this has been suggested and/or is planned as a feature for upcoming releases; I think it goes well with the general theme of teardrops (although not at all the same purpose).

Let’s explain by showing what the problem is: I’m routing a track that carries VDD, so I want it as thick as possible. This detail always annoys me:


I’m referring to what happens when the track connects to the target pad, where it goes past the pad’s area. At this thickness, it is still DRC-compliant; but if it was a bit thicker (which, no reason why I wouldn’t want to make it as thick as the longer dimension of pin 16), then it would get too close or even cover pin 15. If I manually retract the track to make it fit, then these also-annoying things happen:


I retracted it further back than necessary, to make the issue more obvious. The two things are: the weird angle (and narrower contact width) at the contact between the track and the pad; and also, the DRC now complains (since it sees the track’s endpoint as not connected to the pad — I would claim that this is a bug, independent of this situation; but I don’t want to go there in this post)

The feature request: wouldn’t it be great that I simply go ahead and, regardless of the track’s thickness (assuming that it fits within the longer pad’s dimension), I just go ahead and move the cursor and make it snap to the pad’s center, and just click and have KiCAD produce the following?

Just like that: the track’s endpoint gets confined to the pad’s area, connecting properly, right-angles at the contact between the track and the pad, etc.

I should be able to get that even if the track’s width matches the longer pad’s dimension:


And BTW, in all cases, it should also work if I start the track at the pad.

If this has not been suggested and is not being planned: anyone with me on this view/opinion?


Yes, many. See https://gitlab.com/kicad/code/kicad/-/issues/2250#note_288648458.


While i get and understand the request and the questions you posse, there are many issues surrounding this. Most ECAD tools do or offer some other menial way around these simple requests, likely for good reason as im sure you are not the first to encounter this.

Anyways, i would like to confirm your KICAD version, because the seconds image in your post should have passed DRC. While i understand the concern for the angle, most often than not, the board etching (if the angle and notch is small enough) would likely not be as apparent on the actual PCB. I did something similar here in not dragging the track all the way to the center of the pad and it still passed DRC. My example below…

Now regarding the menial ways around these issues, might i offer either copper zones or copper polygons. These offer a little more flexibility in terms of getting things to line up how you actually want them too. See image below of the copper zone.

Hope this helps.

Should have passed the DRC? Why do you say that? I have the latest version (well, there seems to be a newer 5.1.6, at least through Ubuntu — newer than the 5.1.6 that I have; and I have not upgraded), but my observation (and I’m just confirming with a minimal example of a board with two resistors) has been that if the center of the track’s endpoint is not exactly at the centre of the pad, KiCAD considers that the track is not connected to the pad (thus, the DRC fails).

I wonder whether we’re using different terminology? I include “missing connections” as part of the DRC; so, if there are missing connections, I call that “not passing the DRC” … Maybe DRC is more specific, and refers only to violations of minimum sizes or spaces, etc.?

Granted that a small angle should not be a big deal … Well, sort of agreed … But still, the issue of usability remains: getting the track to end at the exact point, not the pad’s centre yet the edge of the track matching the edge of the pad, that can be tricky. Generally speaking, it’s an issue of: why would I (as the user) have to bother with such a detail when I have a computer working for me, that can manage those annoying/tedious details for me?

As for the copper zones: yes, that’s what I most often end up doing (especially in cases like your example, where two adjacent pads get connected together); but you have to agree, that is an unbelievable pain (I mean, in relative terms: compared to the very little effort that involves routing tracks: just move, wait for the cursor to snap, then click… with copper zones: zoom-in, zoom-out, move here, move there, click, oh no, it was one grid-space off… no worries, come back later to edit the vertex’s position … all that for each vertex of the zone … )

Actually, I realize that there is a “bug” in this statement — if the track goes past the centre of the pad while passing through the centre (i.e., the line representing the centre of the track passes through the centre of the pad), then there is a connection, and my statement above would suggest that there isn’t.

Ah. I think i understand how the DRC works in regarding unconnected nets… Looks like maybe we are both right and wrong maybe?? Doing some quick testing, below is two images. The first shows the DRC failing when the center of the tracks endpoint in not yet past the edge of the pad but still partially overlapping the pad. While the second image shows the DRC passing once the center of the tracks endpoint passes, or at least touches, the edge of the pad.

Anyways, while i do agree with you and am on your side wanting a better solution. Im just not sure what that solution should look like. With the mentions you have from your first post, it would seem like a good suggestion. At least until someone considers what to do when the track is larger than that of the pad… On the note of suggestions, i am however partial to the link posted by eelik that points to other suggestions that involve changing how the track endpoints look. ie, square, rounded, or other.

FYI, i do think terminology is a bit weird here lol. Not having played much around with kicad’s source yet, i have no idea what the correct terminology for what we are actually discussing here is.

Interesting! So, the rule seems to be: if the track’s endpoint (the “centre of the track’s endpoint”) is inside the pad’s area, then pcbnew considers that the track and the pad are connected. I think the reason why I had never noticed is that it is non-trivial to make the track get to a point as per those conditions (because as soon as the endpoint is within the pad’s area, the cursor snaps to the centre of the pad… there are ways around this, but we are already off-topic, so let’s leave it there :‒) ).


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.