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.
As a bodge you can also turn on free angle routing in the interactive routing settings and draw the curves yourself.
I tend to draw it crude then redraw over to smooth it out. The auto delete old piece makes it very easy. And makes for much nicer lookign length matching than a random meander when you have the roo .
talking about RF, I have a friend who is a RF Professor and Nerd for many years. He has always been looking desperately for a SW that can handle RF needs. Even professional packages are letting you down when it comes to RF. So, yes, the RF people might embrace KiCad if it gives them some more exotic features. Right now the RF functions look a little bit abandoned…
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).
