DRC violations after applying "melting"

[daf0x]

Hi, thanks for making this cool plugin!

I tried it out on a small board I'm working on, and I noticed that in my case in quite a few places it caused DRC violations that were not there to begin. In my case because it was a small board it's not too much work to manually fix the violations, but on a larger board it may be prohibitive. Especially given the suggested workflow where the "melting" is applied as a "post-processing step", I feel is that re-routing the traces should not result in new DRC violations.

Here is an example from my board: Before:

After:

Ps. For some reason the arrows pointing to the violations appear to get confused, the arrow in the top-right of the fill plane is actually pointing to the arc where the other two arrows are close together.

[mitxela]

Hi. Yes, unfortunately the DRC system is completely inaccessible from Python so there isn't an easy fix for this.

You can fix the DRC errors by altering the original board, the simplest way is to break tracks near the problem so that a smaller radius is formed. Or, reduce the radius parameter when you run the script. You can run the plugin on the selection only, then undo, alter it, run it again, etc.

Until the python interface gets access to the DRC system (which might be never) there isn't much I can do on this.

[daf0x]

You can fix the DRC errors by altering the original board, the simplest way is to break tracks near the problem so that a smaller radius is formed. Or, reduce the radius parameter when you run the script. You can run the plugin on the selection only, then undo, alter it, run it again, etc.

That's what I've been doing, it's a decent work-a-round, but it would of course be even better if things Just Worked TM :)

Hi. Yes, unfortunately the DRC system is completely inaccessible from Python so there isn't an easy fix for this.

I don't know anything about KiCad code, but I wonder if DRC system is really what you need? With the DRC you could check "after the fact" if there were any violations right? But shouldn't the plug-in avoid creating violations in the first place?

For example, while fixing the "source" layout I ran across this: Before:

After:

It looks to me like this is an instance of the same problem, only much more dramatic. Here the two tracks have started to overlap, which can never be correct. The source of the problem appears to be that the inner track has a small corner piece (45 deg), which constrains the 'melt' to make a very small radius at that point. The outer track is just two straight line segments, which appears to give the plug-in more "room" to create a nice big swooping curve.

The plug-in should take the track width and clearance into account, and not allow tracks to get closer to each other than the track width + clearance allows for. Is the track clearance not available on the PCB_TRACK class as GetLocalClearance(), or maybe as GetClearance() on the track's connected net? (again, total n00b here, I just spent 5 minutes on google).

[mitxela]

Yes, that's the expected behaviour, a small 45 degree bend is a way to reduce the radius for a corner.

I talked a bit about this problem at the end of the first melting kicad article I wrote (in the conclusion).

Sure, you could technically re-create the whole of the DRC in python, but there's more to it than you're assuming. The clearance is just a number, but knowing whether the tracks collide is a complex problem. Even if you forget all the other DRC violations possible, like colliding with footprints the board edge and everything, and just focus on track-to-track clearance, even then, figuring out if two arcs are too close together is tricky. I think internally KiCad simulates the arcs with straight segments for the sake of DRC.

But even if you know there's a DRC violation, the problem is still complex. Consider the following situation: When the plugin runs, it has to process each track sequentially. So the first track will do this, an obvious clearance violation: But when the second track gets processed, the problem goes away: This would still happen even if you processed them in the other order. You'd need to process each corner in an exact order, all the "inside" corners first, to be able to tell the difference between genuine clearance violations and this effect.

And of course, if there was e.g. a component on the inside of one of those corners, then the rounding would need to be reduced there, and so the outer track would then need to back off, and if there were more tracks it could potentially cascade.

So yes, I'm aware of the problem, and it's not like I haven't thought about it, but it's a huge task. If anyone wants to help out with it, that would be awesome.

[PerennialNovice]

Hi and thanks for this wonderful plugin :),

I also observe some DRC violations after melting a ready-routed board. Unfortunately I have no solution so far but would like to help because I really like the looks of the melted tracks :) I am far from an experienced coder, know almost nothing about python and my timetable is well filled, but if you have some other tasks to share, feel free to contact me - we'll see what I can do...

What I also observed, is that there are quite some warnings about unconnected ends.

And, a purely visual think, changing direction on a via does not seem to trigger melting:

(the somewhat wrong-looking arcs on the bottom right is a display issue, when zooming further in all looks well)

[mitxela]

Hi. It might help to remember that the melted tracks will always pass through (at least) the midpoint of the original track. So, if you want finer control of the shape, just break the track into several sections, maybe even hand-draw it in free angle mode a bit, and then the melting will follow it.

Vias are considered fixed points, so they will never get moved. I think it would be too confusing if the plugin tried to shuffle them around.

Unconnected ends - these warnings started appearing when I ported it to 6, I need to investigate, it might just be a simple rounding error somewhere.

Now for the main task, I was mostly thinking about it back when it was all subdivisions, but with native arcs the task would be easier. One way of doing it would be to first run the plugin with a very tiny radius, then make a routine that embiggens the radius of an arc until it hits something. Then, we run the embiggening routine on every arc repeatedly until none can get any bigger. It would take a very long time to run, but should hopefully give a perfect result. Optimization could come later.

So the first thing that needs doing is making a routine to detect "does making this arc bigger collide with anything?" Note that in KiCad 6.0.4, even if you are routing in highlight-collisions mode, making an arc bigger does not highlight the collisions in green (though it does trigger the clearance violation when you run the DRC).