pcb-rnd knowledge pool
cam exporting
| cam by Tibor 'Igor2' Palinkas on 2018-07-12 | Tags: announcement, cam, export, plugin |
Abstract: Announcing the cam export option and the cam plugin in an effort to clean up and unify output file name and layer group selection and provide configurable export jobs.
What's the new cam system?
The cam system provides two things:
- a unified API to the few most common operations any exporter plugin want to do
- an optional cam plugin that can call multiple exporters using the cam interface to export several files as one export job
The implementation consists of three parts:
- A few calls to core in each cam-capable exporter that controls the output file name and what layers are exported
- A thin layer in core that can parse the common syntax for the cam export
- An optional cam plugin that can coordinate running multiple cam based exports from configuration
What's does it do in practice?
When used on a per exporter basis:
- the same command line parameter for all cam-capable exporters...
- ... so users don't need to learn a different parameter for "file name" or "don't draw outline" for each plugin
- ... all cam-capable plugins support the same features, there are no random limitations
- per layer group export with any cam-capable exporter (e.g. exporting an internal copper layer to png)
- combine multiple layer groups into one output file
- do other transformation on the layer groups, e.g. invert them or bloat/shrink objects
When used through the optional cam plugin:
- configuration that contains a list of export plugins and cam configuration...
- ... that can output a set of files suitable for a specific vendor
- this can be complex things like generating gerbers, drill files, pngs of various layers
What's wrong with the old setup? What are we replacing and why?
The original approach was a set of per-exporter options, typically chosen randomly (for historical reasons). Some exporters export multiple or all layers combined (e.g. png) while others export per layer (e.g. ps or gerber), sometimes in one file (ps) or in multiple files (ps, gerber).
Furthermore some (but not all) of the exporters had largish kludges, again custom and often different per plugin, for naming the files. The largest and most complex one is gerber's "naming style" system. This also forced us to keep gerber generation and drill file generation in one plugin, while it's a sustainable assumption that in some cases the user wants to get a drill file only.
The new setup cleans this mess up, while keeping backward compatibility. It doesn't change how exporter plugins work so old Makefiles and shell scripts and action scripts won't break. It adds a new "cam" option to some of the exporters.
The cam option provides a unified interface to describe all the above details: what layer groups go in what file with what exporter option. One export session with the "cam" option will result in one file. If multiple different files are needed, multiple export sessions must be run. On CLI, this means multiple invocation of pcb-rnd with -x, or running pcb-rnd with the batch HID and an action script that calls Export() multiple times. This single-file export helps us keeping the exporter code simple.
Finally, the new, optional cam plugin provides a system to set up named "output jobs" and store them in the configuration system. This lets the user save their output jobs system-wide, in user config, per project or even per board file, as needed. Typically sending all files to a vendor would involve executing the cam plugin with a specific cam configuration that in turn runs multiple export plugins with different cam options to produce various output files.
As a side effect, it will be easier to share vendor output configs, as they are really just configs, unlike the hardwired-in-code gerber naming styles.
Why is it called cam?
Decades of experience with EDA tools shows that there are mainly two type of output users want to export from a PCB designer:
- files that can be included in the documentation, can be printed or used for debugging
- files that can be sent to a vendor
In pcb-rnd the first case is pretty much covered by using exporter plugins directly. Different users may have different preferences for what files to generate with what options; some users may even need to generate multiple files with multiple exporter plugins, but it's rare that users would want to share their export setups.
The second case is largely different because there are some common PCB fabs that a lot of users want to use and these fabs specify what files they need (a set of file names and content). Saving and sharing these fab specific export configuration is so much demanded that the gerber exporter had it hardwired in the code for a few fabs.
CAM stands for Computer Aided Manufacturing. The gerbers or even drill files exported from an EDA tool rarely end up directly on machines. The typical process for fabs is to import all the files sent to them into a CAM software that postprocesses them and converts them to other formats the actual machines at the shop can work from.
The cam infrastructure is called "cam" because it is designed to ease producing the input for such a CAM-import process on the fab side.
Support in export plugins
| plugin | lyr | state | comment |
|---|---|---|---|
| export_bom | no | 100% | single-file, no-layer support |
| export_dsn | no | 100% | single-file, no-layer support |
| export_dxf | yes | 95% | layer list is always complete (empty layers created for non-exported layers) |
| export_fidocadj | no | n/a | will not have cam support |
| export_gcode | yes | 0% | plugin is waiting for a full rewrite |
| export_gerber | yes | 100% | won't work: top-assy and bottom-assy |
| export_ipcd356 | no | 100% | single-file, no-layer support |
| export_lpr | yes | 90% | needs testing |
| export_openems | no | n/a | not planned: export format has complex assumptions on layers and includes meshing |
| export_openscad | no | 100% | single-file, no-layer support |
| export_png | yes | 100% | |
| export_ps/ps | yes | 100% | Also consider the --no-show-toc and --single-page options |
| export_ps/eps | yes | 100% | |
| export_stat | no | 100% | single-file, no-layer support |
| export_svg | yes | 100% | can't export assembly or fab drawing |
| export_test | no | n/a | will not have cam support (there is no per layer aspect) |
| export_xy | no | 100% | single-file, no-layer support |
| io_tedax (etest) | no | 100% | single-file, no-layer support |
lyr means the exporter works per layer; no per layer means global/digest exporting (if --cam is supported, only the file name is taken).
(State shows the completion of implementation)