Yup, that’s what would be needed for this functionality. It is not currently existing but probably possible
Thanks for the clarification @Seth_h.
However with such an option at hand there is still one detail needed for a working implementation of skip vias:
Zones on in-between layers must also respect the “Start and end only” setting, even if on the same net.
Otherwise zones would just try to merge in as they currently do, and the result would be no different from what we have today
Suddenly I begin wondering if Custom Rules can be used for a workaround at least.
For custom rules, it may work to use rule area’s and don’t connect to zones inside those rule area’s. But it’s a guess.
But adding those rule area’s maybe it’s just as easy (difficult) to keep out zones in those area’s (without custom rules) but then you’d have to lock the via’s in place too.
Another workaround is to use net ties, to break the net into sections. When KiCad thinks it’s a different net, it won’t connect the via’s to the zone.
I’m obviously missing something here . . . .
Isn’t Start and End and connecting layers the same, assuming it is not meant to connect any other layers ?
Is that the difference here, the OP wants to connect to start and end only regardless of connections to other layers ?
You could also add a little keepout circle on the In1 layer to prevent the fill connecting to the via on that layer. A bit fiddly, but OK once in place. I have done this when I didn’t want a pin to connect directly to power fill.
If you have a large area of many pins, paulvdh’s idea of a net tie and a separate GND-like net for the In2 fill is probably the “right” way here, with the benefit also that it’s quite clear documentation that there’s an area of special GND that needs to go somewhere else before connecting to the main GND at a defined location.
However, there’s a bit of a tricky moment there because you need a net-tie to get from your GND-like net to real GND, which you presumably would want to basically be a single via that connects to both nets (or an array of such vias). And such a single-point net-tie isn’t yet supported (see end of First-class star net-ties (#2265) · Issues · KiCad / KiCad Source Code / kicad · GitLab)
And even if you use a normal ‘bar-shaped’ net tie, the usual net ties have a polygon in the middle to connect the two pads, and the footprint editor does not (yet) support assigning a defined internal layer to polygons, so it’s tricky to make a tie on In2 in any case.
What you can do is a polygon on the In2 layer on GND_1, and use that to forcibly connect to the skip via bottoms. Then tie that back to GND with normal vias.
This will cause DRC errors where the GND vias hit the GND_1 polygon. But you can exclude those DRC errors, either manually or with something like this:
(rule "Allow GND tie"
(constraint clearance (min -1mm))
(condition "A.NetName == '/GND_1' && B.NetName == 'GND'")
)
The net tie in the schematic then gets marked “not on board” to avoid a schematic parity error.
The “risky” bit here is that it won’t tell you if your GND_1 polygon becomes isolated from the GND net vias.
What you’re missing is the GND fill will automatically create a connection that OP doesn’t want.
2 Likes
The suggestion of manually adding circles means an additional task to remember for every single blind via being placed. One might easily miss one of those and then never realize until it’s too late. Therefore not really an option from my point of view.
Adding net ties to every single decoupling capacitor and what else needing a Gnd, would probably work in some cases, but it would also clutter the schematic in a way that would be quite undesirable in my case.
In my opinion this is purely a layout problem and as such I would be extremely hesitant to let it influence the schematics in any way.
I would however be very happy if the desired effect could be obtained globally for all blind vias through the use of Custom Rules alone, but I just can’t wrap my head around how to attack such a task.
It seems the feature request has made it to the codebase. Thanks Seth.
Looking forward to trying it.
2 Likes
Now that is some fantastic response time!
Thanks for pointing out the functionality gap and thanks Seth for making it possible. This is why KiCad is so awesome, impossible to imagine this playing out this way with Altium etc.
4 Likes