I’m not aware of any devs working on this feature, at least not heard of any recent activity.
Ok. I thought I’d check before talking about my attempt at an implementation of this.
I have a standalone application that reads the coordinates of two lines (two segments, in KiCAD terminology) that form a corner, and then outputs the coordinates of the series of small segments that form a smooth corner (well, I modified the program I had, so that it outputs the complete segment line for the .kicad_pcb).
I still need to manually copy-n-paste into the .kicad_pcb file in a text editor. But the results are reasonable. See screen capture below:
I changed the original corner to the B.Cu layer and made it slightly wider, just to be able to visually check whether it is working.
What I’d like to do next is create a standalone program that works with the .kicad_pcb file, identifies the corners and smooths them. I can see some “obvious” corner cases (no pun intended!) that the program would need to handle; for example, what happens if the rounded corner now collides/overlaps with other traces or footprints? (I have no answer / action-plan for this one — any help?). Another “obvious” corner case is: corners that are very close to something else (e.g., close to a pad from some footprint). For this, I can detect the condition and just leave it without smoothing it; however, it would be great to handle the situation and smooth those corners as well.
Any comments?
Thanks,
Cal-linux
Cal. The biggest corner case your likely to encounter would be a parrellel bus. If so you should keep track of which segments you have smoothed. And if a collision happens with a non smoothed segment. Try that one. And so on until you either intersect a pad at which point the bus is abandoned. Or the first one can be smoothed at which point you can walk back up that tree and smooth them all.
The other one is to allow setting radius and a step walker. E.g. if the larger radius fails. You try the next smallest radii. Until a cutoff where it would not do anything.
And the final would be where you intersect a pads exclusion gap. In such case you can likely pre calculate the best radii that would fit ajacent to that pad. The main issue being 90 degree bends where both segments are within 0.05mm from the pads drc exclusion.
To the op. Try straight line routing mode. Lets you trace out in sudocurves very easily.
That’s because we’re tip-toeing. 
Here were a few pre-requisites: https://lists.launchpad.net/kicad-developers/msg29878.html They should now be included https://git.launchpad.net/kicad/commit/?id=840ad7f68053d000dc6d46661d05d9d4be074704
Next steps involve updating SHAPE_LINE_CHAIN but this will need to wait until after v5.1 as the move to GTK3 needs to take priority.
3 Likes
Is the plan to add the capability of arc traces? What I was referring to was the feature of getting the corners rounded (with an arc, presumably — although with a bunch of tiny segments works reasonably well). Either the rounding happening as we route (depending on a setting), or as an action triggered by the user. Not sure whether there’s interest for this feature. I would find it a nice feature to have — if only for aesthetic, I’d buy it. But for very high frequency boards, people usually go for that feature.
For the time being, I think I will continue to work on my “corner smoother” standalone program. Should I choose a different forum to post if-and-when I make any progress?
Thanks,
Cal-linux
PS: @Seth — are you the same Seth that recently posted the reply to my “grounds” question on electronics.stackexchange?
I would suggest start a different thread, & using the Python inbuilt support, so you can (eg) select a net, or trace-set to ‘arc’ process.
There is also work someone has done on tear-drops (including arc teardrops), which is a somewhat similar problem, and look at WireIT which works well as a Plug-In
I think I’ve seen someone do that for RF striplines.
Addit: I find this work-around, using footprints :
and some more reading…
That rapidly gets complicated, and as mentioned above, needs significant database work.
Easiest is to add short segments, as those do not violate existing DRC/FILL/connectivity etc.
2 Likes
An alternative approach, which side-steps all the work of a patch algorithm, is to use any-angle routing for those rare cases where ARCs make sense - eg here is an example of a ‘user-crafted’ arc :
Eventually, yes. Putting this in KiCad requires getting the pre-requisites right first and making sure that the implementation matches to the larger work plan. Especially with fundamentals like this. With some work it is possible to get this in line for v6. That gets easier with support from our community (wink, wink, nudge, nudge), good bug reports and friendly, engaged users.
This is a good place to post work of this nature. As others have mentioned, implementing in Python as a plug-in will ensure that you have a wider audience for your efforts and more feedback.
Yup. I get around 
1 Like
It could go into the V6 build, but be aware that right now KiCad Master is not allowing new incompatible features as it is targeting a V5.1 that is fully compatible with recent Linux distributions.
and google finds this post, from some time back, which shows ‘demo’ of nice tear-drops and arcs in traces…
Seems all this is possible, just not merged & working properly yet.
Curved teardrops are one of the few things I miss in kicad
As far as i am aware there are multiple implementations that where started but abandoned.
At least one of them got stuck as it was build upon the legacy toolset after it was decided that new features should only be added to the modern one. (It was added to the legacy canvas after the v4 fature freeze. So three years or so ago.)
One i think got stuck because the contributor was not prepared to cooperate with the devs.
Further to the WireIT tool that I mentioned above, this is the code repository
WireIT has Icons, and dialogs, and can seed net names from a selected trace and joins selected pads to named net, or selected trace segment.
You would add a new curved trace icon, and require the user select 2 or more segments (Shift-Clk), or maybe NET.
Then, your splice-in-curve code you show above, goes to work, given some radius property, and maybe a segments or chord count.
This way, that will nicely interact live with Kicad.
I think the more scaleable option is to define some chord-error, which auto-adds more segments on larger radii actions.
It does have to work on the GAL canvas and work with the P&S router
1 Like
Hi @Seth_h
thanks for taking car on this
This would add arc tracks at its best…
Please have also a look at benkempke repo… he has developed also solder mask clearance and via shielding and via stitching tools, very useful for RF too.
BR
Maurice
@Seth_h, your recent proposal for “track refining” made me wonder if it could be applied to corners to make them curved. But here we seem to suppose that a curved track would be another shape.
It’s a bit more of a boat and everyone has an oar. As long as we’re pulling together we get there 
I should emphasize that while we’re getting the pre-requisites in place, we haven’t hashed out the UX steps or feature requirements and neither I nor other devs have taken ownership of that bug. After 5.1, we’ll start having more roadmap conversations.
Ben has interesting work. However, it is all in the legacy canvas so sadly there’s not much that is transferable. Were there specific features in his implementation that you’d like to see in KiCad?
The only non directly transferable code is about the Gui interface to activate a context menu (i.e. round a corner or make a solder mask clearance on track). So it shouldn’t a big deal to port even the Gui part.
I have ported his code to kv6 for my needs and I could send you the diff if you are interested in…
-
Round Corners & Solder Mask Clearance
-
Via Fencing
-
Via Stitching
7 Likes
It’s not as simple as you think. Before we get rounded traces, the data model of PCBnew must support arcs and so the DRC has to take them into account. Also, I consider the track refinement proposal from Seth a must-have before we do teardrops/miters/etc - with no info what generated these features, editing or even removing them would be a nightmare…
Tom
2 Likes
No, I don’t think round track would be simple… I know that the Round tracks in bpkempke repo are implemented as the diff-pairs one… converting arcs to segments… for that reason I said to @Seth_h
(BTW round tracks implemented as segments are fully DRC compliant)
But at the same time the code for Via Fencing, SolderMask Clearance and Via Stitching are full usable without the need to change kicad pcb format.
I havent’ tested these, but this “track refining” idea makes me even more curious now. See https://lists.launchpad.net/kicad-developers/msg37209.html.
How does this existing code handle the situation when the vias need to be deleted? How about handling them on-the-fly when tracks are pushed?
I believe that the “refining” idea where there are generating and generated items could be applied to zones and stiching, too. Zones with the same net on several layers could generate and delete vias automatically when zones are edited or items moved. To enable as easy board editing as possible the generated vias should be invisible to editing process, they shouldn’t be left there or moved but deleted when e.g. a track is pushed or a footprint moved over them.
I don’t think this would be possible with a simple non-file-format-changing solution. Same thing for fencing, the vias should be deleted/moved/generated on the fly when the track is changed. (In an ideal situation, of course - it’s great that less than ideal solutions are proposed and implemented, don’t get me wrong.)