Mail Archives: geda-user/2015/10/04/18:34:04.1
On Sun, 2015-10-04 at 13:16 -0800, Britton Kerin (
britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
[...]
> Well I thought it was all really exciting, but it wasn't obvious how it
> could be integrated with pcb (being in Ruby). But now some serious efforts
> are being considere to make a much more accessible file format (via sql and
> YAML) so it could be provided as a stand-alone tool that would be useful to
> pcb users.
>
If the router could route all traces, we could simply import the traces.
That is what I did for the example picture. Better is a very basic GUI
tool, where we can move elements and grab rubberbands and move them.
>
> > > People seem to prefer manually routing, and many seem to not like
> > > curved traces.
> > >
> > > I do not really understand your term "intra-layer". My router is using
> > > arbitrary numbers of layers, and it connect the layers with
> > > automatically placed vias. Testing was done with two layers. I have
> > > some problems remembering details, have not touched it for more than
> > > too years. I think no crashes. The problem is, that there can remain
> >
>
> Great! I had the impression from pics on your site and something Kai said
> that just the rubber band part was done.
The layer assignment was described in detail in the thesis, it was easy
coding that, and it works not bad. But there is room for improvement,
but I forgot details. But I think I will be able to remember when I work
again on that.
>
>
> > > unrouted traces due to space constraints. So some user interaction
> > > would be needed, for example for moving parts. Coding that part would
> > > be the fastest way to make that router useful, but coding that part is
> > > not really much fun and take some time. And when no one is interested
> > > at all? Making the router working without user interaction may be more
> > > interesting, that would include moving components. But that is more
> > > difficult and would need some time for coding.
> >
>
> I take it the remaining traces are really hard to subsequently add by
> hand? Are there options other than moving parts to make is useful, maybe
> somehow less ambitious or cost function rewards "ports" or something?
Importing the traces in PCB program and then fixing it would be
generally possible, but not really nice. When we have curved traces from
autorouter, we generally do not want some straight manually inserted
once. For the example pictures I have painted the missing unrouted
traces in white color, you can see that generally manually fixing is not
hard -- insert some vias, rearrange some traces. But a tool that can
handle rubberbands well would be nice for that.
Another unsolved task is feeding trace parameters like trace width and
clearance into the router. Generally that is not equal for all traces.
My initial idea was taking these parameters from the schematic, but an
editing option for the router would be fine, which may need GUI support.
>
>
> > > But I think I will continue at some time. The code is easy, short, and
> > > mostly based on that PhD thesis. But I have never cleaned it up
> > > unfortunately, and for latest CGAL and Ruby 2.2 some fixes may be
> > > necessary. Porting to Nim would be nice, but for that I would have to
> > > create bindings for CGAL first. Porting to C++ would be an option too
> > > of course, then I need no CGAL bindings, and integration in PCB program
> > > is easier. But that would be no fun for me.
> >
>
> I would rather it stay Ruby, rather than be ported to any of those other
> things. In addition to not being fun it would make it less accessible I
> think. I looked at the Ruby at the time and it seemed quite nice.
Ruby seems to be not that popular any more, most people prefer Python
now. With Nim the code would look similar nice, but speed would be at
least ten times faster. Routing the demos took a few seconds in Ruby,
but for really large boards speed can become important.
>
>
> > >
> > > Have you ever looked at the code of Anthony's toporouter? I tried a few
> > > hours in 2012 and early 2013, but really understood nearly nothing.
> >
>
> I tried yes. Your Ruby is far more readable and maps much more clearly to
> the thesis.
Yes, I have seen nearly no relations between his code and the thesis or
other papers :-(
>
>
> > > Maybe you can -- there may exists some really smart ideas in his code.
> >
>
> Like what?
Well, his router was working fine for his small example boards. So when
he not really followed papers, he may have implemented some own good
ideas?
- Raw text -