I have been fighting this all day and finally made enough progress to be able to ask a question. In pcbnew, 6.0.6, Win10, sometimes the tracks act like they’re not connected to a pad. Symptoms:
(1) Select a component that has tracks routed to it, hit ‘d’ to drag it, some of the tracks come along with the component, and some detach as if not connected. Ratsnest shows it expects a connection.
(2) Select one of these suspect tracks and try to click-drag it - the main body of the track will rubberband, but the end on the pad stays put, as if it is connected after all.
(3) Delete the segment of the track that goes to the pad. If I reroute from the pad to the remaining track, I get the same behavior as in (1) and (2). But if I reroute from the track to the pad, symptom (1) goes away and all is well.
(4) I discovered this while working with @thanhduongvs 's Length Matching plugin. It computes 0 length for all these tracks that don’t participate in the drag action. Built-in net inspector shows the correct length.
In short, tracks that originate on a pad are weird, but tracks that terminate on a pad are okay. Also the ‘Clean up tracks & vias’ tool seems to make the problem come back if I let it delete tracks inside pads.
It is a bit of a vague area.
Simple answer, is that a track is connected to a pad if DRC does accepts it. However, that does not mean that if a footprint is dragged, a connected track will be dragged with it and stays connected. KiCad has come a long way in the last 5 to 7 years, and the “big” holes have been filled, but it still has quite a lot of smaller areas that are a bit murky. I find PCB Editor / Tools / Cleanup Tracks and Via’s / Delete tracks fully inside pads a completely useless and even slightly dangerous option, and I always turn it off. (The other cleanup options are useful though) I also always connect track ends to the attachment points of pads themselves, simply because it is the most reliable option. It is (currently) also the only option for live dragging a footprint while rubber banding track ends. If a track end is even 1um removed from the pad attachment point, the rubberbanding does not work anymore. This track rubberbanding is a relatively new feature in KiCad, only introduced in KiCad V6. There may be a gitlab issue for improving this behavior, but I have not checked.
Quite recently, a relatively complex feature was added to DRC for when to recognize or flag track connections to pads:
And I don’t really understand why this is done in such a complicated way. I’d say that putting an endpoint or a center line within the boundary of a pad would be simpler and also more universal, as it could also be extended to the track rubberbanding while dragging a footprint.
But overall the KiCad developers are doing a great job. Some 200 issues get fixed each month, which is a quite astounding number.
This case should than be catched by the “not connected”-check.
The approach with tracks always start/end at pad-snapping-points is working (from a users viewpoint) as my last 25 years with eagle showed. It’s a reliable concept but naturally trades reliability against flexibility (kicads current concept were partly overlapping tracks are considered as connected).
It’s a bad example.
- DRC will trigger a violation of a clearance for both the top and bottom pads overlapping with the copper of the center pad.
- It’s zone zone boundary thing, and not about tracks.
It’s a contrived example meant to show a real world problem. You can certainly see that a pad might fit just fine between the clearance lines and alternatively, you might increase the zone clearance to get the same effect.
While I understand that you might not need this particular check, it remains useful to a number of folks and others can simply leave the ignore flag on
As to the zone boundary thing vs tracks, you were wondering why it was complicated instead of just checking tracks and this is why
In cases where the distance is minimal and the area cannot cover the center of the pad, a DRC warning is required
So that the designer can solve the problem by creating a track.
Normally I specifically control the areas while they connect you have pads and in some cases I trace the traces of connection between the pads and then I create the area, so I eliminate at the root the problem of connections to the pads / areas that I don’t like or are not very functional.
In my reasoning, however, a problem is hidden.
Sometimes I use tracks with a width equal to the maximum width of a rectangular SMD pad that causes the track to come out on one side.
In this case, I move the protruding part of the track from the center of the pad to eliminate this spill, but the track is no longer anchored to the center of this pad.
Maybe a DRC check on the warning would be convenient.
When routing is accomplished I would therefore analyze all these cases through the DRC AND by resolving or maintaining this misalignment based on the situation.
I hope to understand the problem correctly.
I know this phenomenon, the track needs to be bold but the SMD-Pad is too narrow.
Some programs offer a “hard” ending of a track at the tracks reference point. That would be a clean solution to me …
No, not really, A track does not have to reach the center (attachment point) of a pad to be recognized by DRC as valid. This is by design and is not an error. When a track does not reach the attachment point of a pad, then you do loose the ability to drag the footprint while keeping the track attached. This is an inconvenience, but not a real problem.
If you do always want tracks to reach the attachment point, then you can draw a narrower track to make up the difference. Another possibility is to edit the pads themselves, by first adding an offset to the pad (relative to it’s attachment point), and then adding an offset to the attachment point in the opposite direction. The result is that the copper of the pad is still in the same location, but the attachment point has moved. It is possible, but probably more trouble then it’s worth.
Can you explain why you consider it a problem?
I didn’t express myself well or the mechanical translation sinned.
It is not a problem because the pcb are corrected and I have the possibility to move the tracks without having the vertex in the hundred.
And that in the set of these links nearby you have pads and in narrow arias known that sometimes sections of spurious tracks are generated which then give warnings that normally at the end of the work they manually delete because the automatic system in some situations erases too much, even though I haven’t used this function lately and it can be improved.
I have to better analyze the case studies that happen in these situations as I know of the problems that are not serious but annoying but I have not yet understood the mechanism or the operations that generate them.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.