Fighting with Altium - Importing extended gerber

[richard.cs]

The background

I have a script that makes pretty copper antenna patterns. It does this by generating a gerber file directly and it has to be extended gerber (RS-274X) because I need to use the G36* and G37* commands to create fills. The  script based the gerbers on https://www.ucamco.com/files/downloads/file/81/the_gerber_file_format_specification.pdf and the files work when uploaded to http://www.gerber-viewer.com/ I have attached an example gerber, renamed as .txt so I can upload it.

I am trying to import these into an Altium .PcbDoc which would allow me to treat them like any other copper feature as part of a larger design. Other components could be added, the solder resist, silkscreen and board outline could all be created easily, etc.

The Problems

1) Altium import (the obvious route) seems not to support extended gerber (RS-274X) despite it existing since 1998 and "standard" gerber (RS-274D) having been deprecated since 2014. This manifests itself as an error "Aperture table not found" when trying to import, and if it's tricked by putting an unnecessary* aperture entry in then it imports only the outer lines. It seems fills drawn with the G36* and G37* commands just aren't supported.

2) The files can be opened in Altium so long as the extension is changed to .GTL or similar. They then load correctly and the fills appear. This seemed really promising. It is supposed to be possible to export this to a PCBdoc as per ?http://electronics.stackexchange.com/questions/173702/import-gerber-files-into-altium and various other similar instructions I have found. This always crashes with an error message about netlists despite the netlist step having been followed.

3) A new Camtastic document can be created and the gerbers can be imported into it, just as with the PcbDoc it imports as lines rather than fills.

*I think it's unnecessary, everything is drawn as fills. I dumped a "%ADD10C,0.01*%" into the third line.

Obviously it's possible my script produces buggy gerbers, but they do seem to work with the online viewer and they open (but not import) correctly in Altium. Any thoughts/suggestions?

[Siwastaja]

Are you sure it's a problem of not having extended gerber supported? That would be nearly unbelievable.

"Aperture table not found" does not signify that at all -- quite the opposite; only the extended gerber actually has something that could be described as an "aperture table", and it's clearly missing in your file. Try to add some aperture inits. Official gerber documentation describes this very well.

The old gerber used a separate aperture file.

Edit: sorry, didn't read carefully, you already did that. Sounds like a bug you are encountering. The fact that it requires n>0 aperture initializations (even when not needed) shows us it's a very buggy, hastily implemented kludge. But your experiment also shows it's clearly importing it as extended gerber.

You might want to try a few more Gerber viewers, to further verify your file is really ok. Try gEDA gerbv.

[richard.cs]

I am perfectly prepared to believe there are bugs in my gerber file, but my interpretation of the spec is that I don't have to define any new apertures if I am just drawing outlines of fills with one of the default apertures. Altium seems to want to see a definition so I put one in to keep it happy, but then I don't see a fill in the import, just the lines defining their outsides as though the fill commands hadn't been parsed at all.

Correction to number 3), importing it into a new camtastic file does work correctly, but export to .PcbDoc leads to the same crash as exporting from an opened gerber.

I found the following Altium documentation that looked useful:

...other applications generate Gerber files which contain commands that are neither used nor recognized by PCB and therefore any attempt to import such Gerber files into a PcbDoc file is usually unsuccessful.

However, CAMtastic’s Gerber file importing feature has been designed to correctly interpret many more Gerber commands and it’s Gerber file exporting feature will ensure that when the appropriate options are selected, the exported Gerber files can be imported into a PcbDoc file.

Hence CAMtastic can be used to translate any Gerber files originally created by another application and modify them so they can then be imported into a PcbDoc file.

Which suggests that gerbers exported from Camtastic with some recommended settings should import OK into a PcbDoc. It doesn't seem to work though, the exported gerbers don't import at all, and when I view them in something else the fills are not included. (I thought maybe it would convert them into painted fills or something but no luck, it just seems to drop them).

