JLCPCB - strange issue with rounded rectangle pads + kicad nightly

[atommann]

Hi,

JLCPCB has got the email from David, thank you all for the feedback, and we are very sorry for the troubles. By the way, recently some other KiCad users who use the nightly version also met this issue.

Here I try to explain how this happened:
KiCad nightly build 5.99 use Aperture Macro RoundRect to represent the rounded rectangular pads, but some CAM softwares just can not handle them properly/correctly.

Engineers who processes Gerber files mainly use two set of CAM softwares, let’s call them CAM-A and CAM-B, CAM-A is the primary tool.

The work flow is like this: If the engineer who processed the Gerbers found he/she can not import the Gerbers into CAM-A, he/she will try to use CAM-B to import the Gerbers, now CAM-B read the file successfully, he/she will export the Gerbers from CAM-B. Then again import these files (from CAM-B) into CAM-A to do further processing (remember CAM-A is the main tool).

CAM-A: Which can not handle Gerber X2 and RoundRect Aperture Macros.
CAM-B: Because Gerber X2 and RS-274X are compatible at image level, so CAM-B can partly handle Gerber X2 but not 100% OK.

So, when CAM-B imports the Gerbers from KiCad nightly 5.99, some round corners are missing and some sharp concave corners are formed. I think this can explain the defective pads in the first post of this thread.

I call this a “new EDA vs old CAM problem”. But as @eelik said:

@eelik

KiCad creates correct output according to the gerber standard AFAIK.

The RoundRect macro comply with the Gerber standard. It’s just lots of CAM software can not handle aperture macros good enough.

The developers at JLCPCB have wrote a converter to convert the RoundRect macro apertures into other Gerber elements. But they are still debugging so this converter is still not put into use yet.

So currently please don’t use Gerber X2 when you place the order. And please check “Disable aperture macros” option to disable it. When the converter is ready I wish this problem will be solved.

–
Best regards,
Atommann
An engineer from JLCPCB

[atommann]

Regarding David’s another order:

This issue is mainly caused by the use Gerber X2. As mentioned in my previous post, because Gerber X2 is not supported at JLCPCB, when the engineer processed the Gerbers, he/she will try to import the X2 files into CAM-B. This conversion caused the lower resolution. If you export RS-274X instead of Gerber X2, I think this issue will be gone.

I also want to mention the files in the “yg” [^1] folder. It contains the original Gerbers from the customers and generally it should not be modified! But it has been modified for David’s order.

By the way, I’ve never used KiCad nightly 5.99 for production. Now I’m installing it in Ubuntu 18.04 and want to test the Gerbers.

[^1]: yg is the abbreviation of Chinese Pinyin Yuan Jian (Chinese characters: 原件), which means “Original document”.

–
Atommann

[DavidR]

Thank you for the detailed explanation @atommann.

So, when exporting gerber files we should unselect “use extended x2 format” and select “disable aperture macros”, right?

I had also been supplying drill files in gerber format, so I presume it would be easier for you if we continued to use .drl / excellon format for that too.

[atommann]

Hi David,

Because I’m still installing KiCad 5.99 so I’m not 100% sure. But yes, currently jut to be safe, please uncheck “Use extended X2 format” and check “Disable aperture macros”.

Excellon files are always suggested. Drill map file are suggested too. By the way, I’m still writing the tutorial on how to export Gerbers from KiCad for JLCPCB. Once it’s done, I’ll post a thread in this forum.

[atommann]

There’s another issue with Gerber X2 from KiCad at JLCPCB: Traces will be lost.

It is also related to the work flow I mentioned above. When CAM-A can not read the file, engineers will try the files with CAM-B, CAM-B can partly process it, but for some designs the traces will be lost and only pads are left!

CAM softwares are just black boxes, no one knows what is happening when it processes the Gerbers. For example, the attributes information may interference the interpretation of the image elements even Gerber X2 is compatible at the image level with RS-274X. If the engineer first use a filter to remove the Gerber X2 attributes, then maybe both CAM-A and CAM-B can handle it.

But the aperture macros is still hard for some Gerber readers. There’s a related post from Horizon EDA’s blog (I think it is a good example): Gerber Aperture Macros are hard for everyone

In short, JLCPCB is still not ready for Gerber X2.

[atommann]

I guess I’ve figured out why two corners are lost for the rounded rectangle pads.
In thread Apologies from atommann (an engineer from JLCPCB), about Gerber X2 files at JLCPCB, I suspected it was caused by the 5th parameter (rotation angle) of Apertrure Macro Circle (Code 1), and it is!

