From @kliment on Fri Feb 09 2018 06:38:32 GMT+0000 (UTC)
Having reviewed the code and horizon’s integration, this should be quite easy to add and gives a lot of useful functionality. If nobody objects, I’d like to start work on it as soon as the board editor is in a usable state.
Copied from original issue: https://github.com/LibrePCB/librepcb-rfcs/issues/1
From @ubruhin on Sat Feb 10 2018 23:40:42 GMT+0000 (UTC)
Yes, that would be great. Do you know if the router also supports a very simple routing mode which just creates the traces where the user clicks, without any obstacle detection and so on? I mean, similar to the “router” which is currently implemented in LibrePCB. If so, we could completely remove our own router and replace it by the kicad router.
Btw, If you have some links to code and/or documentation of the kicad router, could you post them here so we have quick access to the most important information?
From @dbrgn on Thu Feb 15 2018 09:37:20 GMT+0000 (UTC)
> Do you know if the router also supports a very simple routing mode which just creates the traces where the user clicks, without any obstacle detection and so on?
Yes, I think so. The interactive router has three modes:
If you use “highlight collisions”, then no obstacle avoidance is being done.
From @ubruhin on Wed Aug 08 2018 21:17:22 GMT+0000 (UTC)
I started a first attempt with KiCads PNS router, just to get a first impression how much effort is required to integrate it. Still hard to say, but at least I already had a first “hurray”-effect
The code is hacky and buggy like hell, and it doesn’t work at all (nothing gets really connected), but I still like it already
From @ubruhin on Wed Aug 08 2018 21:24:38 GMT+0000 (UTC)
Oh, I just (re?)read your comment @kliment
If nobody objects, I’d like to start work on it as soon as the board editor is in a usable state.
What do you mean with “usable state”? And are you still interested in working on this?
Actually I wonder whether I should properly implement the current routing tool to make it usable or it’s better to completely replace the current routing tool with the PNS router. If the PNS router also supports a simple routing mode, and the effort to integrate it is similar to the effort needed for improving the current router, then it would make sense to directly integrate the PNS router…
From @dbrgn on Thu Aug 09 2018 08:36:43 GMT+0000 (UTC)
Woahh, that is fantastic! I didn’t expect an initial integration attempt that fast
Actually I wonder whether I should properly implement the current routing tool to make it usable or it’s better to completely replace the current routing tool with the PNS router. If the PNS router also supports a simple routing mode, and the effort to integrate it is similar to the effort needed for improving the current router, then it would make sense to directly integrate the PNS router…
I really like the Kicad router, so I’d be for that.
From @rnestler on Mon Aug 13 2018 08:11:27 GMT+0000 (UTC)
> I started a first attempt with KiCads PNS router, just to get a first impression how much effort is required to integrate it. Still hard to say, but at least I already had a first “hurray”-effect smiley
Do you have this initial version on some branch?
From @ubruhin on Mon Aug 13 2018 17:33:53 GMT+0000 (UTC)
> Do you have this initial version on some branch?
Yes: https://github.com/LibrePCB/LibrePCB/tree/add-pns-router
From @dbrgn on Mon Aug 13 2018 17:58:12 GMT+0000 (UTC)
Since at least 3 projects use this router now (KiCAD, Horizon, LibrePCB) it might be interesting to extract it into a separate repository.
Maybe we could suggest this to the original authors once the PoC is done.
From @ubruhin on Mon Aug 13 2018 18:02:41 GMT+0000 (UTC)
> Since at least 3 projects use this router now (KiCAD, Horizon, LibrePCB) it might be interesting to extract it into a separate repository.
Yes, that would really be great!
Maybe we could suggest this to the original authors once the PoC is done.
Or even now, I don’t see a reason why to wait
Someone interested to do it? @kliment?
From @kliment on Mon Aug 13 2018 18:04:22 GMT+0000 (UTC)
The original authors are CERN, as part of the KiCad project. Since they’re in the middle of their most important release ever I doubt this is a good time to ask them to do major code base restructuring.
From @dbrgn on Mon Aug 13 2018 18:12:47 GMT+0000 (UTC)
That’s not a major code base restructuring. The router is quite standalone, so it shouldn’t be too hard to extract it into a separate repository.
I’ll take a look if I find a developer forum or mailing list to ask
From @kliment on Mon Aug 13 2018 18:18:18 GMT+0000 (UTC)
The people in charge of the PnR are Tomasz Wlostowski tomasz.wlostowski@cern.ch and Maciej Suminski maciej.suminski@cern.ch
From @dbrgn on Mon Aug 13 2018 19:51:31 GMT+0000 (UTC)
@kliment thanks!
From @dbrgn on Wed Aug 15 2018 22:56:03 GMT+0000 (UTC)
Reply: At the moment they’re not interested in extracting the code into a standalone library. That’s fine, we can simply copy the router (it’s GPLv3+ licensed).
From @ubruhin on Thu Aug 16 2018 06:25:01 GMT+0000 (UTC)
IMHO it was pretty clear that they are not interested in extracting the code Horizon and LibrePCB would have much more benefit, so basically it’s our job to create such a library. And if we do it well (I think about CI with many compilers, and even unit/integration tests for the router), KiCad developers may still be interested some time in future to use the standalone library instead of their own copy.
So it would be great if someone would start creating such a standalone library
From @rnestler on Mon Oct 29 2018 11:54:27 GMT+0000 (UTC)
> So it would be great if someone would start creating such a standalone library
I can give it a try. I’ll do it in my personal GitHub account first, we can then still move it to some organization if needed.
From @ubruhin on Mon Oct 29 2018 22:24:00 GMT+0000 (UTC)
> I can give it a try. I’ll do it in my personal GitHub account first, we can then still move it to some organization if needed.
Nice!
@rnestler What’s the state of this?
Hi, is there any progression on that ?