DRC does not report copper zone fill collision with track

This is kind of just how the DRC works (for now), don't think it would be easy to fix for V5.
"Test zones" step of DRC doesn't actually check for collisions between tracks and zones, only checks for zone-to-zone collisions and that zones get valid netcodes.
So, the only way to get a DRC-passing board is to enable that checkbox to refill zones before running DRC.

@Jon, as I understand the reporter, this option was already enabled.

I have attached a demo board where a track crosses the fill from another net. I would have expected the DRC to complain here when the refill checkbox is not checked.

I am thinking there is a misunderstood here:

Zones are expected to be refilled when running a DRC.

The refill checkbox is only here to avoid modifying a board when running DRC when you know filled zones are OK.

I am myself really not very thrilled by this confusing option (To be honest, I am thinking this option is the bug).

(For me: try to detect a collision between zone and a track has not really a meaning: just refill the zones fixes the issue).

Other EDA tools I known just refill zones after a change, and no not detect a track to zone collision, because this case do not exist (unless bug in refill zo,e algo, but this is an other topic).
However the price to pay is high: calculation time can very annoying when routing a complex board.

@jp, but why does the DRC not detect the short in the board I attached?

DRC does not detect collision between tracks and zones because there is no code for that...

Instead of, DRC expects zones to be *refilled* before running collision detection between tracks and pads.,
Therefore, after refilling, there is no collision and no need to detect them.

I believe the primary issue regarding automatic refill before DRC is whether or not running DRC should modify your board.

(Personally, I think fixing this type of issue is more important than a board-const-DRC. I'm pretty sure Wayne feels the opposite.)

If the DRC won't decect it, wouln't it be better to have the refilling enabled by default?

Like JP says, in many other EDA tools, zone fills are updated in real-time when anything changes that would affect them. So, moving items around, changing the clearance settings, etc.

IMHO, if you do something that invalidates the zone fill, that should invalidate your zone such that the board needs to be flagged as modified anyway. So maybe the actual bug is that re-filling zones should not flag the board as modified. The actual modifications are the things that would cause the re-fill to have a different result: moving items around, changing the zone or clearance settings, etc. Just the act of recalculating the fill doesn't mean the board is modified.

On 3/31/2018 7:51 AM, Jeff Young wrote:
> I believe the primary issue regarding automatic refill before DRC is
> whether or not running DRC should modify your board.

This is an issue in production environments. There needs to be some
indication that the board layout has been changed or is going to be
changed. Boards that have zones that fill quickly, the zone file
progress dialog was not displayed or dismissed so quickly that you could
miss it so there was no indication that your board had been changed by
the DRC.

>
> (Personally, I think fixing this type of issue is more important than a
> board-const-DRC. I'm pretty sure Wayne feels the opposite.)
>

I do and it needs to be obvious that the drc is going to make changes to
your board when it is run. I'm fine with changing the default setting
to refill zone but I'm not fine with silently refilling the board
without the users knowledge. I the check box in the DRC dialog makes it
obvious that the board is going to refilled when the drc is run.

@Jon: I don't know any tool except Mentor that would update zones in the realtime (and still, it works reliably on a relatively simple boards).

@JP: Many tools on the contrary always check for zone-to-track collisions. Refilling the zones is not the way to ensure there are no clearance violations. If the user mistakenly changed something that results in a zone/track/via short circuit, (s)he should be made aware of it. Automatic refill on DRC hides this information from the user, which IMHO is bad. Besides, "Check" means a check, not a modification.

Tom

What about a DRC warning if zones are not refilled after the board is modified? Let's the user know that there _might_ be a problem but doesn't force them to take action if they know it's not an issue.

@Seth, we're tracking the warning idea here: https://bugs.launchpad.net/kicad/+bug/1712579.

We'll have to change the file format for it, though, so that we store timestamps for last-mod and last-fill. So probably not a 5.0 option....

BTW, +1 to Tom's assertion that DRC should check for this regardless of whether we fill / don't fill the zone.

Brexit means Brexit. Err... I mean check means check. :)

Changed importance to High until we figure out what (if anything) we're doing here.

The main problem I see here is that DRC does not report copper zone fill collision with track. Which means that one can pass DRC and have a board which has nets shorted to the zone which are not intended to be. The reason being what JP mentions in #5. It seems dangerous. Hence I think refilling the zone by default is safer for the normal user.

IIRC DRC once upon a time did refill unconditionally before running the check because of this. So I think it would be ok to just make it default refill before the actual DRC. If the user then did uncheck the option to refill in the dialog, and expect the board to be protected from track to zone fill shorts, that would be considered a user error.

I agree. My concern is can this be done reliably without pushing back
the v5 release.

On 4/4/2018 7:26 AM, Jeff Young wrote:
> BTW, +1 to Tom's assertion that DRC should check for this regardless of
> whether we fill / don't fill the zone.
>
> Brexit means Brexit. Err... I mean check means check. :)
>
> ** Changed in: kicad
> Importance: Undecided => High
>