Here’s the test I did this afternoon:

1. Create a project in Kicad 5.99 and add several chip capacitors which uses RoundRect macros.
2. Generate Gerber X2 files with Aperture Macros enabled.
3. Import Gerbers into CAM-B, two rounded corners are missing.
4. Copy top copper layer, remove the 5th parameter for circle.
5. Import the modified Gerbers into CAM-B again, all 4 rounded corners are displayed correctly.

Same layer, circle with 5th parameter vs without 5th parameter:

The Gerber Format Specification Revision 2020.09, page 52:

The Gerber Format Specification November 2013 Revision J1, page 85:

[Naib]

interesting and nice investigation.
So looking at the GERBER spec 2020.09, the 5th parameter is listed as OPTIONAL (default no rotation)

so if the example is:
%AMCircle*
1,1,1,5,0,0,0*%

vs
%AMCircle*
1,1,1,5,0,0*%

so… if you have time, if you were to take a KiCad X2+macro GERBER set and manually remove that additional rotation parameter (whatever the angle) does it work in both CAM packages?

rotation on a circle seems odd because it is symmetrical … but it’s the spec. If manually removing works then one solution would be an option to suppress rotation information. Ideal solution is interacting with the CAM vendor but well

[DavidR]

@Naib It’s rotation around the macro origin, not rotation around the centre of the circle (which obviously does nothing).

However, for compatibility reasons I think KiCAD should be modified to avoid outputting the rotation parameter at all. I have raised an issue for this: https://gitlab.com/kicad/code/kicad/-/issues/7047

[Naib]

@DavidR

@Naib It’s rotation around the macro origin, not rotation around the centre of the circle (which obviously does nothing).

oooooh… that makes more sense

and yes some UI option to disable rotation it probably the best. Then Fab houses can list their recomended settings.

[DavidR]

I don’t even think it needs to be a UI option. What’s the point of outputting that data if it just serves to make the file bigger and less compatible? As far as I know KiCad never outputs a nonzero rotation there.

[Naib]

The point would be specification compliant. The updated specification w.r.t. the aperture macro explicitly states the rotation. While it is optional, it is still there and at some future date some new rotation might be required to create more complex openings and thus completely removing the ability to include this could cause problems later.

Also the inclusion would help with a statement that the format aligns to a certain version of the specification

[DavidR]

Well, don’t output it if the value is zero, then.

[Naib]

that’s viable, as long as it was captured in some document that this is the behaviour…
i’m just from an industry where an awful lot of time and money is spent to exhaustively show not only compliance to but also the exact response to requirements is. If a source material that something is meant to show compliance to stated the format, then this would need to be demonstrated

[atommann]

Did another test on the rotation angle for aperture macro circle primitive.

Also just several chip capacitors with rounded corner rectangle pads. Modify one rotation angle to 22.5 degrees to see how the pads will look like in different Gerber viewers. am-circle-rot-test-gerbers.zip (8.6 KB)

0 Add four circle primitives for the rounded corners*
1,1,$1+$1,$2,$3,22.5*
1,1,$1+$1,$4,$5,0*
1,1,$1+$1,$6,$7,0*
1,1,$1+$1,$8,$9,0*

Reference Viewer by Ucamco:

gerbview in KiCad 5.99:

tracespace view:

Gerbv 2.6.1 in Ubuntu 18.04:

[bobc]

@atommann

Reference Viewer by Ucamco:

The UCAMCO viewer does not show UCAMCO spec files correctly?

So much for “standards”

[atommann]

It did shows it correctly as you can see one circle was rotated 22.5 degrees around the macro’s origin. So looks like KiCad’s own viewer, tracespace viewer, ref viewer from ucamco all implemented correctly as per the Gerber spec rev 2020-09.

[Naib]

@bobc

The UCAMCO viewer does not show UCAMCO spec files correctly?

So much for “standards”

That looks correct though. Rotate the circle 22.5deg around the origin and you would have that. The modification was done at RAW level not generated by some package. Gerbv-2.6.1 outright ignores any rotation

[atommann]

2.6.1 is not the latest version of Gerbv. I’m curious how the test file will look in the newest Gerbv.

[Naib]

True, it is interesting it silently ignored the final parameter. I would have expected some form of warning as the aperture termination would have been incorrect against an old parser. This would imply it isn’t parsing correctly.
good question how it is viewed in the updated version.

[bobc]

I tried windows version of 2.7.0