Mailing list archives : pcb-rnd

Date:Mon, 27 Jul 2020 11:17:06 +0200 (CEST)
Subject:[pcb-rnd] project state update + external autorouters
Hi all,
weve switched from cleanup to feature development phase. During the 
cleanup I've made good progress with the librnd separation and the menu 
system upgrade for more modularity.
In the feature dev phase there are two smallish features on the TODO, and 
other than that I am cocnetrating on route-rnd, our external autorouter.
More about the autorouter and how this effort will make pcb-rnd _smaller_:
I know, I know, you don't want to use an autorouter at all. At least, 
according to my informal surveys, I am perfectly aware of the fact that 
majority of pcb-rnd users don't want to use an autorouter, and even those 
who can imagine to use one prefers something closer to assisted routing 
(e.g. push & shove).
Maybe it sounds a bit wierd, but at the end the main benefit of having our 
own (external) autorouter will help us cleaning up the code and have less 
legacy/historical/junk in pcb-rnd regarding to the largely 
unwanted autorouting feature! Rationale:
1. We have a built-in router, the original one, from the early 2000s; by 
now this is only half-working. But if we are honest, it was never really 
fully working even in geda/pcb: I learned the hard way that it didn't 
really handle diagonal lines (or even arcs), so even the rat drawing code 
had to had ugly workarounds that made rats less optimal for 
non-autorouter-users as well; and then the resulting routed tracks are so 
bad that we have the djopt plugin pretty much dedicated to clean it up 
using local optimization.
2. We have bridges to external autorouters, but non of them are good 
enough that I'd safely recommend new users to use them. We have one to, which is a java app (for many that just means "PITA to 
run"); we have a bridge to c-pcb which is small and easier to run, but is 
half-finished and I lost hope that it would ever get to the level we need.
3. We used to have a toporouter by Anthony, which was also half-finished, 
depended on a local fork of a large triangulation lib and had zero chance 
that anyone would ever touch it again. I got rid of this one long ago.
4. We have a few, currently defunct or half finished or abandoned assisted 
routing tries (acompnet, skroute, jostle). In a more generic sense I 
regard these as autorouters too.
So we have a lot of code, but not a single real good, well working 
solution. After reading a lot in the topic of autorouting, including geo 
based routers and topological routers, I am very confident that 
autorouting is a problem too big to simply fit within pcb-rnd. Plus I am 
also sure that all the complex data model and infra in pcb-rnd is 
suboptimal for autorouters. It's because pcb-rnd is a PCB editor, so it 
has to deal with tons if tiny details related to fabbing and footprints 
and parts and metadata. For autorouters, this is pure noise. So they 
either go and rebuild the whole board in a simpler model, or they go on 
constantly implementing workarounds and ignores for the fab-related 
At least that's when you have an internal autorouter plugin. With an 
external autorouter solution pcb-rnd exports the parts of the data 
model that are relevant to the autorouting and the router deals only with 
The plan is (part of the NGI0):
1. I've specified a tEDAx file format for communicating from a PCB editor 
to an autorouter, and back
2. I am now building the main infra of route-rnd, a stand-alone 
modular autorouter, working with this format
3. I am implementing a very simple router algorithm plugin that works with 
2+ layers, having horizontal-only or vertical-only wiring on each layer; 
this one will be usable when you have a few, sparsely placed parts and 
board space and via cost are non-issues; typical for simple arduino 
shields; typical for those where our original autorouter or c-pcb also 
worked. But although it would result in an autorouter usable for those 
simple cases, the main goal is rather that I have something I can finish 
and test the whole infra with
4. during my research I found a few easy-to-implement algorithms for 
simple geometric routing. I may try to implement one of those too.
5. Then I can sit down and rewrite the topological autorouter within 
route-rnd. When I'm finished, I hope we will have something that's an 
alternative to Although it will probably take many years 
to catch up with them, I hope it would be a bit better than the original 
geda/pcb toporouter or the built-in autorouter plugin we have now.
6. Once we have the toporouter working within route-rnd, I will start 
removing the old junk from pcb-rnd. And that's the main goal of the whole 
thing: to refactor things and separate the 
huge/complicated/not-really-fitting-in autorouting topic from pcb-rnd to 
external code. So I'd fully remove the current autorouter, and the 
half-finished assisted routing plugins, and the c-pcb bridge too. The 
dedicated bridge would be removed too, because by then 
we'd have a real complete io_dsn that could be used for the same.
7. Long term I _think_ assisted routing will fit more into route-rnd than 
pcb-rnd too, and we would have an optional real-time link between the two 
for this purpose.
So at the end we will have smaller, simpler pcb-rnd. For those who don't 
ever want to use autorouting this is already a benefit, a lot of 
half-working and/or never used code removed. For those who use 
autorouting, the new setup will not make a big difference in how 
autorouting is done on the user level, but hopefully will improve the 
quality of the routing. 
And for those who want push&shove, I know a lot of users want that, while 
I am going through all these, I hope I will learn enough of topology and 
routing that I will be in a good position to finally sit down and solve 
that after this effort.
Best regards,

Reply subtree:
4266 [pcb-rnd] project state update + external autorouters from