Yes, v5.99 has lots of problems at JLCPCB now. I just checked a quality issue complaint: The design is an open source keyboard I guess. It has nice artwork (big logo, with complicated shapes) on bottom silkscreen layer, but the physical PCB does not have it! When the engineer imported it into CAM-B, the bottom silkscreen was gone but top silkscreen was keeped.
%TF.GenerationSoftware,KiCad,Pcbnew,(5.99.0-6667-gfc6fc88219)*%
This is what is confusing… GerberX2 is backwards compatible and thus the only way GerberX2 is being mangled (but GERBER isn’t) is aspects of the underlying GERBER parser is incomplete and thus is not to specification. Possible case of “good enough”
eelik mentioned this thread in:
As I read it, this (newer) feature in the use of Gerber in KiCad is incompatible with the (older?) implementation that is used by JLCpcb.
Did a quick test. manila-ice is used in this test, thanks Joshua.
The settings:
CAM-A reads KiCad’s Aperture Macro RoundRect correctly, we can see the structure clearly.
(Some specific version of it)
We can see the round corners are missing in CAM-B.
The settings:
CAM-A reads it correctly.
(some specific version of it)
CAM-B reads it correctly too.
Answered, see the screenshot in my last post.
Yes, that confirms what I understood after all related discussions: Disable (uncheck) X2, Disable (check) the new aperture macros.
So essentially don’t do the recommended stuff. Weird. 
A slightly tangential but related question.
Is it possible or are there plans to have presets for Fabrication Outputs ?
It’s these sort of Board House idiosyncrasies that get forgotten if you use different companies to manufacture different PCBs. I would certainly find it useful to save a preset for JLCPCB, PCBWay etc etc etc
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