pcb-rnd knowledge pool


Planned/scheduled feature deprecation

deprecation by Tibor 'Igor2' Palinkas on 2020-02-05

Tags: insight, feature, deprecation, removal, obsolete

node source



Abstract: There are a lot of features in pcb-rnd. Some are in daily use, others are "looked like a good idea once but turned out to be unusable in practice". Yet others are "this is something pcb-rnd should have, but it will need to be done differently". This page announces the biggest features that are going to be removed, with expected schedule, rationale, plans/recommendations on alternatives.


List of features for removal

feature schedule summary
Renumber(), RenumberBlock() and RenumberBuffer() actions between 2021 or 2023 will be rewritten as an optional user script; may require refdes renumber from support in the central back annotation infra
MinClearGap() 2021 rewrite in user script! (or use query()+propset() or polygon side enforce_clearance instead)
gsch2pcb-rnd once cschem/sch-rnd works use pcb-rnd action script or import schematics
c-pcb between 2020 and 2025 use a different autorouter
hardwired layer keys between 2020 and 2022 configure custom layer keys from layer attributes
the fullpoly flag not yet decided extended object or multiple plygons by hand
HID background image not yet decided use gfx instead

List of features that got removed

feature date of removal summary
gerber name styles 2020-04, after 2.2.1 use CAM export instead
direct gerber export also doing excellon 2020-04, after 2.2.1 use CAM export instead
old DRC 2020-07, after 2.2.2 use drc_query() instead
crosshair shape 2020-07 non-cross shaped crosshair options (use ddraft instead)


gerber name styles

The old code hardwired file naming heuristics in C code. This made users unable to easily change file names and required programmers to grow the code for each new fab. A lot of users ended up exporting with one of the name styles that was "close enough" and then run an extra script that renamed and/or deleted files.

The old direct gerber export also does excellon export automatically, because that's a very usual combination. However, once fabs start to migrate to requiring drill files in gerber (or who knows in what format), this would be only a source of confusion.

Finally, in some cases the export pack needs a few files exported in other formats; for example an assy drawing in png.

Alternative solutions:

The old DRC system

The new, modular/scriptable DRC system is implemented by the plugin drc_query. It is gradually taking over the role of the old, hardwired DRC system. Soon the old system will be fully removed. What to be aware of during the transition:


MinClearGap() is an action implemented in core that iterates on all objects or all selected objects and changes the clearance fo the specified minimum value if the given object's clearance is smaller.

It was invetned because in the original data model the only way to specify the clearance was to specify it at each object. If the required clearance value changed later, it was not easy to adjust objects in big volumes.

However, pcb-rnd already has better ways to handle this:

Thus MinClearGap() has been moved from core to the oldactions plugin, then will be removed completly.