Edit:
Re-reading the spec it looks like I am supposed to have defined an aperture before defining regions. It doesn't actually fix my problem though, it stops Altium PcbDoc import throwing an error but it still imports as lines which is my main problem anyway.

[Siwastaja]

I meant Altium is buggy, not necessarily your Gerber file.

Typical Altium approach, implementing the same thing over and over again so you need to try dozens of different workflows, all broken in different ways, until you find one that hopefully works.

It seems they have some kind of fake gerber import which cannot import gerbers, except for their own, limited subset of the gerber format, so they shouldn't call it gerber import at all!

One option might be to rewrite the script to only use the Gerber constructs the Altium PCB import tool supports, but you need to find out by trial and error. There are many valid ways to construct copper regions, AFAIK.

[ajb]

If you've got the lines imported to the PCBDoc, can you not convert them to a polygon or region (Tools>Convert>...) and wind up with something that will work for you?  Can you try importing the objects into a PCBLib first?  Different parts of Altium sometimes use different routines to do the same thing, I know I've had different results when importing into a DXF into a Lib vs a Doc before.

[richard.cs]

If you've got the lines imported to the PCBDoc, can you not convert them to a polygon or region (Tools>Convert>...) and wind up with something that will work for you?  Can you try importing the objects into a PCBLib first?  Different parts of Altium sometimes use different routines to do the same thing, I know I've had different results when importing into a DXF into a Lib vs a Doc before.

I have actually just finished doing that - it works, but it's a bit tedious. Fine as a one-off but it makes playing around and optimising antennas, etc a bit of a pain.

That's an interesting point about importing it into a library, I'll give that a go at some point (probably next week now, it's 16:30 Friday and I'm going home).

[cgroen]

Richard,
I'm not sure if this is related (or meaningful in any way) to your problem or not, but it helped me when I needed to extract a footprint from some of our gerber data:

http://electronics.stackexchange.com/questions/173702/import-gerber-files-into-altium
A "screenful" down the page there is a good step-by-step to extract the data
Hope it helps

[Hensingler]

I have attached an example gerber

I imported that ok in 16.1.

Renamed to .gtl. In camtastic had to add an aperture and flash it once in each part of connected copper. That gives netlist generation something that looks like a pin to hang a net on. Then had to set layer order (Tools | Layer Order). It then exported to PCB as the two pads I placed and polygons which just needed repouring.

[richard.cs]

Adding a flash to each fill flash to make the netlist generation work properly sounds like it might fix the error I saw. I'm on version 15 but I will give it a go. Thanks for the tip.

[texaspyro]

I ran it through my "swiss army knife" gcode processor/converter and told it to spit out a .PDF   The Gerber seems to be fine.  It did show up a bug in my program where arcs in G36/G37 region boundaries were not always being flagged as part of the boundary... 'doh!

[Hensingler]

Adding a flash to each fill flash to make the netlist generation work properly sounds like it might fix the error I saw.

It only needed two flashed 'pads', one for each net. It understood the connected copper and the polygons took on the net of the flash they were connected to. I added and flashed a small round aperture because I wasn't sure what the aperture used to draw the fills was. You probably ought to have pads for the antenna feed points anyway.

[richard.cs]

I have just tried manually putting a flash onto each copper fill and it behaved, exporting to PcbDoc without errors. I thought it hadn't brought the regions in at first but they had been converted to polygons and just needed a "Repour All" to make them appear.  Thank you all for the help, it is much appreciated.

I'll update the script to put the extra flashes in automatically. I was intending to do the feedpoints by dropping connectors out of the component library once it's a PcbDoc.

If anyone's interested the structure is a log periodic tooth antenna, take a look at http://www.antenna-theory.com/antennas/wideband/log-periodic.php or chapter 10.4 of Balanis.*

* Antenna Theory: Analysis and Design, Constantine A. Balanis.