Maybe KiCAD should have a CAM350 compatibility downgrade selector for the low cost fabs?
What you mentioned I guess is aperture macro primitive Center Line (code 21), Gerbv can handle it correctly since a specific version (I don’t know when).
In a CAM tool I know, there’s a configuration parameter controls how Center Line will be rotated:
- No (default) - Rotate aperture macro primitive around it’s center point
- Yes - rotate around the 0;0
If this parameters is set to “Yes”, which will comply with Gerber spec. If set to “No”, Center Line will rotate around its own geometry center which is wrong (and this is the default!).
I’ve had the X2 attribute issue with a number of fabs, including domestic (US) fabs like Advanced Circuits (although that was when I first tried the X2 option in early 2019. They may be able to work with these files now.)
After being notified of issues by the vendor I went back to the X1 format and have been using this since.
My workflow includes a quick check of the gerber files in Gerbv version 2.6A. I’ve found that if Gerbv opens it without error and it looks normal, none of the vendors I work with will have issues.
I plotted a copper layer of a board I have been working on recently, designed in the latest nightlies, that I know will successfully generate X1 gerbers. If I plot X2, I received the following errors in Gerbv:
I understand this version of Gerbv is probably 10 years old but it has always been a good representation of vendor capability.
I find that to be VERY interesting… I JUST got my second order in from JLCPCB the other day… a 2-layer and a 4-layer board. I used X2 Gerber option (5.1.6), and aside from a cosmetic issue on one board, they all turned out okay.
Does the gEDA fork/update pcb-rnd have a gerbv style viewer?
Yes, most of the orders with X2 files are OK and this is why I said “maybe my method (ask customers to re-plot RS-274X files) is overkill”
@eelik I scaled down your test file and placed 4 real orders for the 4 different combinations in 4 different colors, need to wait for about 4 days to get the them.
- Board size: 80x50mm.
- Octagonal pads are added.
- Spacing between rows is 300 mil, real DIP-18 ICs can be soldered
- Some USB connectors are added because there are some spare spaces.
- Traces are added to test if they’ll be lost.
Here’s the modified project: Flashpads-01.zip (1.0 MB)
EDIT on 2021-01-11
@eelik, Got the processed files.
- nox2ap 88640F_Y89.rar (657.4 KB)
- nox2noap 88640F_Y90.rar (386.4 KB)
- x2ap 88640F_Y91.rar (479.2 KB)
- x2noap 88640F_Y92.rar (383.6 KB)
I’m kinda disappointed because I found all my order has been processed correctly. Today I contact two relevant colleagues, they said the X2 to X1 converter is already handed to some engineers (who process Gerbers). And they are evaluating this converter/preprocessor, if it’s OK then all engineers will use it.
If you are careful enough you can find traces/evidences which shows my files are preprocessed before they were imported into the CAM tool.
For example, for Y91 (x2ap) in the file in ok folder you can see a temp folder X1_x2ap was created:
1. Path : (File) d:/foldername/88640f_y91_x2ap/yg/x2ap/X1_x2ap/Flashpads-B_Silkscreen.gbr
In Y92 (x2noap), in the yg folder, all my original X2 files are disappeared and they are replaced the RS-274X files except Flashpads-B_Silkscreen.gbr because this file is not used (no contents on bottom soldermask).
EDIT on 2021-01-16
Add photos.
4 Likes
I sympathise with you here. I don’t see KiCad as pushing X2, but rather that X2 is the out-of-the-box default. I always turn X2 off, because the cheap fabs I use have problems with it. So, sure, their CAM software are out of date or buggy, but the fabs are the ones that need to be nagged, not me. I’m not interested in getting review bounces just for a better standard when it has no effect on my simple jobs.
Similarly I continue to use Protel extensions, even though I approve of the use of a single extension from the viewpoint of a standard not using many suffixes. Although fabs seem to do some kind of parsing that works most of the time to identify the layers.
1 Like
In China?
…
I just tried that and had the same results. X1 files work fine. The files generated as X2 will not load.
I think they still rely on Gerbv, as a loosely associated project. I haven’t followed development of pcb-rnd that closely though.
Pcb-rnd is the only gEDA derived project with activity, gEDA is sadly dormant - a good thing in a way for KiCad as the only complete opensource suite being developed and maintained, but I always feel some competition is a good thing
I have attempted to submit X2 format files to JLCPCB in the past and failed… so not sure what changed about your process that allowed this to get into the queue.
Coral EDA also (the project that contains PCB-RND)
I’d say PCB-RND would be the go to tool for lower end machines or people that prefer more retro unix like software. It interoperates with KiCad too.
At the moment the CoralEDA project is suspended as the only active participant is the pcb-rnd project.
Kind of a moot point… since pcb-rnd is the main component… its not like many of the perpherial areas of KiCad are any less “suspended”. Also pcb-rnd has active development just like KiCad these days.
I would say KiCad is much more approachable but, pcb-rnd is itself also useful… and has it’s own niche. Dissing other projects, or claiming some subjective status of “Best and only OSS EDA or some nonsense…” is not a good look for anyone.
Not a moot point because this hijack was response to
I like competition, you can borrow ideas in the opensource world.
I don’t know much about Horizon.
LibrePCB admit themselves that they are not for complex boards and have some incorrect info on KiCad in their comparison
I wish them both well.
1 Like
Just spotted this discussion after Seth asked me about how we handle this issue.
At AISLER we noticed this issue after a user noticed the corrupt preview in our Board Inspector. This was on October 13th. As we develop our CAM software in-house, a fix was deployed later that day. Because of this I can tell you, that it is definitely not related to the X2 extensions but rather to the aperture macro used.
Here is how our software dev described the issue
A spec test exists to reproduce the bug. The bug was located in the contourizer, when translating apertures (in this case a macro) to single polygons. The aperture in this example consists of 9 elements - four of them of type “line20”.
During the construction of polygons representing the lines of type 20, the polygons have been rotated correctly, but not moved translationally afterwards. Thus, constructing the shape failed because of their wrong location.
If anyone is interested I’d be willing to publish our fix. The macro as used by KiCad is definitely valid according to the Gerber specs and as soon as it is implemented correctly it works totally fine.
Cheers,
Patrick
11 Likes