I had manufacturing errors from the radial electrolytic capacitor footprint
The footprint used was this from Capacitors_THT
I suspect this is the silkscreen CAM circles bug again.
Maybe the library should use a 180 degree arc?
Maybe the Chinese fab should instead update their software?
2 Likes
I just took a moment to compare the code generating circles1 with the Gerber spec and it looks like everything is being done correctly (and I’ve had countless boards made with circles on them without this problem). I think there’s something wrong with the fab’s software.
I am however not familiar with this bug, do you have any reference to it?
1 common/common_plotGERBER_functions.cpp, ThickCircle(), Circle(), and Arc()
Never mind, I’ve turned up a bunch of discussion on this.
For reference, see: https://bugs.launchpad.net/kicad/+bug/1385177
It’s caused by fabs using old versions of CAM350. The gerber needs to be in metric mode AND use 4.6 precision AND use arcs. If it’s in 4.5 precision, the problem doesn’t happen.
Ah yes, the old circle bug. https://bugs.launchpad.net/kicad/+bug/1385177
It seems that CAM350 v9 has this bug, but possibly other software too. I guess the reason old buggy software is used is because they got hold of it “for cheap”. It may be related to 4.6 format or not.
Official KiCad position : KiCad generates the correct output, and will not change to accommodate fab houses
Workrounds:
- Don’t use circles in KiCad. Create using arcs.
- Find a different fab house that happens to use a less buggy CAM software
- Persuade the fab house to spend money upgrading their software (good luck with that!)
\4. Use 4.5 format. General consensus now seems to be that it is related to the 4.6 format and that solves the issue.
This problem is caused by fabs using waay out of date versions of CAM350.
The conditions which need to be met are:
- Metric gerber
- 4.6 precision
- arcs
If you change any of the above, the problem goes away.
The consensus decision from a few years ago when this first surfaced was that KiCad shouldn’t attempt to work around the buggy software out there.
One workaround for this (if you can’t find any other solution, perhaps you only have gerbers from KiCad, not the board file), is to use gerbv to rewrite your gerbers, before submitting to the fab.
Mitch.
2 Likes
LOL, I tell people the conditions in the IRC channel, and there’s a rush to post it here 
Ah well, at least any newcomers to KiCAD will be warned now (again)
PS: my personal workaround is not to use circles in the silkscreen in my fps.
I’m thinking about changing the default to 4.5, or at least proposing it. Honestly I’m strongly against this “unanimous” agreement not to work around bugs in other packages. That’s one of the most important parts of software development - you have to interact with the real world, not the imaginary one where everyone follows specs perfectly. It’s also absolutely hellish and one of the worst parts of software development, but in my opinion it is a necessary evil. When I make a PCB, I don’t know what software the fab is going to use with it. I might not even know which fab it’s going to at the time.
Software supporting quirks of other software is basically why anything works at all. Just imagine how much of the Web would be broken if browsers didn’t have quirks-modes where they emulate older, broken browsers. And trust me, if somebody switched browsers and suddenly their favorite sites didn’t work, when they did with the last one, they wouldn’t be blaming the sites. This goes for EDA software too.
As developers it’s tempting to sit here grumpily muttering at our monitors that “the users should blame the fab”, “the fab should upgrade their software”, etc etc, but this muttering doesn’t make any of that happen.
2 Likes
All dandy, but it’s just a hand full of fabs over in China… not the whole world.
I do send my stuff to the same aggregator over there now for a while, one time the fab does the correct thing, another time it doesn’t. I don’t even have control over paste mask or soldermask some times… it’s a gamble, but it’s cheap enough to not matter.
I’m not in production yet and don’t really care.
But KiCAD really shouldn’t try to catch all oddities on this planet, especially for niche cases.
There are enough oddities in KiCAD itself that need work 
The trouble is that this always seems to happen when you are in a hurry.
What is needed is a detection of the combination of circle and 4.6 and issuing a warning about possible compatibility with work round. I agree that just replacing circles with 4 quadrants is not the way forward
Saying don’t use these fabs is just not an option for many of us.
Well, that takes care of that then!! No need to worry about this issue anymore @Joan_Sparky doesn’t care!
Perhaps there could be an option when plotting to convert circles to arcs by default, then we could turn that option off when we know we are dealing with a fab who can handle circles?
What would the point of such an option be? Converting circles to arc segments is hackish, but once you’ve done it despite the hackishness, what do you gain from having an option to turn it off?
There is no need for this, the known work round is to use 4.5 mode. This drops the Gerber resolution, but these broken Fabs are the not the ones that are going to be able to make the finest pitch boards anyway.
The lack of any warning about why we still have 4.5 mode is the issue to me
1 Like
What is to gain by plotting circles instead of arcs in the first place when you know it causes problems, regardless of who’s software is to blame?
I…just asked you the same question. 
No…you didn’t, but anyway, I would prefer not to sacrifice resolution just in case some footprint I used from the KiCad libraries happens to use a circle. What would the point of having support for 4.6 be? Hackish or not it would solve the problem without any compromise elsewhere.