No way that can just be removed. If you have to zones with different nets they could be accidentally connected with a no-net zone. (Net tie footprints are used to do that on purpose.)
Sounds like net-tie is a very focused use, that can easily be managed, as the natural zone fill is to include clearance.
Ah, ok. Yeah, setting same prio actually works so the no net fill ups vacant space so I could probably use that in my use case now. As others noted.
However, it only seems to work because of special handling of the no net zone or just because it’s not connected anyways… When I tried using VCC and GND overlapping with the same prio I got no control which had prio.
Are you able to post your project for anyone to look at or is it NDA?
I can do that, but it seems to me that we’re all on the same page now. I just missed the part where it needed to be same prio first. And then tried GND and a connected net (VCC) with same prio which also turned a bit messy. In my case VCC filled up areas that was previously covered by GND which I didn’t want.
So if I understand now:
- Trying a lower prio zone to fill up vacant space of a higher prio doesn’t work.
- Trying two connected zones like GND and VCC with same prio leaves it to KiCad to figure out which one would be filling where they could possibly both fill.
- Trying a same prio no net-zone to fill up vacant space DOES work but gives DRC’s
Maybe this detail was obvious for everyone else but wasn’t to me so I’ll just add it: With a same-prio no-net zone, it’s actually filling up everything so fills overlapping with GND as can be seen if moving it:
I guess that’s the reason for the DRC violations…
To be clear, it’s not only no-net zone which behaves like this. All nets which have the same priority are filled so that the fills overlap.
Oh yeah, that’s definitely a no-go. Adding planes for VCC and GND with same prio would have shorted GND and VCC for me:
Well spotted, yes
The DRC violation are not quite correct, as it still spits those even if there is no real copper overlaid.
You can remove the DRC errors, but that needs different pri levels, and then that dictates the higher Fill is kept manually clear of the lower fill, if you want that to proceed.
What you do get with ‘no net’ is the remove unconnected switch is flipped, so I think the best fix here is to add user access to that decision boolean, that clearly exists inside the sw.
ie allow users the choice of remove unconnected areas.
In some CAD packages, they have a Area value for this too, so tiny copper areas can be removed, and larger ones kept.
Seems like adding “Keep Unconnected” tick option is what is required here, which is a new feature.
I see you can get some coarse control on smallest kept areas, by setting the Fill min Width larger, but that has the caveat the thermal spoke is not smaller than min width ie is best used for None option on thermals.
1 Like
Testing a recent Windows Nightly
Application: kicad
Version: (6.0.0-rc1-dev-1481-g5e705347b), release build
no net set at 0, a GND island at “1”, works exactly as epected
I guess that depends on what one expects 
Do you mean as opposed to what we reported here?
That the ground island (GNDS) is complete and follows its zone outline and that the remaining board in my no net zone is flooded with unconnected copper, minimising etching.
No DRC errors.
1 Like
Ah, ok! Now I see. You have a higher prio on the no net fill. Yeah, that doesn’t work for me. If the no net zone overlaps the GND one and has higher prio it would override and disconnect.
Compare
Only GND fill:
Overlapping no net with higher prio:
In your example, if you would have removed this trace:
I don’t think you would have gotten a connection here since the no-net fill is of higher prio than the GND one. But if you remove the no-net fill, the ground one would have connected them.
Of course, if you route everything with tracks and not lean on the fills to make connections, these tracks would still be there even if you have a no-net fill around it, but then you kindof loose the point of the ground fill altogether?
Ok, I see you have both GND and GNDS. But if you do an island of GND where I pointed with prio 0, does this make a connection if you remove the track I pointed at?
This one is interesting though:
Is this not an explicit track from GNDS? It’s right on the border of the no-net zone, right?
I just get more and more confused
That test board has GNDS, no particular importance. The no net flood is the lowest priority.
Sorry, reread again. I for some reason thought you meant higher prio on the no-net. Okey, lower prio on the no-net. Of course! Sorry about my massive amount of confusion in this thread 
Yeah, it just doesn’t solve my problem. What I want is a GND plane filling up the entire board, both to save on manual routing but also to save on etching. KiCad automatically removes disconnected islands of that plane. Adding a lower prio plane to cover that up is a no-op.
The only reason that the ground pour won’t fill is because there is no way of making it contiguous. The fill has got to connect with GND (or whatever net you chose) somewhere in the board. There is simply no way of connecting to it in the area that is unfilled on your board. The 'no net’s will fill up the remainder because it’s connected to well … nothing! If you can get a link to your chosen net inside the unfilled area it would fill with the GND pour.
Yes, it might be better to ensure that you have a contiguous GND pour e.g.for RF concerns but that has to be a design intent and there has to be a way that the pour can be connected. If you have filled the zone with a no-net fill, you can then via stitch the unconnected isolated copper to a different layer. There would have to be a certain amount of individual selection and interaction to do this.
Filling overlapping pours with different nets is never going to be a good plan - it is clearly a problem but one that is picked up by DRC.
The original issue was to reduce the area etched - the no net on the same priority seems to achieve this.
Looking at your original board - try moving the triple connector that is bottom right up or to the lefta shade. I bet the area to the right of the board will then fill. Filling the rest of the board is left as an exercise 
2 Likes
This is good, practical strategy. You may also try to make the minimum width of the zone smaller (as small as the normal track width) if it’s not small enough already. In your original picture there seems to be good possibility to fill maybe 3/4 or more of the empty space in the green layer if you just move some tracks and vias without rerouting, provided that you get one connection behind a connector footprint as John suggested.
This is an example where fragment inside the GNDS zone are not filled with GNDS as there is no available connection, but then are not flooded with no net either. Arrows point to what I think is an error
I wish I could but these are panel mounted WH148 pots, holes already written, not in stone, but well in plastic, PETG to be specific
Like this, but I’m not going the no-plan whatsoever wiring approach again:
I’m doing the pots pcb mounted this time and just wiring to jacks which will be alot easier
I might get away with extending the board downwards a tiny but though… I should have 3.5mm according to this which should leave me with one more mm almost:
You may also try to make the minimum width of the zone smaller (as small as the normal track width) if it’s not small enough already.
Yeah, for these to be hand-made boards I try to keep margins high not to bridge anything
Anyways, thanks all for all good suggestions! For my current use case I’m all good, I’ll manage and I’ve learnt a lot. And thanks @davidsrsb for the report, I’ll follow progress there!
1 Like
The bug has been marked “wishlist”
Personally, I disagree as my opinion is that the fill algorithm, which is already a special case, should all empty islands regardless of other zones it overlaps. Anyway this might have to be a V6 thing as it would affect Gerber output in existing V5 projects.
It would help if those commenting in this thread click “This bug affects you”
edit Seth has committed a patch https://github.com/KiCad/kicad-source-mirror/commit/6b75f589e94315f7c0ee0c11906ef5f4004ade23
This should be in tomorrows Nightly
1 Like