Pad connection problems

Am having a lot of trouble finding the answer to this issue. Using v8 I have some footprints that I’ve created that include vias and segments and arcs - (these are for custom button contacts).
(simliar to this post : Turn shapes into a pad)

kicad_Qx3A9UpwKe

It’s driving me crazy because I’ve got some old footprints that were created with v7 and they work.
None of the methods that searches recommend are yielding connectable points anywhere along these nets - even though the ratlines show they should be connectable.

Here’s what happens when trying to connect from the via - (a DRC violation won’t allow it to begin from there) (ack, apparently new users can’t include multiple images - will add below…)

… any clues or suggestions are appreciated!

DRC Violation when originating a track at the via …

OK - there is something deeper going on here, some of the vias on my footprint do in fact connect just fine. Could it be that there is copper on both sides of the board on the upper vias?

kicad_rmncet8SrM

First, it’s nice of you to have searched the forum for anwers first, but people here do not like to re-read old threads and it’s preferred if you start a new thread for a question. (You can link to an older thread if you think it helps).

Then there is a difference between pads and via’s. Via’s are light grey with an orange center, while THT (Through Hole Technology) pads are orange with a black center. They are different entities, with different uses, so use the correct words to avoid confusion.

I also looked at your screenshots an hour or so ago, but there is not much to tell from a simple screenshot. You can try to use: PCB Editor / Inspect / Clearance Resolution and PCB Editor / Inspect / Constraints Resolution to see if those give you a pointer in the right direction.

If you run PCB Editor / Inspect / Design Rule Checker, does that give any additional information.

One thing that is a small annoyance for me in KiCad, is that THT pads are painted as black circles instead of open holes (this is apparently performance issue). But as a result things inside the hole do get “painted over” by black. A common cause for The routing point violates DRC if there are lines on the Edge.Cuts layer inside the hole. Some footprints from those internet libraries have this. You can move the footprint to see if there is anything underneath (then [Ctrl + z] to undo, or File / Revert to undo the move). You can also open the footprint in the footprint editor, and then start deleting items to see if you see anything strange within the footprint itself.

@paulvdh - Thanks for creating a new thread and letting me know the best practices there!

I’ve managed to figure my way out of the situation described above, (via a workaround at least) - if not fully getting to the root cause of the non-connectable features.

My situation is uncommon and may be an edge-case, but I’ll try to describe it for future adventurers and any insight it may provide to the devs. The footprint in the example above is a special case in that it contains an SMD part on the bottom layer, the part gets connected to the two vias that also connect to the copper shapes on the top layer (copper shapes that form the button contacts).

For whatever reason when the footprint part contains connections to the top and bottom of the via it is unconnectable when placed. Once I realized this I just deleted the (bottom-side) tracks in the footprint that connected to the embedded SMD pads. The floating SMD pads remained in the footprint and can be routed after the part is placed.

When there are tracks on only one side of the vias in the footprint they are connectable when routing the board.

I don’t know if this is behavior is by design or accident - and it took me a bit to figure because it resembled several other common difficulties that people have reported - and much of the info on the web (as of the current date) relates to former methods (pre-v8) of creating the connectable geometry.

Is it possible that the “track” going down from the via isn’t a real track or a track of the wrong net? As there’s no text in it, it looks like it’s treated as a net-less copper polygon, which KiCad won’t connect to net-having tracks.