pcb-rnd knowledge pool


cam exporting

cam by Tibor 'Igor2' Palinkas on 2018-07-12

Tags: announcement, cam, export, plugin

node source



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:

The implementation consists of three parts:

What's does it do in practice?

When used on a per exporter basis:

When used through the optional cam plugin:

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:

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)