How do you know what is real F.Silk and what is routing then?
I thought I saw some responses to your question here. Must have been on another thread.
Sorry about ignoring you.l
Well, I don’t know for sure. I was thinking of my situation building a panel and using
silkscreen for the routing. It was on the interior of the panel outline and OSHPARK had
no problem with it. Your specific case may be different. Put comments in that identify
the routing. They are pretty good at figuring out what you want and making modifications
themselves.
I agree. Above all else, talk with your fab directly about your intentions and have them recommend their preferred methodology. OSH Park was happy to answer my questions and in the thousands of boards they’ve sent to their fabs, I’m sure they’ve seen it all and know what works best in these situations. They were also happy to have me send the Gerber files direct to their support address and they promptly reviewed the file and said it should work fine.
As to feeling lazy or making them do more work than normal, I think that’s the service companies like OSH Park provide and what makes them thrive. They are super quick to respond and super helpful and never once was I made to feel like a noob when I was asking noob questions. 8)
And OSHP can’t deal with the outline and the internal milling being on the same Edge.Cuts layer?
I know KiCAD will give you ‘hell’ when you just draw non-closed lines (like a routing path) on Edge.Cuts, so you have to draw the edges of the milling… but it’s not that much work and should be ok with them?
At least then the routing/milling is all on one layer and there is no guess work involved?
I’m about to receive my first nested board design (two LED rings nested inside each other but separate boards). I created the PCBs separately and launched PCBNew manually to combine them into a single resulting Gerber file. It will be interesting to see if the outcome of that fab is as I expected, especially after sending the designs to OSHP for review and having them give me the go-ahead, saying that the output should be as I expect.
This is the result from OSH Park for my nested rings (see below).
To reiterate, I created each ring as a separate KiCAD project and then opened PCBNew manually (outside of KiCAD) to append both boards to the same file for Gerber export.
OSH Park recommended at least a 100mil gap between the two boards (enough for routing) and that in that gap, I add the words “Cut Out”.
edit: I did not create the mouse-bites or the pattern that the fab routed, I just created a space between the two rings - they figured out how to route it out and where to put the mouse-bites. I don’t know if OSH Park did that during panelization (probably) or the fab.
The result is just perfect for what I need and allowed me to make more efficient use of the space - pulling two boards in the same space as one. Arguably, I could put a third board on the inside to make use of that space as well but, honestly, I didn’t have anything that would fit that space.
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…
Weren’t those LEDs all the same orientation, although the centres were in a circle?
Scottchers pcb actually rotates the part
No idea, didn’t see the result afai-remember?
Got a link? … me = too lazy
Found it
I was wrong, these LEDs are rotated, the driver? are not.
I am not sure about the capabilities of typical pick and place rotation
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.
Thanks for the feedback, @Joan_Sparky ! I did a small OpenSCAD sketch of what I want to achieve:
And I successfully imported the resulting DXF to KiCad, adding four mouse bites footprints on the inner circle:
But the 3D viewer keeps complaining, more or less as before regarding Edge.Cuts
interior graphics error as shown before
Any hints on how to please the 3D viewer are super welcome!