Fill zone overlap issue

[kicad_user0]

For some reason my fill zones overlap when filled, even though they are different nets (VCC and GND). Why is this? How can I fix it?

Thanks!

[rocketscream]

You have to set the zone priority level accordingly under the property menu (or press E after clicking on the zone).

[cioma]

Does DRC give an error when two zones with different nets but with the same priority overlap?

[Joan_Sparky]

In past versions I couldn’t create zones like that without having set priority correctly… maybe it changed?

[kicad_user0]

I tried setting different priorities. That fixed it! Thank you everyone! I did have to clear and fill again to see the priorities take effect.

Thanks again!

[dchisholm]

Can you share more details? (I haven’t encountered this situation yet but I see it approaching on the horizon.)

Referring to the image in your original post . . . and extrapolating from previous experience with other EDA tools I’d expect the behavior to be:

1. If the “VCC” zone was filled first I’d expect the “GND” zone to leave the VCC fill intact, flowing around the VCC fill while honoring all the constraints for clearance, minimum line widths, etc. In a logical sense, the zones filled first take precedence over later fill operations.

2. If “GND” was filled first I’d expect the “VCC” zone to fill only the areas (within its defined zone) that hadn’t already been claimed by the GND fill. In many situations (like your example) this will make the actual VCC fill smaller than its zone definition. This seems consistent with the “precedence” concept I mentioned above.

Alternatively, I can imagine the VCC fill acting to “push back” the GND fill as necessary so that VCC can occupy the full extent of its defined zone. This essentially inverts the order-of-precedence I mentioned above but it’s consistent with other human experiences, e.g. the idea that when a government makes a law, it takes precedence over any conflicting portions of earlier laws.

The situation shown in your image - where the VCC copper occupies the same space occupied by GND copper - is simply improper at the most fundamental understanding of clearances, interference, etc.

Like @cioma, I’d like to know how DRC reacts to situations like this. If KiCAD is known to produce the kind of unacceptable behavior shown in your example, I’d at least like to have some confidence that DRC will alert me.

Dale

[cioma]

I can reproduce this issue on r6643. But at least DRC troughs up the following type of errors:
“Copper area inside copper area”
“Copper areas intersect or are too close”

[nicholas]

Can you use this functionality with zones over zones to create voids in GND plane?

But the void will not have a net as it is void.
Maybe covered some where in documentation.

Need to make some voids in a place.

[rocketscream]

Need to make some voids in a place.

Use the route keepout functionality.

[nicholas]

dosent work on planes
at least noit in cairo mode

it just quits the operation silently

[Joan_Sparky]

@nicholas

it just quits the operation silently

Sounds like the behavior when I tried to create a zone overlapping another zone without setting the priority right in BZR60xx… BZR66xx does bring up a warning when I try to do this now and works afterwards normally when I set the priority.
Only thing that helped to get the zone module back working again was to restart pcbnew and try again…

Anyhow, keep out area works in default canvas, no probs:

[nicholas]

can you confirm it not working in cairo ?

if so i submit a bug

just to check its not user error on my part

[Joan_Sparky]

It did fill the zones during creation automatically and had no warning when I didn’t set the prio for the smaller copper zone (left at 0 as the larger one when I made it).
Looked like in the OP, so DRC should catch this… but I don’t use Cairo, so…

[dchisholm]

@nicholas

can you confirm it not working in cairo ?

In a 30-second test, I was able to create a keepout area while using Cairo, though I couldn’t seem to repour the copper (and make the zone obvious) until I switched back to Default.

In my work pattern I regularly switch between Default and OpenGL. I haven’t found any feature or capability that’s unique to Cairo, and it seems to run slower than the others on my machines. Does Cairo offer some advantage I’m not aware of?

Dale

[nicholas]

cant say for sure

the other look horrible but thats just subjective

i will try the other more further on.

[nicholas]

ever tried in the middle of a GND plane ?

[Joan_Sparky]

Drawing either a keep out or another filled zone in the middle of a bigger zone do not cause a ‘silent operation quit’.
It draws the zones (no matter if prio is set correctly or all 0).

For me OpenGL and Cairo look the same.
Need to play a bit more in OpenGL, can’t put my finger on what ‘feel’ it is that Default has that I prefer, as the look of OpenGL is nicer than Default. Only thing I miss there is the color mixing for overlapping features (Red + Green = Yellow) and the grid is a bit to prominent in OpenGL (on darkest grey) vs black background… just dot’s as in Default would be nice.