Long time ago users used gnetlist to export a netlist file then loaded the netlist in pcb and placed elements from the library manually, looking at the netlist, and changed their refdes manually (because the netlist format doesn't have footprint info).

Then came gsch2pcb which automated this. Unfortunately not in a reasonable way: it tried to load and edit the .pcb file, then saved a netlist the user still had to import and a an action script (.cmd file) the user had to run for some element/pin renaming.

A fork called gsch2pcb-rnd happened within the pcb-rnd project, which was also working from the same config system as pcb-rnd to reduce the configuration mess the original tool introduced to the workflow. Later on gsch2pcb-rnd evolved into a much smaller, simpler tool which doesn't have to edit the board file any more and user steps reduced to executing a single .cmd file from pcb-rnd. That .cmd file is an action script that creates the networks and makes sure the footprints are imported and pin names are right. Most of this code is the one that runs the import schematics code within pcb-rnd. The .cmd file is simply what gnetlist generates.

By now, gsch2pcb-rnd is nothing else just an over-complicated C implementation of a shell few liner that would call gnetlist to produce the action script and tell the user to execute that script in pcb-rnd.

Alternative solutions:


c-pcb is a nice, small external autorouter that can do full routing of small boards. However, it is not able to do partial routing, which is an essential feature. The documentation and the file format of c-pcb are rather weak too.

Since there seems to be no chance to improve on partial routing, the file format and the documentation, I decided to stop investing time in c-pcb on my side. This will let the current plugin work for a while, but most eventually it will break and will be removed.

Alternative solutions:

hardwired layer keys

The old approach is hardwired in the menu file: if you press {1}, it will select layer ID 1 (really layer ID 0 intenally).

A major problem with this is that layer IDs are invisible, internally assigned numbers and they do not depend on where your layer is in the layer stack. So on most boards layer 0 (key {1}) will be the top copper layer, but there's no guarantee on this, on another board it can be a random internal layer or the bottom mask layer. So while it works for most boards if they are derived from the same layer stack description (e.g. from the same default board file), it will randomly be different for other boards, and in fact the user really needs to learn the mapping on a per board basis.

A minor problem is that it limits you to 10 layers. If you have a "6 layer board", that means at least 6 copper layers and 2 silks. That's 8 already. If you prefer to use separate gnd/power layers, you quickly reach 10 and we haven't bound anything "exotic" like mask or paste. Of course the old setup allows addressing up to 20, using the alt key (which may fail with modern window managers!) - but then again, it's just a limited set and you can easily run out.

Another related problem is which layers should be easily accessible. I'd say copper and silk and maybe mask, in this order of priority. With the old, by ID setup, you couldn't easily make priorities. If you happened to have your important layers with low IDs, you had easy access, if they got high IDs, you had harder access or no access.

Finally, since we support multi-stroke hotkeys, we really have a key tree. A single-stroke hotkey shadows out a large subtree of possible keys, so we try to avoid them, especially the ones without modifiers, in the default menu file. For example you probably use {c r} a lot. To be able to have {c r}, we had to sacrifice having {c}. If we had a binding on {c}, and you started to type {c r}, parsing would stop right after {c} and pcb-rnd would execute the action for {c} and you would never get to {c r}. (Of course there could be some timer based trickery, but that would just slow down user input and would assume a minimum typing speed of the user - both are worse than simply not having single-stroke non-modifier keys).


We have two optional attributes on layers (not layer groups!), called pcb-rnd::key::select and pcb-rnd::key::vis - the value of the first will set the hotkey for selecting the layer; the value of the second will set the hotkey for toggling layer group visibility of the parent group of the given layer. (Sounds complicated, but it's really just what happens when you click on the layer's name or visibility box).

Easiest way to set these is: right click on the layer name, property editor, click on 'add' on the bottom which will let you add attributes.

The syntax for the value is the same as the key sequence syntax in the menu file. For example:

Once you change these attributes on a layer, they take effect within 500 milisecond, updating the menu items in Window/key bindings/attribute layer keys submenu.

The fullpoly object flag

Full discussion at: mailing list thread 3843. , referring to this example file.


The fullpoly flag is a dangerous thing that should not be used by users and should be removed from the code. In fact I should just remove it imediately - except that I can't because it would break compatibility with the obsolete pcb format....

The plan is this:

Crosshair shape

A less known feature is different shaped crosshairs: besides the normal '+' shaped crosshair, it is possible to get extra crosshair arms in a few predefined angles. Supposedly this helps aligning objects.

However, the feature is pretty much unknown to users. Because it's considerable amount of code in HIDs and its usability is rather limited because of the fixed angles, this feature is going to be removed, leaving only the '+' shaped crosshair.

For aligning objects or rather, moving the cursor or placing objects in a calculated way, using the ddraft is recommended. Alternatively, when a large number of objects have to be aligned, user scripting is recommended.

HID background image

It's used mainly to trace an exisitng board or a mechanical outline from a photo/scan/screenshot. It's a bit painful to get the scale right and it's not easily possible to replace or remove the background image once it is specified. It is not really possible to have two background images, one for top view and one for bottom view either.

As of lihata v7, we have support for generic pixmap (gfx) objects. These objects can be resized freely and placed on a layer basis. Which means visibility can be controlled more easily (by layer visibility), multiple overlapping images are handled (e.g. on a top and a bottom layer) and the image is saved with the board.

The transition will go like this:

Renumber(), RenumberBlock() and RenumberBuffer()

The renumber plugin is 321 sloc long and offers three actions for renumbering subcircuit refdes':

This plugin has the following problems:

All three actions shall be rewritten as an user script hosted on edakrill. The script should have a simple dialog box for GUI usage and should build on pcb-rnd built-in back annotation features instead of inventing an unknown/unspecified file format limited to refdes renumberings.

History of the renumber plugin: the Renumber() action was part of core before early 2016 when it got moved out to a plugin. Later that year DJ's RenumberBlock code was imported from the web.