[Circuitsmith-development] Gerber files and stuff

[Kenneth M. <km...@ci...>]

Hi guys,

I thought it would be a good idea to hash out the gerber stuff now that 
Roy has started looking into it.

First some background. I apologize if you know all of this already. 
Gerber files are the industry standard format for transferring pcb 
designs to pcb manufacturing companies. There is one other file type for 
defining drill locations - oftencalled excellon or NC drill files - 
which tends to get lumped in when we talk about gerbers. 
www.apcircuits.com has some good examples and descriptions of the two 
file types. Basically drill files contain a list of drill sizes used 
followed by the location of the drill hits. Gerber files (extended 
gerbers that is) contain a list of aperatures (shapes) followed by 
application of those aperatures as either flashes (used in a single 
place) or drags (used to make a line). As you'll find from the RS274X 
format, you can get pretty fancy with them. Unfortunately most PCB 
houses don't like all of that so I think we should ignore it, at least 
for now.

I'll quickly talk about how the files are used. Note that I'm not going 
into any details about the specifics of the formats, such as units, 
precision and all the other options available.  These are details. When 
I send cam (computer aided manufacturing) files to a board house I send 
one board's worth zipped up in a single zip file. This zip file would 
contain something like the following list. I've used Protel's standard 
file extensions just because I use them all the time.

PC0003-02.gtl --- top copper layer extended gerber
PC0003-02.gbl --- bottom copper layer extended gerber
PC0003-02.gto --- top silkscreen extended gerber
PC0003-02.gbo --- bottom silkscreen exteded gerber
PC0003-02.gts --- top solder mask extended gerber
PC0003-02.gbs --- bottom solder mask extended gerber
PC0003-02.gm1 --- outline layer extended gerber
PC0003-02.txt --- NC drill file
readme.txt --- text file describing the type of board, thickness, 
plating and all the filenames. This is read by humans usually to make 
sense of all of the above files

Often manufacturer's also want aperature files and drill table files. 
These are throwbacks to the original file types when each gerber and 
drill file did not specify the aperatures and drill diameters at the top 
of the file.

So, what do we do? It would be cool if CircuitSmith was pretty 
automated. For instance, it could just produce the zip file. I don't 
know of any program that does this yet; although I might be out of date. 
I would also like the option to have multiple gerber settings per pcb. I 
imagine a gerber setting class which extends EdaTreeNode  - let's call 
it EdaGerberNode for now - and they appear in the tree as children to 
the PCB. They would have some sort of properties dialog which would 
probably be multi-tabbed.

First tab: General
this tab has a bunch of settings like output file name, whether to zip 
the output, format for gerbers, absolute vs relative origin etc.

Second tab: Layers
This tab has a table of files to generate. Columns: name, layer name(s), 
type of file
The user can add or remove files.

third tab: readme
This tab sets up the auto generation of the readme file. I imagine it's 
probably just a big text box which the user can write out the text of 
the readme along with special tags for file names, board thickness, 
plating, silkscreen colour etc.

All of these settings will get stored in the EdaGerberNode so the user 
can easily generate files again and again and only set it up once. It 
would be neat if there's a way to set up global settings for these so 
they all start in some preconfigured (by the user) way.

The user can then hit a generate button (either from the node pop-up 
menu or from the dialog) a file dialog will pop up to ask where to 
generate and then  the dialog will make all of the gerber files as 
specified.

So, on to the mechanics of making the files. I figure that gerber 
generation is most similar to a printing operation, so it makes most 
sense to use a Graphics2D context to carry out the task. This also 
provides a nice split between what we have now and the addition of this 
gerber functionality. For now I am going to assume that Roy will come up 
with some magical way to render text (of whatever font) onto the gerber 
context so no consideration needs to be taken from the other side of the 
program in this regard. The EdaGerberNode will step through each file 
it's supposed to generate, and call the draw method of the pcb with 
parameters of an EdaGerber2D and an EdaLayerList containing the required 
layers.

Does anyone have any suggestions or things they really want in this 
area? I think this is a pretty good way to start.

Cheers for now.

Kenneth.