From the “wishlist” item on github I linked earlier to in this thread:
Such a CAM dialog could then also handle exporting and importing CAM
settings.
So KiCad developers are aware of the idea, but currently it is not implemented yet. If you like it, then give it a thumbs up on gitlab. (Current count is 11).
Hah! I’m not awake yet am I. I’ll try and read rather than scan next time !
I certainly will give it a thumbs up, thanks.
In most areas KiCad tries to be conservative, and not make changes that might cause bad PCBs. So I am puzzled why KiCad pushes Gerber X2 so much, it is just one proprietary standard after all.
Because X2 is good (X3 is better) in that it completes the fabrication info (and then assembly info) AND it works. If a fab house accepts GERBER they will work with GERBER-X2
If you look at the test it would appear the issue is with appature and not X2 ( in as far as an exhaustive combination test was not performed). This makes more sense as X2 adds info to COMMENTS and thus is ignored by older parsers
If X2 fails then there is a flaw in X1 readers as it is non-compliant
Other more open standards perform the same function, and it is clear X2 DOES NOT always work.
I don’t understand why we are pushed to join the “crusade to get everyone X2 compliant”.
I just want to make cheap PCBs. Please don’t make me join your religion.
It seems there are issues with using X2 even without aperture macros - see my post here: JLCPCB - strange issue with rounded rectangle pads + kicad nightly
I do agree though that in principle it should be fine for KiCad to default to using Gerber X2 because of the backwards compatible design. And as @atommann said, JLCPCB are working on a preprocessing script to strip out the X2 stuff which shouldn’t be too difficult to do.
On the other hand, I think the move towards using aperture macros is a bit more questionable. There was nothing wrong with the old approach, and it seems that multiple pieces of software struggle to implement aperture macros correctly (see https://blog.horizon-eda.org/misc/2019/11/18/gerber.html ). So, I think it may be wise to have aperture macros off by default.
Like what? IPC-2581 no one uses it and Kicad doesn’t support it. ODB++ quite a few places support it but Kicad doesn’t. RS-274D the defacto standard, yes but things have moved on and here is the kicker… RS-274X is an EXTENSION to RS-274D via adding additional infomation to GERBER comment sections
IF a CAM package or GERBER viewer fails to render a GERBER-X2 file then it is non-compliant to the original RS-274D specification and thus raises the question… what else is it not compliant to.
simply put I fail to see why I should trust something that is not compliant to the RS-274D specification with anything.
It’s just the default. The other option would be to have X2 disabled by default and let people send files without newer features to all manufacturers. The history of X2 goes back to 2012 or 2014. Is it too much to expect that large commonly used manufacturers can interpret 7 years old file format?
Also remember that X2 had be unchecked with v5.1, too. It’s the new aperture macro change which lead to this large scale problem with 5.99.
You sound like a salesman for UCAMCO.
Not just the default, it’s “recommended”. As wikipedia might say, by who?
Again, why do I have to join this modernisation crusade if what I have works?
Its good that @atommann from JLCPCB is looking into this but basically something isn’t right. There are two options in question and thus four combinations
Configuration #1
[ ]Use X2 format
[ ] Disable macro
CAM-A worked
CAM-B failed
Configuration #2
[ ]Use X2 format
[X] Disable macro
CAM-A worked
CAM-B worked
That leaves two other configurations
Configuration #3
[X]Use X2 format
[ ] Disable macro
This is the combination that I use and in the year I have sent cards to: elecrow, ragwork, invotec, garner all returned as expected so at least there is some confidence in this configuration
Configuration #4
[X]Use X2 format
[X] Disable macro
Right now the macro appears to be the biggest culprit and @eelik implied this
You can do what you like and use who you like. I personally would not trust a fabrication house that has questionable RS-274D parser.
And I don’t appreciate your tone. who I am and what I do is inconsequential to this discussion so why even make such a statement
See my thread linked above, where I talk about two orders that I submitted to JLCPCB, with those configurations 3 and 4. Both caused issues.
Yes I did see, which means there are all four combinations covered
so there are other datapoints that show there is parsing concerns. Now since X2 is added to comments: https://www.ucamco.com/en/gerber/demo-1#Q3
This really does imply that the JLCPCB has an X1 parsing problem and since I have used X2 to a number of fabricators with no problems (some RS274D, some RS274X) at least aspects of KiCad’s generation is valid
If an application chokes on Gerber X2, it is not a compliant Gerber X1.
I am not saying you are a salesman, only that you sound like one.
But regardless, I apologize. You are right, no one should care who you are or what you do.
Notes from jp who maintains the kicad gerber implementation and gets involved with UCAMCO who writes the spec.
Today I collected some information about the defective boards I see recently. I think these are not all of them.
Case 1
2020-12-05
Defect: Traces on top and bottom layers are missing
%TF.GenerationSoftware,KiCad,Pcbnew,(5.1.8)-1*%
Case 2
2020-12-09
Defect: Traces on top and bottom layers are missing
%TF.GenerationSoftware,KiCad,Pcbnew,(5.1.6)-1*%
Case 3
2020-12-07
Defect: Traces on top and bottom layers are missing
%TF.GenerationSoftware,KiCad,Pcbnew,(5.1.7)-1*%
Case 4
2020-12-29
Defect: Some corners are missing for Rounded Rectangle Pads
%TF.GenerationSoftware,KiCad,Pcbnew,(5.99.0-7681-ge37a89cdbf)*%
%AMRoundRect*
Case 5
2021-01-03
Defect: Some corners are missing for Rounded Rectangle Pads
%TF.GenerationSoftware,KiCad,Pcbnew,5.99.0-unknown-e48f2a70fe~106~ubuntu20.04.1*%
%AMRoundRect*
Case 6
2020-12-31
Defect: Some corners are missing for Rounded Rectangle Pads
%TF.GenerationSoftware,KiCad,Pcbnew,5.99.0-unknown-81d4e06f00~106~ubuntu20.04.1*%
%AMRoundRect*
Case 7
2020-12-05
Defect: Some corners are missing for Rounded Rectangle Pads
%TF.GenerationSoftware,KiCad,Pcbnew,5.99.0-unknown-1a9878d6d~106~ubuntu18.04.1*%
%AMRoundRect*
Case 8
2020-12-24
Defect: Bottom silkscreen is missing
%TF.GenerationSoftware,KiCad,Pcbnew,(5.99.0-6667-gfc6fc88219)*%
case 9
2020-12-24
Defect: Some pads' soldermask were lost
%TF.GenerationSoftware,KiCad,Pcbnew,(5.1.6)-1*%
case 10
2020-12-23
Defect: Some corners are missing for Rounded Rectangle Pads
%TF.GenerationSoftware,KiCad,Pcbnew,(5.99.0-7551-ge9817932e0)*%
We can see all of them are Gerber X2 files.
Because the RoundRect macro is still new (maybe it was introduced two months ago?), so we can see not so many boards are affected.
This is a useful thread. I do not want to see more personal attacks or rudeness 
@atommann, Here’s a set of gerbers plotted with different settings in the latest Kicad 5.99 (8244-g9424d66d22). KiCad 5.99 generates different kinds of special shapes with aperture macros by default. I have plotted them with and without x2 and aperture macros. This is the set of pad shapes:
Here are the gerber files: gerber.zip (37.1 KB)
Can you send back the same set processed by your default process?
Here’s the whole project for reference: Flashpads.zip (329.6 KB)
The reason why I didn’t mentioned Configuration #3 and #4 is related to how engineers process X2 files at JLCPCB.
Configuration #3
[X]Use X2 format
[ ] Disable macro
Configuration #4
[X]Use X2 format
[X] Disable macro
As I mentioned in JLCPCB - strange issue with rounded rectangle pads + kicad nightly, the CAM-A is the main tool, it can not import Gerber X2 files at all (Honestly I did not used CAM-A, but other people always told me this, I’ll try myself once I got a chance). Now the engineer finds that he cannot import files into CAM-A, what he’s going to do? The answer is he has a secondary CAM which is CAM-B. CAM-B can read X2 files but it can not do the job right every time.
Configuration #1
[ ]Use X2 format
[ ] Disable macro
CAM-A shows the RoundRect macro correctly in my test before, so #1 may work too for KiCad 5.99. Why I chose #2 is because lots of CAM and Gerber readers have problem with aperture macros as lots of people already mentioned in this and other threads.
Thank you very much for the test files. I’ll post the processed files back when they are done.
These custom polygons remind me another issue related to aperture macros (basically some Eagle users are affected): https://www.eevblog.com/forum/manufacture/jlc-pcb-reorientation-of-octagonal-pads/
Kinda off-topic: The author of Horizon EDA sent me files to test the Aperture Macros, I made 5 physical copies myself, and I felt lucky that I got the defective boards (because that’s what I expected 
