Mail Archives: geda-user/2015/10/04/22:39:09
--001a11c262d82121260521526935
Content-Type: text/plain; charset=UTF-8
On Sun, Oct 4, 2015 at 2:24 PM, Stefan Salewski <mail AT ssalewski DOT de> wrote:
> 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.
>
I think pcb has defaults for these, and saves them in each file also as
overrides. So they could be gotten from an existing pcb file. Or is
making the router implement different parameters the hard part?
> >
> >
> > > > 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.
>
TIOBE showing Ruby still gaining
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
I didn't mind it except it's error message are bad compared to perl (which
desperately needs its smart error messages :).
Carbon cycles are move valuable than silicon cycles, the Ruby
implementation largely exists already, I think there is no reason to feel
bad for not rewriting in any other language.
--001a11c262d82121260521526935
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Oct 4, 2015 at 2:24 PM, Stefan Salewski <span dir=3D"ltr"><<=
a href=3D"mailto:mail AT ssalewski DOT de" target=3D"_blank">mail AT ssalewski DOT de</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex">On Sun, 2015-10-04 at 13:16 -0800, B=
ritton Kerin (<br>
<a href=3D"mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) [vi=
a <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] wrote=
:<br>
<br>
[...]<br>
<span class=3D""><br>
<br>
> Well I thought it was all really exciting, but it wasn't obvious h=
ow it<br>
> could be integrated with pcb (being in Ruby).=C2=A0 But now some serio=
us efforts<br>
> are being considere to make a much more accessible file format (via sq=
l and<br>
> YAML) so it could be provided as a stand-alone tool that would be usef=
ul to<br>
> pcb users.<br>
><br>
<br>
</span>If the router could route all traces, we could simply import the tra=
ces.<br>
That is what I did for the example picture. Better is a very basic GUI<br>
tool, where we can move elements and grab rubberbands and move them.<br>
<span class=3D""><br>
><br>
> > > People seem to prefer manually routing, and many seem to not=
like<br>
> > > curved traces.<br>
> > ><br>
> > > I do not really understand your term "intra-layer"=
. My router is using<br>
> > > arbitrary numbers of layers, and it connect the layers with<=
br>
> > > automatically placed vias. Testing was done with two layers.=
I have<br>
> > > some problems remembering details, have not touched it for m=
ore than<br>
> > > too years. I think no crashes. The problem is, that there ca=
n remain<br>
> ><br>
><br>
> Great!=C2=A0 I had the impression from pics on your site and something=
Kai said<br>
> that just the rubber band part was done.<br>
<br>
</span>The layer assignment was described in detail in the thesis, it was e=
asy<br>
coding that, and it works not bad. But there is room for improvement,<br>
but I forgot details. But I think I will be able to remember when I work<br=
>
again on that.<br>
<span class=3D""><br>
><br>
><br>
> > > unrouted traces due to space constraints. So some user inter=
action<br>
> > > would be needed, for example for moving parts. Coding that p=
art would<br>
> > > be the fastest way to make that router useful, but coding th=
at part is<br>
> > > not really much fun and take some time. And when no one is i=
nterested<br>
> > > at all? Making the router working without user interaction m=
ay be more<br>
> > > interesting, that would include moving components. But that =
is more<br>
> > > difficult and would need some time for coding.<br>
> ><br>
><br>
> I take it the remaining traces are really hard to subsequently add by<=
br>
> hand?=C2=A0 Are there options other than moving parts to make is usefu=
l, maybe<br>
> somehow less ambitious or cost function rewards "ports" or s=
omething?<br>
<br>
</span>Importing the traces in PCB program and then fixing it would be<br>
generally possible, but not really nice. When we have curved traces from<br=
>
autorouter, we generally do not want some straight manually inserted<br>
once. For the example pictures I have painted the missing unrouted<br>
traces in white color, you can see that generally manually fixing is not<br=
>
hard -- insert some vias, rearrange some traces. But a tool that can<br>
handle rubberbands well would be nice for that.<br>
<br>
Another unsolved task is feeding trace parameters like trace width and<br>
clearance into the router. Generally that is not equal for all traces.<br>
My initial idea was taking these parameters from the schematic, but an<br>
editing option for the router would be fine, which may need GUI support.<br=
></blockquote><div><br></div><div style=3D"">I think pcb has defaults for t=
hese, and saves them in each file also as overrides.=C2=A0 So they could be=
gotten from an existing pcb file.=C2=A0 Or is making the router implement =
different parameters the hard part?</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=3D"">><br>
><br>
> > > But I think I will continue at some time. The code is easy, =
short, and<br>
> > > mostly based on that PhD thesis. But I have never cleaned it=
up<br>
> > > unfortunately, and for latest CGAL and Ruby 2.2 some fixes m=
ay be<br>
> > > necessary. Porting to Nim would be nice, but for that I woul=
d have to<br>
> > > create bindings for CGAL first. Porting to C++ would be an o=
ption too<br>
> > > of course, then I need no CGAL bindings, and integration in =
PCB program<br>
> > > is easier. But that would be no fun for me.<br>
> ><br>
><br>
> I would rather it stay Ruby, rather than be ported to any of those oth=
er<br>
> things.=C2=A0 In addition to not being fun it would make it less acces=
sible I<br>
> think.=C2=A0 I looked at the Ruby at the time and it seemed quite nice=
.<br>
<br>
</span>Ruby seems to be not that popular any more, most people prefer Pytho=
n<br>
now. With Nim the code would look similar nice, but speed would be at<br>
least ten times faster. Routing the demos took a few seconds in Ruby,<br>
but for really large boards speed can become important.<br></blockquote><di=
v><br></div><div style=3D"">TIOBE showing Ruby still gaining=C2=A0<a href=
=3D"http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html">http:=
//www.tiobe.com/index.php/content/paperinfo/tpci/index.html</a></div><div s=
tyle=3D"">I didn't mind it except it's error message are bad compar=
ed to perl (which desperately needs its smart error messages :).</div><div =
style=3D"">Carbon cycles are move valuable than silicon cycles, the Ruby im=
plementation largely exists already, I think there is no reason to feel bad=
for not rewriting in any other language.</div></div></div></div>
--001a11c262d82121260521526935--
- Raw text -