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.
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.
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.
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.
@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…
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…
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.
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.)
Huh… I have to confess that Cal-linux and Python don’t get along (at all!) I’m more of a C++ fan (though I haven’t gotten into the newer, C++11 and later, features). I was into wxWidgets for a while (back when it was called wxWindows).
Is there any chance that I might get away with being able to contribute and not having to write a single line of Python?
Oh, man!! Those are neat! (I don’t think I have right now any need for via fencing or via stitching, but those are certainly important features to have to attract the RF community. I hope some of that work can be reused, despite the incompatibility with the old canvas (as I understood from Seth’s comment).
Although I have to say — I would rather see the feature implemented as a “routing mode” (a flag in the settings for the router), where you check a box “Round corners” (and supply any related parameters) and then the corners are rounded as you create the traces.
It’s the other way round, they were witten for the legacy canvas only. KiCad is creeping towards deprecating the old canvas, so all new features must run on GAL/Cairo
I can also see that true arcs in the database is quite complex to add, with many ripple effects. ie it will be a long time coming.
Perhaps the menu item of Add-curve can be added, pretty much as coded now, which splices in N segments, with an option for that to be Segments or Arc for future KiCad releases.
Yes, those are not easy to edit / move, but significant edits would re-draw the trace, and re-apply the curves last.
The examples show these as a niche feature, applied to just some traces in a design, so that level of user interaction is tolerable.
Similar with TearDrops. - those can be batch-added, and perhaps some fractional width can be used to tag the teardrop as ‘auto-generated’, allowing a re-generate to easily remove the old ones.
These would be a post-route, pre-pour apply step.
For easier manual editing, perhaps select could expand, to allow (eg) ‘trivial connection of same width’, which would pick all of an auto-generated teardrop, for manual delete.
I’ve found curved teardrops are best, to avoid clearance effects as they pack better.
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.
I’m more of a C++ fan (though I haven’t gotten into the newer, C++11 and later, features). I was into wxWidgets for a while (back when it was called wxWindows).