At the moment I do not know of a direct way to draw arcs as parts of tracks, but they can be added to tracks by selecting some tracks and then use the Fillet Tracks function from the popup menu under the right mouse button. Arc’s i tracks made this way have completely different properties:
Support for arcs in tracks have been lacking for a long time and there is some support in KiCad-nightly V5.99, but I think you should still consider it experimental. You can drag the radius of a filleted track, but there is no direct way to set the radius to some specified value after it has been created. I have not used this much myself, so I can’t tell more about the details.
Your assumption is correct (Draw Arc on a copper plane). But since it is allowed to do this on a copper plane, I - probably incorrectly - assumed that it would count as a track as well (not only as a graphical construct without electrical properties).
The issue with using filleted tracks though is that I can imagine it is hard to create exact evenly spaced concentric arcs like the following:
Although I must confess that I didn’t even try (the filleted tracks I mean, the above was created using Arcs) -> I just hoped that this would be a supported feature in v6.
Does anyone know how I can actually find out whether this is a feature that is planned for v6 (the nightly of 1 week ago doesn’t support it) and that I should ‘patiently wait :)’ or that I should look for other means?
On a side note, a bit of a shame that I switched from EasyEDA to KiCad since the former doesn’t support hierarchical sheets, which I think I need (and works like a charm in v6!). However, EasyEDA does support arcs as tracks on PCBs…
Arcs as “real” tracks only supported as fillets is very limited indeed, but for KiCad it’s a start I expect improvements over time but it’s going to take a while, and the most logical improvement would be to draw arcs as copper tracks in the same way as arcs are drawn as graphical elements.
There are currently 16 issues open related to arcs on gitlab.
Quite a lot of them have been marked for KiCad V7. At the moment most of the focus of developers is pointed at getting KiCad V6 ready for release, and improving support for arcs is probably not high on the list.
At the moment I see a few workarounds in KiCad, but they are all quite ugly.
You can draw them as graphical arcs as you already did, and then: PCB Editor / Route / Interactive Router Settings with: Mode: Highlight collisions and Options: Allow DRC violations. With these actions you can connect (More accurate: “overlap”) real tracks with graphic elements.
Use the footprint editor. In the footprint editor you can add graphic shapes to pads. This should work, but it needs a lot of fiddling to get it right. In this case I would make a single footprint with 12 arcs and put SMT pads on their ends, because tracks connect to pads in footprints. You also have to put a representation of the thing in your schematic to get it into the netlist, maybe as some sort of connector symbol.
Maybe you can hack into KiCad’s PCB file, and then combine the properties of a graphical arc with a copper track segment. I suspect that KiCad supports arcs in tracks, but there are just no GUI controls made yet to manipulate them.
There are some tweaks we can do for V6 (I’ll look at it tonight)
Note: Fillet Tracks isn’t the only way to create tracks with arcs: you can also do so while routing by switching the corner rounding mode in the context menu (or with default hotkey Ctrl+/)
I don’t know much about that polygon stuff in issue #4809, but I did upvote Seths remark of:
If graphical arcs can be “promoted” to real copper tracks then it would make a lot of designs that need arcs a lot simpler. Here is another project, in which arc segments in tracks are pretty much essential:
There are plenty of ideas for Kicad, but the amount of people who have both the knowledge and drive to work on an Open Source project is limited. And despite that, KiCad is doing great and has made leaps of progress in the last 7 or so years. There are over 1100 open issues on Gitlab, and everyday several get closed, but the total number almost stays the same over time, because new issues are opened just as quick.
And there are are also some hidden functionalities. Recently I did an import from Inkscape for example, and it had Bezier curves in it, and I could manipulate their control points in KiCad to change the shape. There is no GUI button to add such a shape to a PCB however.
Edit: @Russ Below a little example with Bezier curves exported as .DXF from Inkscape.
In KiCad, each Bezier curve section has 4 control points. Start & end points, and “Direction and strength”
Regarding paulvdh’s answer (lacking the people for implementing everything); I understand this. In fact, I can imagine that promoting a “simple geometrical shape” to a track with a net provides a slew of new problems - the first thing that comes to mind is that all DRC checks now need to be applied to an arc as well. Probably not a small thing…
It’s not that I feel “entitled” in any way that this issue needs fixing - in fact, it’s not even an issue as this is apparently a feature that doesn’t exist yet. However, I do entitle myself to gently ‘nag’ about this feature in the small hope that when more people do this, it might move the feature request higher up the list
So, understood… I will look to the other solutions that have been proposed (didn’t do this yet) and hope that the small amount of community nudges will lead to an implementation of this feature in the somewhat foreseeable future
Thanks for all the helpful answers by the way - greatly appreciated (actually somewhat overwhelmed by the amount in such a short time).
Thanks for the list of work arounds. Regarding these:
Understood. Will not be doing this, since I heavily rely on the DRC checks also for correct connections. I know myself -> if I disable this, I WILL make a connection mistake And I’d like to have the via clearance checks as well.
That is an option I did not think of; noice . I think this will be the option to try out for me…
Perhaps I could / perhaps not. But I think I will stick to the supported interface to the program! Not only must I ‘research’ the file format for this, there are more subtle errors that could occur this way: misinterpretation of the PCB file from my side / changing semantics between versions / etc.
IF I go for option 2), I will post the result. Thanks again for the options provided!
At point two, you have a few options.
If you give both pads the same pad number, then KiCad assumes they are the same net.
If you give the pads different pad numbers (for example “1a” and “1b”, then they belong to different nets in KiCad, and the overlapping arc with the 2nd pad probably generates a DRC violation. (I’m mixing up different KiCad versions which behave a bit different here).
There is (another dirty hack) to prevent this. In: Footprint Editor / Edit / Footprint Properties add the words “net tie” in the keyword field:
and it does work, and it also results in a track with a fillet (Which is expected). But just as creating fillets afterwards, it does not create an arc of wich it’s center can be fixed at some location independent of other properties.
That would be nice, I’ve been bumping into forum questions for better support for arcs for several years, and the only workarounds I know are quite ugly.
If you feel intimidated by a few well meant answers to your question, then maybe choosing a little tough user handle would be more approrpriate. or you have to work a bit harder to become what your handle implies.
As of next nightly you’ll be able to create track arcs from graphic arcs using the “Create from Selection” -> “Create Tracks from Selection” context menu option. This should allow you to either draw the arcs or import them as graphics from an external CAD tool, then convert them to tracks that you can assign a net to.
The arcs will be created as tracks on whatever copper layer you have active at the time. The original (graphic) arc will be left alone, but will remain selected so you can hit delete to get rid of it if you don’t need it anymore. The idea here is that you may want to keep the “reference” arc on a graphic layer (like User.Drawings) even after you create tracks from it on a copper layer.
@paulvdh: Well, it very much depends on the specific community I guess; I have had different experiences in other communities that were less helpful. So you can take that as a compliment
I actually paid very little mind when creating my handle, since it has been the same since close to 25 years (ye olde times, when multiplayer Doom was still played with a 0-modem cable): “Kinslayer” - after the main character from a famous fantasy book series. And since KiCad also starts with “Ki”, well… :))
But I guess it makes sense to consider tailoring handles to the actual community it is used in. Oh well, can’t change it now anymore, so I shall have to live with the consequences!
In any case, thanks for all the help - I will be downloading the latest nightly today/tomorrow and try my luck with that!
Thanks a lot for the new nightly! Just to confirm what I found:
I can create tracks from Arcs (arcs being on the user.drawings Layer)
I can create tracks onto F.Cu and B.Cu (did not try other layers)
I can assign nets to these tracks
After assignment, rats nest also takes these tracks into account
I can change the trace width afterwards (of the track itself), without having to change the width of the original Arc - neat.
During manual tracing, DRC checks seem to be applied to these tracks (at least: trace distance, via distance)
I did not try:
Changing Arc parameters of the track after conversion to track - I changed the original Arc on the user.drawings layer and re-converted to a new track
Verifying whether DRC checks work between multiple Arc tracks (I had them spaced out well enough)
What was unexpected:
I read that the copper layer onto which the tracks should be placed should be active. This prevented me from selecting the Arc on the user.drawings layer however. I found out that that was caused by my setting to dim the other layers (in Layer Display Options). After setting this to “normal”, the feature works as advertised!
button
