Yesterday I discussed this with the head from the prototype manufacturing department. So we agreed to a decision: If CAM-A (the main CAM software used) can not import the user’s Gerbers and if it’s from KiCad and it’s Gerber X2. We need to ask the customer to re-plot the Gerbers in RS-274X format.
This morning, when I reached the office. I see tons of orders are in Gerber X2 format and they are stopped! I wrote an email template, so my colleagues can send it to customers to inform them to re-plot the file in RS-274X format.
I feel nervous as lots of orders will be delayed and maybe my method is overkill.
So I write this letter here to apologize for all the inconvenience.
By the way, JLCPCB is working on to support Gerber X2. We’ll announce it when it’s ready.
@paulvdh, that is not accurate! We are talking about v5.99 which is different. It generates different kind of gerbers. Linking to 5.1 instructions doesn’t help, it may create more confusion.
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.
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”
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).
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
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.