This seems like the best short term solution for v5. We can implement a
full check during v6 development.

On 4/4/2018 8:06 AM, Nick Østergaard wrote:
> The main problem I see here is that DRC does not report copper zone fill
> collision with track. Which means that one can pass DRC and have a board
> which has nets shorted to the zone which are not intended to be. The
> reason being what JP mentions in #5. It seems dangerous. Hence I think
> refilling the zone by default is safer for the normal user.
>
> IIRC DRC once upon a time did refill unconditionally before running the
> check because of this. So I think it would be ok to just make it default
> refill before the actual DRC. If the user then did uncheck the option to
> refill in the dialog, and expect the board to be protected from track to
> zone fill shorts, that would be considered a user error.
>

I just knocked up a version of ZONE_FILLER::Fill() which rebuilds all the poly lists (but doesn't set them into the zones), and then checks their MD5 hashes against the existing MD5 hashes.

We could get rid of the checkbox and call this routine; if the hash-compares fail then we could ask the user if they wanted to re-fill or not.

Worst case it would re-fill every zone twice. So I guess there's also the option of keeping the checkbox and only calling the new routine when it's unchecked.

(Of course the option of deciding this is too risky for 5.0 is also on the table.)

I've now got a slightly more elegant version which fetches the new poly lists, compares them with the old (via their MD5 hashes), asks the user if they're out-of-date, and then continues with the fill or cancels depending on the answer.

So this is my proposed 5.0 solution:

1) Keep the Fill Zones before DRC checkbox.
2) Keep its current default (unchecked).
3) When unchecked, re-calculate zone polygons and compare with existing polygons. If different, ask the user if they want to re-fill.

I've attached a patch which implements this for review.

I'm not intimately familiar with the zone fill code, so I'd appreciate other opinions on the amount of risk this involves.

@Devs, any thoughts on this?

@Jeff, your patch seems like a reasonable short term solution. I do
agree with Tom that the DRC should check zone to trace clearances. I
propose that we use your solution for v5 and implement the DRC checks
during v6 development. Once the new DRC check is stable, we can always
cherry-pick it for a v5 point release. We will have to discuss the v5
point release because as of right now, we don't really have anything in
place to handle point releases.

On 04/06/2018 03:42 PM, Jeff Young wrote:
> @Devs, any thoughts on this?
>

Jeff, I think your idea is reasonable. I have also tested your patch, but I always get the message saying that the zones are not up-to-date. No matter if I had refilled them before the DRC or during the DRC and restarted the test after.

@Orson, there seems to be a multi-stable state with the zone polygons. It does that for some zones and not others. That's why I changed the message to "may", but it's not entirely satisfactory.

Does anyone know why zone fills (or at least the polygon MD5 hashes) aren't always deterministic?

PS: I'm going to go ahead and merge so we can get some more air time on it. We can back it out later if necessary.

I also always get the message saying that the zones are not up-to-date even for only one zone.
(W7 32 bits)

@JP, does your single-zone case have a curved edge (ie: from an intersection with a curved board edge)? If not, could you post it?

This is a very basic zone, using only lines for board outlines.

Thanks, JP. Turns out there's no multi-stable state or indeterminism. I just had my check in the wrong place.

Fixed in revision 05dae9627581777eabe10e0a1a318903cd8a01b5
https://git.launchpad.net/kicad/patch/?id=05dae9627581777eabe10e0a1a318903cd8a01b5