Mailing list archives : pcb-rnd

ID:3123
From:Anthony Tuttle <ke...@gmail.com>
Date:Sat, 8 Jun 2019 10:14:18 -0500
Subject:Re: [pcb-rnd] project state + camv-rnd progress
in-reply-to:3120 from ge...@igor2.repo.hu
replies: 3124 from ge...@igor2.repo.hu
--0000000000004a22af058ad1672f
Content-Type: text/plain; charset="UTF-8"
 
I have wanted a gerber viewer that can render PCBs in more photorealistic
colors so it's easier to understand what I'm looking at and compare with a
physical board. Would it be able to do this?
 
On Sat, Jun 8, 2019 at 5:35 AM <gedau@igor2.repo.hu> wrote:
 
> Hi all,
>
> for a week I worked on camv-rnd and I have the first results to show.
>
> 1. what is camv-rnd?
>
> It will be the viewer of our -rnd suite, capable of opening any file you'd
> normally send to a fab to get your pcb professionally made. This would
> include:
>
>  - gerbers
>
>  - drill files (gerber or excellon)
>
>  - IPC-D-356 (needed for automatic electronic testing)
>
>  - one dialect of p&p files (needed for assembly)
>
> Furthermore we could long temr support a few other formats that are also
> supported by pcb-rnd on the import side, e.g. HPGL.
>
>
> 2. Why do we need a new tool? Isn't gerbv good?
>
> Gerbv is generally good, but:
>
>  - gerbv development generally stalled lately
>
>  - ... and even when it was going, it was not in par with pcb-rnd on speed
>
>  - I have a plan about getting genxproj into production state and make our
> ecosystem more affecting for Eagle users who are planning to switch; for
> that I need some ecosystem related features implemented in the gerber
> viewer, which doesn't seem to happen in gerbv any time soon
>
>  - gerbv depends on gtk, glib and 2.7.0 even has c++ parts - which means
> there are hosts where pcb-rnd runs fine, but gerbv is either hard or
> impossible to compile.
>
>  - gerbv uses a autotools
>
> So after looking at the source, considering all options, I decided it's
> cheaper to write one from sratch.
>
> Camv-rnd is building on the same infra pcb-rnd uses, so multiple
> HIDs, no hardwired glib dependency, no autotools - so it's a bit more
> portable. At the end, when it's ready for production it will generally run
> on any system pcb-rnd runs on (which will definitely include C89 systems
> without glib, gtk, c++ compiler, etc).
>
> I also want to provide a strong CLI support, including being able to
> compile camv-rnd without GUI (using the batch HID) for automated exports,
> including command line within the GUI, including fungw scripting.
>
>
> 3. When?
>
> We already have a testable versions (for real hardcore users), but it's
> very far from being usable. I started with the hardest parts and they are
> done: booted the hidlib, got camv-rnd GUI and basic infra up based on the
> hidlib, wrote a gerber parser and a gerber state machine that can render
> the files into objects I can display.
>
> I expect we'd have the first version that is somewhat easy to compile and
> test within 2 pcb-rnd cycles after the next release. But this part depends
> more on pcb-rnd (and pcb-rnd's hidlib) releases than on camv-rnd.
>
> After that we'll probably need to run some beta test period using real
> board data and if it's not more broken than other gerber viewers out
> there, we can make a stable release.
>
> If everything goes well, this stable release could happen next year. A lot
> depends on _coordinated_ user testing.
>
>
>
> 4. Wait, what's -rnd? And the suite and ecosystem?
>
> Imagine it as an onion.
>
> The innermost group of software is our EDA suite, which at the moment
> consists of pcb-rnd and genxproj. camv-rnd joins here and later on, when I
> have the time to write cschem, that will join here too. The suite share
> developers/users and a lot of concepts and code. However, this does not
> mean these programs are integrated in any way or you have to use them all
> together. They are all replacable. Since pcb-rnd's name ends in -rnd, and
> nobody had a better idea, I decided to start naming the whole suite rnd -
> but there'll be another mail about this.
>
> Then the next layer around this is the 'tight ring' of the coralEDA (the
> ecosystem) - tools that are not part of the suite, but are closely
> related. These tools work very well together with our suite and other
> coralEDA projects, but they do have different developers following
> different concepts along different choices. Xschem for example is heading
> to the tight ring: it does a lot for supporting features we need for
> coralEDA.
>
> Then the outmost layer around this all is the 'loose ring' of coralEDA,
> where we have tools that work together with the rest of the ecosystem
> tools to some degree, but are not actively trying to join the 'tight
> ring'. Gerbv for example is in the loose ring.
>
> Regards,
>
> Igor2
>
>
 
--0000000000004a22af058ad1672f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 
<div dir=3D"ltr">I have wanted a gerber viewer that can render PCBs in more=
 photorealistic colors so it&#39;s easier to understand what I&#39;m lookin=
g at and compare with a physical board. Would it be able to do this?</div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat,=
 Jun 8, 2019 at 5:35 AM &lt;<a href=3D"mailto:gedau@igor2.repo.hu">gedau@ig=
or2.repo.hu</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Hi all,<br>
<br>
for a week I worked on camv-rnd and I have the first results to show.<br>
<br>
1. what is camv-rnd?<br>
<br>
It will be the viewer of our -rnd suite, capable of opening any file you&#3=
9;d <br>
normally send to a fab to get your pcb professionally made. This would <br>
include:<br>
<br>
=C2=A0- gerbers<br>
<br>
=C2=A0- drill files (gerber or excellon)<br>
<br>
=C2=A0- IPC-D-356 (needed for automatic electronic testing)<br>
<br>
=C2=A0- one dialect of p&amp;p files (needed for assembly)<br>
<br>
Furthermore we could long temr support a few other formats that are also <b=
r>
supported by pcb-rnd on the import side, e.g. HPGL. <br>
<br>
<br>
2. Why do we need a new tool? Isn&#39;t gerbv good?<br>
<br>
Gerbv is generally good, but:<br>
<br>
=C2=A0- gerbv development generally stalled lately<br>
<br>
=C2=A0- ... and even when it was going, it was not in par with pcb-rnd on s=
peed<br>
<br>
=C2=A0- I have a plan about getting genxproj into production state and make=
 our <br>
ecosystem more affecting for Eagle users who are planning to switch; for <b=
r>
that I need some ecosystem related features implemented in the gerber <br>
viewer, which doesn&#39;t seem to happen in gerbv any time soon<br>
<br>
=C2=A0- gerbv depends on gtk, glib and 2.7.0 even has c++ parts - which mea=
ns <br>
there are hosts where pcb-rnd runs fine, but gerbv is either hard or <br>
impossible to compile.<br>
<br>
=C2=A0- gerbv uses a autotools<br>
<br>
So after looking at the source, considering all options, I decided it&#39;s=
 <br>
cheaper to write one from sratch.<br>
<br>
Camv-rnd is building on the same infra pcb-rnd uses, so multiple <br>
HIDs, no hardwired glib dependency, no autotools - so it&#39;s a bit more <=
br>
portable. At the end, when it&#39;s ready for production it will generally =
run <br>
on any system pcb-rnd runs on (which will definitely include C89 systems <b=
r>
without glib, gtk, c++ compiler, etc).<br>
<br>
I also want to provide a strong CLI support, including being able to <br>
compile camv-rnd without GUI (using the batch HID) for automated exports, <=
br>
including command line within the GUI, including fungw scripting.<br>
<br>
<br>
3. When?<br>
<br>
We already have a testable versions (for real hardcore users), but it&#39;s=
 <br>
very far from being usable. I started with the hardest parts and they are <=
br>
done: booted the hidlib, got camv-rnd GUI and basic infra up based on the <=
br>
hidlib, wrote a gerber parser and a gerber state machine that can render <b=
r>
the files into objects I can display.<br>
<br>
I expect we&#39;d have the first version that is somewhat easy to compile a=
nd <br>
test within 2 pcb-rnd cycles after the next release. But this part depends =
<br>
more on pcb-rnd (and pcb-rnd&#39;s hidlib) releases than on camv-rnd.<br>
<br>
After that we&#39;ll probably need to run some beta test period using real =
<br>
board data and if it&#39;s not more broken than other gerber viewers out <b=
r>
there, we can make a stable release.<br>
<br>
If everything goes well, this stable release could happen next year. A lot =
<br>
depends on _coordinated_ user testing.<br>
<br>
<br>
<br>
4. Wait, what&#39;s -rnd? And the suite and ecosystem?<br>
<br>
Imagine it as an onion.<br>
<br>
The innermost group of software is our EDA suite, which at the moment <br>
consists of pcb-rnd and genxproj. camv-rnd joins here and later on, when I =
<br>
have the time to write cschem, that will join here too. The suite share <br=
>
developers/users and a lot of concepts and code. However, this does not <br=
>
mean these programs are integrated in any way or you have to use them all <=
br>
together. They are all replacable. Since pcb-rnd&#39;s name ends in -rnd, a=
nd <br>
nobody had a better idea, I decided to start naming the whole suite rnd - <=
br>
but there&#39;ll be another mail about this.<br>
<br>
Then the next layer around this is the &#39;tight ring&#39; of the coralEDA=
 (the <br>
ecosystem) - tools that are not part of the suite, but are closely <br>
related. These tools work very well together with our suite and other <br>
coralEDA projects, but they do have different developers following <br>
different concepts along different choices. Xschem for example is heading <=
br>
to the tight ring: it does a lot for supporting features we need for <br>
coralEDA.<br>
<br>
Then the outmost layer around this all is the &#39;loose ring&#39; of coral=
EDA, <br>
where we have tools that work together with the rest of the ecosystem <br>
tools to some degree, but are not actively trying to join the &#39;tight <b=
r>
ring&#39;. Gerbv for example is in the loose ring.<br>
<br>
Regards,<br>
<br>
Igor2<br>
<br>
</blockquote></div>
 
--0000000000004a22af058ad1672f--
 

Reply subtree:
3123 Re: [pcb-rnd] project state + camv-rnd progress from Anthony Tuttle <ke...@gmail.com>
  3124 Re: [pcb-rnd] project state + camv-rnd progress from ge...@igor2.repo.hu