Possible to force unconnected copper fill to save on etching chemicals?


#21

You mean a “remove isolated copper” tickbox ?
Yes, other PCB cad pgms have such settings, and it can be useful.


#22

Interesting, below is a V5 test, of a ‘no net’ drawn outside everything.

GND is highlighted here, so the two fills show clearly.
Anywhere that is not GND reached, becomes ‘no Net’ filled. All looks fine.

Same priority 0 as gnd, in this test case, however that does spawn DRC errors.

If I change either priority then the higher one wins, and the other one vanishes.
It seems hidden in that both priority 0, is a “keep isolated copper” switch.

It is just the DRC error that makes any issue with both Pri=0, and it’s not clear why they need that message at all. The fill has not created colliding copper, and the NamedNet seems to have a natural inbuilt priority over ‘no Net’, in that ‘no net’ only fills what is ‘left over’. Seems a sensible order rule.

That natural priority, that looks to be already in there, could give a quite useful “keep isolated copper” control by area, if they just remove the strange DRC message. (eg maybe allow ‘no net’ with same priority level, to do this else fill ? )
NestedFillTest_V5


#23

I tried this and now understand what you mean. The GND zone has higher priority even in those areas where it’s not filled. The lower priority zone doesn’t fill that area because the area belongs to the GND zone. It’s just left empty if it’s not connected to other parts of the GND net.


#24

Ugly, very ugly, workaround: add a one pad SMD footprint to each isolated area, set the pad zone connection to solid and the net of the pad GND. Ignore those DRC errors which warn about these.


#25

Yup, and in my test above, (v5) if they both have pri0 they do correctly fill, with ‘no net’ filling second, but that construct then spawns the DRC errors.

Looks like some fixes are needed.

To me, V5 is fine, provided they remove that error message for ‘no net’ of equal priority, as it seems to work just fine. (ie they have already used the ‘no name’ to give a ‘-0.5 priority’ :wink: )


#26

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.)


#27

Sounds like net-tie is a very focused use, that can easily be managed, as the natural zone fill is to include clearance.


#28

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

#29

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…


#30

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.


#31

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:


#32

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.


#33

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


#34

I guess that depends on what one expects :slight_smile: Do you mean as opposed to what we reported here?


#35

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.


#36

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?


#37

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:

image

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 :slight_smile:


#38

That test board has GNDS, no particular importance. The no net flood is the lowest priority.


#39

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 :blush:

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.


#40

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 :wink: