The following is just a an example
In this case, doing a push and shove routing cause the magenta track to come in contact with Edge.Cuts, but I often have cases where dragging a via is re-routed across the cut too.
Note: previous to drag, the track was well on the right side of the cut, on the left there’s never enough space, since it’s too close to left border of the board.
Didn’t I define well the cut zone, or is it a bug? DRC doesn’t show it as a problem as well, so unless I spot it myself it would pass unnoticed (until manufacturing).
1 Like
It has always worked this way for me as well. You can file a bug report, but the shove router (and walk around) have always routed with respect to copper features, not EdgeCuts for me. Maybe pose it as a wishlist item?
Mmh… maybe I’ll file it as a flaw, though it’s not just related to router: as said, if I draw a track crossing some hole, the DRC says it’s all Ok.
I’m also a bit surprised: there’s no control to be too close to cuts/margins either? Maybe I didn’t set it properly…? 
1 Like
Hm, that screenshot. It looks as if the track didn’t go over the centerline of that outline.
I encountered before that the outline definition does behave odd in regards to filled zones, where as the thickness of the line influenced the setback value of the zone - it was always the edge of the line (and thus it’s thickness) that counted into that and unfortunately got declared a feature instead of a bug by the lead dev(s).
You got the opposite problem as the autorouter/shove function seems to not go over the centerline, but has no setback value apparently.
It’s hard to say in this case if it’s a wishlist item; there is clearly something wrong. For a workaround we can paint in KeepOut zones, but that’s extremely inconvenient. However, in the specific case presented here I would be inclined to place a drill hole rather than a circular cutout. Unfortunately at the moment there is no simple fix since we do not have a 2D geometry kernel with the necessary features.
1 Like
@LouC… now that @cbernardo mentions it, drill holes up to 6 mm are more accurate than circular cutouts (hole done by drilling, not by milling). They can deviate in diameter as much as 1 mm by my own experience.
2 Likes
Well for the circular hole I can add a drill hole, but it’s not the only opening I need, see this one, which is more like a buttonhole
The yellow trace was happily on the right side of it, but as I dragged slightly the via pointed by the arrow it was immediately re-routed over the cut. This PCB passes DRC check as “everything’s fine!”, but hey, I wouldn’t be that optimistic 
As a side, I’m an embedded developer, I know how hard and complex can be the solution to what appears “so clear” at first sight 
Just trying to see if is there any workaround, or if I’m wrong with anything, before filing a bug.
For the moment you’ll have to draw a keepout zone around the cutout, then duplicate that zone on all other layers. If glyphs on the edge.cut layer could be treated as tracks that might work; however I don’t think the DRC has a collision check for arcs … and we’re back to needing a geometry kernel with more features.
2 Likes
that would work for me if I could draw on those layers in the footprint.
I think the router and DRC should respect edges.
It does in V5 20 characters
I still work with V4.0.7 (and Linux)
One of the boards I designed has an L shape and the Push & Shove happily routes tracks through thin air outside the board.!
The screenshot below is the result of moving a single trace, and 2 other traces are routed off the board.
Necessary clarification to avoid confusion: V5 has not yet been released. It is very close but a few things still need to be done. (Mainly documentation and a few critical bugs need fixing as well.)