pcb-rnd knowledge pool
Planned/scheduled feature deprecation
| deprecation by Tibor 'Igor2' Palinkas on 2020-02-05 | Tags: insight, feature, deprecation, removal, obsolete |
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 and 2023 | will be rewritten as an optional user script; may require refdes renumber from support in the central back annotation infra |
| 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) |
| gsch2pcb-rnd | 2023-06 (after 3.1.1) | use pcb-rnd action script or import schematics; the code itself got moved to a separate repo , just in case (but do not use it, rather switch to import) |
| MinClearGap() | 2023-06 (after 3.1.1) | rewritten in an optional user script. |
Details
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:
- migrate to using CAM export for generating gerbers+excellons for fabbing; CAM lets the user specify file names and different export plugins in config and unlike direct exporting, it is export job centric, not code centric
- or stick to do file renaming from a shell script or Makefile, but then use the default pcb-rnd name-style with the gerber export; that's the only name style that will remain after the name style feature removal
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:
- both the old drc (drc_orig) and the new drc (drc_query) works into the same drc dialog, so you may get redundant results for a while
- there's a master disable bit for each plugin in the conf tree: plugins/drc_orig/disable and plugins/drc_query/disable - you can use these to control which plugin(s) to use
- the new system has better GUI support
- the new system offers more control: per rule disable (conf subtree design/drc/disable), more detailed settings
- new settings are all under design/drc/
-
compatibility:
- rules are gradually rewritten in drc_query, so the new system can perform (among new tests) compatible tests with the old ones (so the new system is compatible with the old)
- old settings from directly under design/ are copied as low prio values into the new settings (for the few new drc rules that do the same as the old drc); but the value can be overriden by setting the value at the new place under design/drc/; so the new drc is backward compatible with the old
- new values are not copied back to old settings; this means any change to the new values (under design/drc/) will be ignored by the old drc (e.g. if you open the board with an old version of pcb-rnd)
- the GUI for the old drc (in preferences, sizes & drc tab) will be replaced by gui for the new drc
- the old DRC plugin (drc_orig) will be removed in 2020
MinClearGap()
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 invented 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:
- use query() or the advanced search to select objects with insufficient clearance and then use propset() or propedit() to make the necessary change - this doesn't require a C hardwired action
- an automated variant of that is an the optional user script minclrgap from edakrill
- use the poly-side clearance enforcement method: set the polygons enforce_clearance to non-zero and it will automatically make sure the minimum clearance for any object is at least the value set in enforce_clearance (without changing any object's clearance field); This is available from lihata board v7.
Thus MinClearGap() is a dummy action in the oldactions plugin.
gsch2pcb-rnd
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:
- For imports coordinated from scripts or Makefiles, there is a howto describing the fewliner that can replace gsch2pcb-rnd; the user experience is pretty much unchanged.
- The same setup, but using tEDAx instead of the action script: generating the action script with gnetlist introduced an unstable tie between the projects. Lepton for example lately broke API compatibility and the gnetlist backend script that would produce the cmd file stopped working. tEDAx is supported by both gschem and lepton and is an independent file format that doesn't assume either project knowing the internals of the other project. At the end the user experience is the same, but the file format and workflow is much more stable in time.
- Use the import schematics feature with the gschem schematics import format (will probably fail with lepton). This is the pcb-rnd driven version of the flow. Can be used from both GUI and CLI. Can be run from a Makefile.
- Use the import schematics feature with the external command (cmd) import format and specify a gnetlist or lepton-netlist command line that produces a tEDAx netlist.
c-pcb
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:
- use the built-in router
- use freerouting.net
- find and use an alternative external router (let me know if you find a good one and I will write the plugin for hooking it up)
- fork c-pcb and fix it up (replace file format with tEDAx, implement partial routing and fix up the docs)
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).
Solution:
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:
- {l t} is written as: <Key>l;<Key>t
- {l ctrl+w} is written as: <Key>l;Ctrl<Key>w
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.
Conclusion:
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:
- I will code an extended object, probably called pour, that will take over the role of the fullpoly flag. It will be somewhat similar to the full poly thing, except that it will really create and maintain separate polygon objects for the islands, removing a huge complication from the code (by allowing all parts of the code to assume one object is one object). With this, you will get about the same functionality as with full poly today, except it won't suffer from connectivity bugs.
- I also have plans about a minor data model upgrade to support polygon-side clearance values; this would help us a lot in compatibility to EDA tools that really matter on the market (eagle and kicad) as it would help us reproduce their global or "zone" based clearance mechanism. I already know how to do this cheap and without breaking any compatibility with our current data model.
- In the same time I will mark the fullpoly flag deprecated. This means whenever pcb-rnd meets it, a warning will be thrown and a link to 'how to switch to the pour extended object' will be included.
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:
- there will be a pool node about how to use the new gfx feature
- old pool nodes will need to be updated
- after a transition period --bg-image and the bg_image conf node will be removed together with the HID code
Renumber(), RenumberBlock() and RenumberBuffer()
The renumber plugin is 321 sloc long and offers three actions for renumbering subcircuit refdes':
- Renumber() tries to renumber the refdes of all non-locked subcircuits on the board, from 1 for each letter-prefix, and tries to save a back annotation file in a format that nothing loads; renumbering is ordered by subcircuit centers
- RenumberBlock() renumbers selected subcircuits using explicit from-to starting numbers specified by the user (no back annotation is attempted)
- RanumberBuffer() is the same as RenumberBlock(), but operates on the current buffer instead of the board
This plugin has the following problems:
- writes unspecified, unusable file format for back annotation
- not all three actions deal with back annotation
- no GUI is provided
- the implementation is broken (undo bugs and segfaults) but nobody reported any bug which suggests nobody is really using these actions
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.