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.
|
