I call BS on that. Whatever the external format, these " long sequences of numerical calculations" could be done internally with double precision. What are these long sequences anyway ??
I’m not convinced 6 places are necessary.
In practice more than 5 decimal places is probably not necessary, but the main point was that the allowed perturbation is +/-0.5 μm.
But from a software perspective, the difference between outputting 4.5 vs 4.6 is trivial. But using 4.6 with G75 arcs can trigger a known bug. So far this only affects silkscreen but circles on copper layers would be far more serious.
It appears that four quadrants is the fully compatible failsafe, has anybody seen evidence that 180 degree arcs is OK?
The solution is apparent really - put arcs in the footprint for the KiCAD models on github instead of circles.
It’s not how-it-ideally-should-be, but it will work no matter what.
And people who are most inclined to use the KiCAD libs are exactly the ones that will run into this issue without knowing - they use the KiCAD libs exactly for this reason - not having to deal with the details of why-this-and-why-that.
By modifying the source for them, you make the KiCAD libs technically a little less ‘clean’ but avoid any downstream-issues. Just need to get @SchrodingersGat + team on board and maybe leave a note in the KLC for why they are that way.
Next step after that would be to set KiCAD-out-of-the-box conservative as @c4757p want’s to and have the tick at 4.5 instead of 4.6 - again, the occasional user will be more safe this way.
Personally I’d prefer the default output format to be 4.5; at least that’s a known workaround for the Bad CAM problem. I don’t know what’s gained by 4.6. If we have such short line segments that we need that extra decimal place, I’d say there’s something seriously wrong.
I’m not sure the OP in this case fits your description of the type of user who might be bitten by this.
Why suggest these illogical solutions when they do nothing to fix the issue? Who would really be so bothered by the fact that KiCad uses single quadrant arcs instead of full circles? And the issue would be fixed and allow circles to be used on any layer with any format.
And you wonder why no one wants to get the source and create patches!
I have been digging and found this three year old message
https://lists.launchpad.net/kicad-developers/msg15258.html
The cause then and clearly still to this day is that some Fabs cannot deal with 360 degree G75 arcs. Two 180 arcs always works.
I have been bitten by this one because 2014 is long before my time here on KiCad and most of my boards are SMD, avoiding this compatibility problem.
The frustrating thing is that this knowledge is hard to uncover and libraries like Capacitors_THT use full circles unnecessarily
Dislcaimer:
I’m just a user here who posts a lot (probably should change that as well) and just got a mod badge to being able to do more on the forums - in no capacity am I speaking for what the devs want or do.
I also have no illusions about what my ramblings cause in the end - most of it will run down in history as ‘blah bla bla …’
Really need to add a disclaimer to my posts it seems.
You can’t fix issues that sit OUTSIDE of your sphere of influence caused by a minority who doesn’t apply bugfixes to the software they are using.
And there is no need to do any coding to convert arcs into circles every time.
Just change the libs, add a note to the KLC and set the standard export to 4.5.
Done - IMHO.
If you were fixing it at all you wouldn’t stop there, go for line segments I say.
Go straight for the root of the problem.
I don’t wonder about that one really, but I’m pretty sure it’s not because of me or my suggestions.
99.9% of the people who want to or do use KiCAD don’t look for another past-time-coding-project, they simply want to get from circuitry to pcb assembly as comfortable as possible and simply have no time or interest in dealing with the code of the tool.
The 0.1% that does have the ability and desire to change things will probably do fine and join the KiCAD IRC channel and the dev mailing list and work from there - probably never to be seen on KiCAD.info again. 
PS: I haven’t looked at the source once since I’m using KiCAD as I have enough other stuff to deal with already.
Yes you can, software developers do it everyday!
???
Changing the libs does nothing to stop someone from creating such a footprint in the future. Nor is there any reasonable reason to not support for 4.6 format.
@c4757p is one dev of many… I can’t speak for him nor the rest of the devs.
If you want to know what they think, go on IRC/dev mailing list and ask that question.
Why should KiCAD prohibit absolutely correct data to be created just because a minority of fab houses on this planet use an outdated piece of kit?
That doesn’t make sense to me, sorry.
And KiCAD wouldn’t stop supporting 4.6 under @c4757p 's and @cbernardo 's proposal to get this on safe tracks, it would just set the tick at 4.5 instead of 4.6 when started afai-understood-it.
PS: I’m out of this, I made my personal point and don’t want to drag this on. My voice on this matter doesn’t count anyway.
1 Like
I don’t recall anyone suggesting it wasn’t correct, but it causes problems which can be avoided in a manner that would be completely transparent to everyone.
The problem is we don’t know which ones do or don’t, unless you can provide us with that list?
Exactly! So at any point it could be selected and the problem reintroduced. What is “fixed” by that?
MANY of us create and maintain local libraries. Even if the KLC said something like, “Creating circles from two or more arc segments is encouraged.”, I’d probably still use circles because they are easier to create and much less error prone. If I used a standard KiCAD library footprint as the basis for my own footprint, and found a circle made from arc segments I’d be inclined to convert it to a real circle.
Since the problem is known to be related to outdated CAM software used by a relatively small number of fab houses, it’s reasonable to expect the problem to resolve itself in the future. I’d argue that the most correct solution for KiCAD is an informational dialog popup displayed when you plot a Gerber silkscreen layer. It would say something like, "This silkscreen layer uses graphic circles. These may be rendered incorrectly on boards produced by the following vendors: . . . .
The python script circles2arcs.py can avoid this problem by converting silkscreen circles to multiple arc segments."
Dale
1 Like
It’s been around for many years already.
That may be the case but how does anyone know who to avoid?
But why is everyone so against fixing this issue in a manner that would solve it 100% and be completely transparent to any user? You wouldn’t even know it had been done, there certainly wouldn’t be any nagging dialog/message boxes popping up every time you plotted your Gerbers. Make it an option then, but an option that specifically states why it is there, then you can disable it at your own risk.
This is something that could potentially cost a KiCad user hundreds of dollars because of an issue that was well known for years but people were just to proud to change it.
I have now found out that my fab was aware of the problem and usually fix it manually, missing my last board.
I have now changed my own footprints to use two arcs. Hacking at the Gerber level is accident prone
Completely unrelated to the thread opener’s problem, but:
Using 4.6 precision for Gerber output in Kicad produces data that is wrong in so many ways when imported into the software that is used to control the LPKF PCB milling machines (CircuitPro) while using 4.5 precision works. This is (among many other things) a fault on LPKF’s side and appropriate bug reports have been filed.
Nevertheless, since we are deploying Kicad in our classroom installations and the students use it for their appointments and projects and since we have two LPKF PCB mills, I strongly support having 4.5 as the default precision.
From past experience my guess is that, whenever 4.5 precision becomes the default in Kicad, it will be sooner than LPKF fixing the bug 
One reason not to fix by putting arcs is that the standard discourages this. Ideally market forces will make people fix buggy implementations (yeah, sure). This is not unreasonable because it’s difficult to stick to the specification once you start making exemptions for all the bad 3rd party software you might encounter. So what may be “obvious” to some users is simply the wrong thing to do. The best we can do is default to 4.5 and put in a message that 4.6 will cause problems with some old CAM software so use with caution. Why corrupt KiCad’s implementation because of someone else’s faulty software?
5 Likes
Re: changing the default to 4.5
Also Re: adding a warning icon/message next to 4.6 in the plot dialog
Ever sit down to do something really simple and then realize it’s actually a big smelly onion of problematic layers and much harder to do than it seemed on the surface?
Yeah.
(╯°□°）╯︵ ┻━┻
3 Likes
Which “standard” would this be? The Gerber file format specification seems to suggest exactly the opposite.
4.5.9 Numerical Instability in Multi Quadrant (G75) Arcs
In G75 mode small changes in the position of center point, start point and end point can swap the large arc with the small one, dramatically changing the image.
This most frequently occurs with very small arcs. Start point and end point are close together. If the end point is slightly moved it can end on top of the start point. Under G75, if the start point of the arc is equal to the end point, the arc is a full circle of 360°, see 4.5.1. A small change in the position of the end point has changed the very small arc to a full circle.
Under G75 rounding must be done carefully. Using high resolution is an obvious prerequisite. See 4.9.1.
The Gerber writer must also consider that the reader unavoidably has rounding errors. Perfectly exact numerical calculation cannot be assumed. It is the responsibility of the writer to avoid unstable arcs.
Under G74 arcs are always less than 90° and this numerical instability does not exist. G74 is intrinsically stable. Another option is not to use very small arcs, e.g. by replacing them with draws - the error is very small and draws are stable.
In the end what matters is the user experience, they don’t care if the Gerber files contain arcs instead of circles, they care about receiving the boards they paid for, just like they did when they were using other software to design their boards.
This isn’t the sort of numeric instability described there, so the underlying problem likely has something to do with the CAM’s parser. Having no access to CAM350 we can’t even say if avoiding G75 would fix this problem or if it will still come up if 4.6 format is used. If someone can confirm that the problem goes away for all known bad CAMs (ageing versions CAM350 are all I’m personally aware of) if we use G74 exclusively then we may get the chief devs to consider making modifications to avoid G75. Otherwise the consensus is still “incorrect 3rd party implementation - not required to fix”.
No, perhaps not, but you miss the point. Reread the last paragraph in conjunction with your statement …
In fact it does the opposite suggesting the use of G74 arcs as they are intrinsically safe.
Making this statement …
also nonsense, as there would be nothing “corrupt” about it.
1 Like