I have a four-layer layout, built with KiCAD v5 (the original 5.0 release) — the layers stack is:
Top copper (components and signals)
Ground plane
Vcc plane
Bottom copper (signals)
I have many filled-zones on the top copper layer — some ground zones to connect the “power VDD” decoupling capacitors, and zones to provide extra-thick connections from the IC’s output pins to the output terminals (these are signals carrying 5A to 10A).
The layout passes DRC with “zero errors, zero warnings” (only the “Refill all zones before DRC” and the “Check courtyard missing in footprints” boxes are checked)
Now, I want a copper pour connected to GND on the top layer — my idea is: add a zone for GND net, with Default pad connection set to None, a 0.5mm clearance, and then edit some of the vias or pins connected to GND and set them to override the “Pad connection” (e.g., set it to Solid) to make a connection to the zone and thus make it fill.
Well, it does not seem to work: the zone just fills on top of all the other zones. Now the DRC of course flags 50+ errors (Copper zone within copper zone).
The priority of the just-created zone was 0; if I increase that priority to a value above any other priorities in the other zones, then the other zones do not fill, and I get a bunch of ratsnest lines showing missing connections.
In case it matters — the filled zone I’m creating is a square, essentially the same as the board’s edges.
Is this a sign of something wrong with the layout? Or is this “normal”/“expected” behaviour? (I would be greatly surprised if that was the case)
I guess I could carefully draw the copper pour in selected areas; and for that matter, I’m sure I can live without the copper pour — still, I’m puzzled and curious (and would prefer to have the copper pour connected to GND)
Have you reversed this? I.E. keeping the new pour at priority 0 and all your other ones at priorities above 0? I’m not sure if this would help, but it might be something to try.
*sigh* … Seems like when my brain labels something as “I don’t like it”, then it refuses to store that in long-term memory…
It would seem like what I’m trying to do is simply not possible in the general case — from one of my own previous posts (More trouble (pcbnew bug?) with filled zones), looks like:
The zone will connect to all traces connected to the GND net (there are of course plenty of them — every GND pin of every IC connects to a pad of a decoupling capacitor and then from there to a via to the ground plane)
I think just now I’m fully understanding PCB_Wiz’s comment at the end of that post: “Zones check traces/vias/pads, but not intersects with other zones, as that is very calculation intensive”.
Regarding the second point above: if I’m (now) getting this right, and two zones that intersect will unconditionally connect to each other, I have to say that I’m profoundly appalled. I’m not sure whether the part “as that is very calculation intensive” is PCB_Wiz’s own conjecture or whether it is something generally accepted and supported by KiCAD developers — IMHO, there is no excuse to have such a misfeature because “it is too calculation intensive”, especially when it is not [calculation intensive]. Zones are simple polygons, so checking for overlap is most definitely doable: Check whether segments from the boundaries intersect (O(N1·N2) where N1 and N2 are the number of segments in the zone’s outline); triangulate the zones’ polygons and check each vertex of one zone for inclusion in one of the triangles of the other zone (again O(N1·N2)), and I guess checking for “edge cases”; a segment touching a vertex but nothing else — in any case, it would be a matter of checking every vertex and every edge of Z1 against every vertex and every edge of Z2 and vice-versa… Am I getting this wrong?
Hi. Dev here. This is not the case with v5. Overlapping zones with different nets will generate errors when running a DRC check. The exact error is “Copper area inside copper area”
That said, I just had a look at your previous post and it looks like you are not referring to DRC checks but rather you want the zone to fill based on it touching another zone. This also should work. If it doesn’t, can you post or send me your project files so that we can make sure this feature works correctly for you.
Well, ok, yeah, for sure the DRC does check for that (I did noticed this detail, and mentioned it in my initial post). But the thing is: why do overlapping zones lead to an error? Why do the zones connect to begin with? They’re zones of different nets, they both have a specified clearance, why would they connect to each other? (PCB_Wiz’s comment seems to explain this, in that during normal operation zones do not seem to check against other zones).
If the answer to “why would they connect to each other?” is “because the definition/specification of filled zones establishes that they should connect to each other”, then, well… let’s say that to avoid having nightmares tonight I’m going to go ahead and assume that that’s not the case
This is a valid concern. Specifying the priority is the best way to avoid this. Leaving them connected flags the error in DRC that you did not specify which zone has priority. But perhaps there are other,better ways of accomplishing the same thing. We’ll discuss over at the bug tracker.
If they have different priorities then they work as you expect
A bit more detail: If two zones overlap, kicad can not know where do draw the line between them. So it needs additional information. In this case it is the priority level. The zone with the higher priority will define the resulting border between the zones.
I was going to say “no they don’t, I already tried” — then I read the rest of your message (and Seth’s, and fred4u and SembazuruCDE messages — man, it would seem like when my brain refuses to listen, it really does not listen!!! )
Though that part works (I just tried), what I’m trying to do is still problematic — the newly-created zone will still connect to GND traces (which I do not want), and to other smaller GND zones, which I also do not want — I want to connect this new zone to GND at exactly (and only) one point, to reduce the opportunities for ground loops.
Notice also: the zone will also connect to GND vias, and there’s nothing that I can do about those, since I cannot set the via to override the Connection to pads and assign it to None, since I need that via to connect to the ground plane (unless I can control this setting for each layer separately? In gEDA pcb, I can do that — the thermal relieves in that software are controlled by the via/pin, and not by the zone; and it works at each layer independently of the other layers).
I would posit that the reasonable action by the software should be to not create the zone, with an error message indicating that the zones overlap and that the user must specify different priorities to resolve the conflict. The other option I see, which is not filling the newly-created zone, might just add to the ambiguity and the user’s frustration given the many reasons (some of them legitimate, some of them not-so-much) why a zone will not fill.
May I suggest a “new feature” to address one of the issues related to this:
It would be a nice thing if the priority could take negative values. Or in any case, if the default priority value was somewhere inside / half-way the range of valid values. One problem with the suggested solution is the following: I need the new zone to have a priority that is lower than the priority of each of the existing zones. But most (in all likelihood, all) zones that are already there have priority 0, since that is the default value. So now I have to go one by one through each of the zones and change their priority (and there is no tool in the software to “enumerate” the existing zones — I have to visually catch them and not miss any).
It would be neat if I now could go a create the new zone with priority -1
Hahahaha — nice indeed!! I like this idea (then again, some of you may remember how much I loved the idea of the net ties in the context of having split ground planes — followed by a bit of a disappointment when discovering that the SMT net tie can only be placed on the top or bottom layer, and not in any of the inner layers such as the ground plane … still, a neat idea, I thought)
I think this would be more complicated to implement, no? (however, I think it is a good idea to have a mechanism to enumerate / go through all of the existing zones)
[[ EDIT: another alternative may be to just have a, say, menu item under “Zones” that just shifts all zones’ priorities by 1 ]]
How does this work? Did you mean that you will bring it up to the other developers and it will be a developers-only discussion? If the general public / users can participate, I’d like to know how does it work.
Yes and no. Both are changes that would need to wait until v6 to be evaluated.
This is a mildly important aside for users: There is no such thing as an easy new feature. Changing how the layer priorities are represented changes many internals and requires many (many!) hours of testing before it is a viable option. And that is only if we don’t run into unanticipated problems.
The new dialog would also require a fair bit of work to ensure not only that it functions correctly but also that it works in a way that users find approachable.
Register with launchpad and give them an e-mail address to send you updates. Then go to the bugs you are interested in and look on the right-hand side where it says “Subscribe to this bug”. Choose that option and then any responses, discussion and/or changes will show up in your inbox.
User opinions are welcomed and even more useful is testing nightly builds with potential fixes/changes.
I was originally reluctant to (more like, determined not to) register with launchpad … But on second or third thought, I figure: what the hell, why not!
)