As a child I used ballpoint refill with the ball removed to paint my PCBs and then I etched them in iron trichloride.
That worked, but I don’t regret that I joined the modernization crusade and stared to use IBM-XT with 640k RAM and without HDD to design my PCBs. That needed frequently swapping 320kB diskettes in drive B: (in A: there were the main Racal-Redac diskette not needed to be swapped).
That worked, but I don’t regret that I joined the modernization crusade and started to use for PCB designs the PC with HDD. I used to plot my PCBs at the back sides of cards from a large wall calendar (in 2:1 scale), then to order the photocopy of it and go with that photographic plates to small (those time) PCB manufacturing factory.
That worked, but I don’t regret that I joined the modernization crusade and started to replace my own plotting with sending the gerber files directly to that PCB manufacturing factory as soon as they purchased a photoplotter.
And so on…
I am afraid there is a mix between aperture macros and the (new) X2 format.
Aperture macros are a old feature of RS274X format an are not related to X2 format.
Aperture macros are used to describe a “complex” pad shape from more basic shapes (primitives).
Pads need usually to be flashed, therefore need a shape that is not painted, but drawn all in once.
This is due to the fact pad shapes are also used in post processing in CAM tools (tests, solder mask creation …)
Aperture macros can be defined by a set of primitives (circle, rect …) having a defined size, or having a size defined by variables (notation: $1 $2 …)
When shapes are defined by variable, only one aperture macro is needed by a shape (for instance round rect shape)
When shapes are defined by absolute values, one aperture macro is needed by a pad with a given size.
So one can have a lot of one aperture macros. This is obviously not a good idea.
By the way, Gerbv (not the Kicad Gerbview) does not handle correctly aperture macro rotations, like unfortunately many other Gerber viewers although this parameter is described in Gerber doc since at least 10 years)
(This is the reason Pcbnew does not use (unfortunately) rotated complex aperture macros).
X2 format is an other thing (having nothing to do with apertures):
X2 format adds metadata to Gerber files:
- Identification of files (type of layers: copper, layer, silk screen) that avoid the ridiculous used of non standard protel extensions.
- Net info: needed for CAM tools to automatically test the board.
It is also used in the Kicad Gerber viewer: one can highlight a net, or all pads of a component for instance. Just this feature is enough to use the X2 format.
Note also one can create Gerber drill files and Gerber pick and place files (known as X3 extension)
At least they are correctly defined in Gerber file format.
This is not the case of Excellon drill files (no actual format defined) and not the case of P&P files.
Which is fair enough, except all indications are this is an Aperture macro parsing problem and not an X2 parsing problem. As others have said, X2 doesn’t change pad information, it’s the complete fabrication information since now the layer order is encoded rather than relying on interpretation of the filenames
Now CAM-A not loading X2 (rather than raising warning on the additional commented content) is a CAM vendor concern since if you have an X2 parsing problem then you have a serious X1 parsing problem
The good news is the 1st step in resolving a problem is understanding there is a problem
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.
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.
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.