Oh, and because I don’t like to do things manually that can be done automatically and because PCBNew provides a scripting hook, I created a script that will automatically place my components in the ring pattern you see in the above picture.
After getting over the hump of figuring out how to get scripts to work in PCBNew and the class structure, it wasn’t that hard. It is not, however, a script that’s ready for prime time - just something I threw together using manual, not form-based, edits to change parameters.
Still, hugely rewarding, fun and a big time saver for this project and other ring-shaped projects.
The one thing that makes these circular boards less space efficient that they could be is the reliance of KiCAD on polygonal copper fills. I’ve minimized it as much as possible in the above design (I think) but there are still areas of the copper fill shape that forced the ring to be larger than it should have needed to be based on my edge cuts (which allow circles).
Why doesn’t KiCAD allow you to use perfect circles for copper fill areas and is there anything better than changing from 16 to 32 segments for copper fill circle boundaries?
I did put up a script on github that created copper fill zones with as many segments as you like… would need tweaking and runs outside of kicad (manual kicad_pcb file editing) but would do what you wanted.
Also there was someone 1 week ago I think that needed a method to get LEDs into a circle… he solved it with the inbuilt array function…
I’m not sure if I provided a link to the simple code I wrote to place the modules around a circle…
I have not re-visited the code since the last time I used it - you know how it goes, out of sight, out of mind but it works pretty well at the moment and is an upgrade from the previous version which used a hard-coded array list in which I set the positions and orientation from an Excel spreadsheet.
An SMD pad is the only thing that would give you a circular copper fill. The reason KiCad doesn’t do a circular fill is that the fill regions are defined by a polygon. I would prefer to use a “closed loop” to describe the region and that loop can be any number of shaped segments joined end-to-end; a circle would be a case of a single segment defining a closed loop. The next best thing it to at least model the region like DXF’s “PolyLine” which is essentially a loop consisting of arcs and line segments; in that case a circle can be modeled with two arcs. Unfortunately it’s a pretty big task to make those modifications and to ensure that the Gerbers come out right.
On that subject… I don’t know if it would solve anything - approximation by straight segments is pretty good - but I would propose an adaptive method.
One can define number of segments per 360deg at the moment… choices are 16 and 32.
For small radii this is sufficient, but for large radii the segments become visible and in the case of large circular outlines the difference between the arcs for the outline and the finite segments for the zone edge becomes pretty obvious.
Is there a cheap and fast way to define a max length for segments and the algorithm then just adds more to a large radius approximation while it is creating the zone outline? So instead of the one-and-all solution 16/32 that is used everywhere it would increase the segment count for larger radii when segment lengths go over a certain threshold (until they are under the threshold again)?
I can help myself by creating me a zone outline via script that uses a higher number of segments for the loop, so I can deal with it, no problem - just thought I share the idea in case it’s a low hanging fruit: No arcs etc. needed, no risk for gerber creation, ‘just’ modify the segment creation algorithm to adjust the 16/32 setting on the fly to whatever is needed to stay with the segment length under a (user settable?) threshold.
In part the problem is due to various poor assumptions and dubious sharing of code. No one would ever want more than 32 segments to describe a circle, would they? A better test in most cases is to impose a maximum deviation from the arc/circle, and there are a few calculations like that in various places in the code. The actual requirements for different uses of similar code can vary quite a bit. For example, modeling a 5cm diameter circular board using 32 straight segments is definitely not acceptable; however for 3D visual modeling it’s probably fine in many situations unless you have features near the board edge.
I’m sure we can fix a lot of these issues by changing the various bits of code which do these calculations so that it’s all done consistently and in such a way that some code such as the 3D visualization which can quite happily trade off precision can easily override parameters. Unfortunately there are quite a few places in code which would require some change, but if anyone has the time it can certainly be done without too great a hassle.
I’m trying to have circular boards+mouse bites+internal cuts without having the 3D viewer complaining about non-contiguous polygons. Has anyone succeeded on placing the mouse bites (i.e https://github.com/madworm/Panelization.pretty) while having Edge.Cuts not being perfectly aligned for each segment?
I’ve tried drawing a circle in the middle and adding the mousebites later, but then the middle board is gone and I’m left with castellated mouse bites.
Then I tried drawing partial arcs in the center, interspersed with mouse bites every few degrees, but then the 3D viewer complains
Any good hints? Thanks for this interesting thread!
For complicated pcb outlines you need a CAD tool that can export DXF that is understood by KiCAD.
I wouldn’t try to do any panels/sub-boards other than rectangular ones with KiCAD really.
The offending spot is around this area, right near the mousebites lower hole, but I suspect that this is a more general issue since I cannot see any obvious mistake here:
When I dealt with this type of error in the past with simpler boards it was always a case of Edge.Cuts lines not closing/overlapping properly… since this is a continuous generated .dxf file, that doesn’t seem to be the case since it should be closed already (not manually drawn).
I’m having a look now at KiCad’s 3DViewer function to see what it actually does before erroring out and how I could potentially write a test for this:
I guess if I am not doing the posting I shouldn’t care, but people seem to be happy to spend a lot of time trying to compare and I get confused trying to follow it, so I wonder how newbies manage.
The nightly builds are getting on for 2 years worth more advanced than the stable release, that is a lot of changes. In particular, the 3D stuff has seen a lot of improvements.
So yeah, there are several bugs in stable that are fixed in nightly builds…
No worries @bobc, I just gave it a shot to nightly for OSX from June the 12th (UI looks great, btw!) and here’s the result (same error yet cleaner, less verbose):
So the problem is somewhere else, not in the DXF’s themselves, strange … I’ll play a bit now with the copper layer and footprint placement but I’m a bit out of ideas on what might be the issue here.
Don’t worry @bobc, the dxf comes from inventor and worked in stables before.
I just mentioned the version as @brainstorm is on a mac, which might have been a contributing factor.
Interesting. Maybe a forgotten, nearly zero length outline…
Anyhow, you’ll nail the bugger Good luck.
and 
I get confused trying to follow it, so I wonder how newbies manage.
Good luck.
