| ID: | 194 |
| From: | James Battat <jb...@wellesley.edu> |
| Date: | Mon, 5 Dec 2016 08:06:38 -0500 |
| Subject: | Re: Layer rewrite new (was: Re: [pcb-rnd] gerber output names have |
| in-reply-to: | 193 from ge...@igor2.repo.hu |
| replies: | 195 from ge...@igor2.repo.hu |
--001a113f9d3051095e0542e8f5e2 Content-Type: text/plain; charset=UTF-8 Thanks for the update on this. If the fix will take time, can you recommend an svn rev number that is before this bug, I need to send Gerbers out today. Also from now on I should be more careful when updating to HEAD. Do you have a recommended way to have both a known good copy and HEAD available in my machine? Many thanks, James On Dec 5, 2016 2:05 AM, <gedau@igor2.repo.hu> wrote: > > > On Sun, 4 Dec 2016, James Battat wrote: > > After updating to svn HEAD, I now get different names for three of the >> gerber output files. >> >> By looking at the gerbers in gerbv (see attached screen grab): >> group1.gbr is the bottom copper layer. >> group0.gbr looks like the top cooper layer. >> group2.gbr looks like a subset of group0 >> >> In the previous pcb-rnd version that I was using (not sure exactly what >> the version was, sorry), the gerber names for top and bottom layers were: >> top.gbr >> bottom.gbr >> and there was no corresponding file for what is now group2.gbr. >> The other gerber filenames have not changed (bottom mask, outline, >> topmast, topsilk, etc etc.) >> >> I don?t understand why the gerber names changed from version to version >> (but it makes problems for workflows like my makefile that renames the >> pcb-rnd gerbers to match what OSHPark.com expects). >> I also don?t know why the top copper layer appears in both group0 and >> group2?. >> Can I safely ignore group2.gbr? >> >> I?ve attached a screen grab of the pcb-rnd layer groups for this board >> (as well as the .pcb file itself). >> >> > > Thanks, this is a bug. It got introduced a few days ago, during the layer > rewrite (see below). I'm working on fixing it, it'll take some time. > > Layer news > ~~~~~~~~~~ > > I'm in the middle of an almost total rewrite of the layer support. The > goal is to remove various assumptions that the original code had hardwired > _repeatedly_ in most exporters and core. These assumptions limit what we > can do with our layers without breaking everything immediately (see later). > They also make the code unreadable and hard to maintain. Like if you know > you have 4 copper layers, indexed 0..3, why do you address layer 5? > > (Because the code assumes there will be two extra silk layers right after > the copper layers. Which means you can't have more or less than 2 silks. > Then one would think the same happens to top/bottom mask or paste layers, > following the silks, but no, those are handled totally differently.) > > These assumptions sort layers in two classes: the "copper" layers > (including silks and outline layers!) and everything else (mask, paste, > fab, drill, "the other side" layers). Instead of taking a layer as a layer, > the code tries to do random strange things depending on whether it thinks > the given layer is "copper" or not. Determining this sometimes need the > layer index, sometimes the user editable layer name (!), sometimes the > magic bits in the layer group index. Then if someone wanted to loop over > all layers, it had to be done differently for "copper" and "non-copper" > layers. Layer groups behaved differently per class too. The physical > location of the layers, especially silk, mask and paste are not really > stored, just assumed. > > It's a mess. One can feel all the historical layers of code built up > slowly in the spirit of "let's hack this in without having to clean this > up" over the decades. By now we really reached a point where we have to > bite the bullet and clean it up before we can proceed. > > Current state and plans > ~~~~~~~~~~~~~~~~~~~~~~~ > > The first step was to provide a new, simpler, more uniform and more > flexible layer API in core. This API present all layers as equal, generic > canvases, with a set of type bits that tells where the layer is and what's > on the layer (e.g. "copper" on "top side", "silk" on "bottom side", > "outline" (no side)). This also cleared up the terminolog about layers, > layer groups and their relation to physical layers (remember how much > criticism PCB gets for this on geda-user@). This is all done by now. > > The second step (I am doing currently), is rewriting the calls to use the > new API. At the end of this step we will have all the code doing exactly > the same as before, but without random assumptions. All layer-related > knowledge groupped in a single spot in core. We are about 1/3 into this > effort. Until we finish, I expect to see such layer-related bugs. I plan to > finish this within a week. > > The third step that we can do after all those above, is the exciting one: > we can extend the layer support without breaking anything. This means: > > - real physical layers: thickness, material, explicit substrate layers > (sort of required for FEM, but making these explicit will help with > anything more complex than 2 sided hobby boards) - this is a low hanging > fruit > > - support for extra custom layers (comment layer, adhesive, multiple silks > e.g. for multiple colors) - another low hanging fruit > > - we will be able to think about explicit, user editable mask and paste > layers (or even editable fab or assy layers!) > > - easier implemention of blind&buried vias > > Regards, > > Igor2 > > > --001a113f9d3051095e0542e8f5e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Thanks for the update on this.=C2=A0 If the fix will take= time, can you recommend an svn rev number that is before this bug, I need = to send Gerbers out today. =C2=A0 Also from now on I should be more careful= when updating to HEAD.=C2=A0 Do you have a recommended way to have both a = known good copy and HEAD available in my machine?<div dir=3D"auto"><br></di= v><div dir=3D"auto">Many thanks,</div><div dir=3D"auto">James</div></div><d= iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Dec 5, 2016 2:05= AM, <<a href=3D"mailto:gedau@igor2.repo.hu">gedau@igor2.repo.hu</a>>= ; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> <br> On Sun, 4 Dec 2016, James Battat wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> After updating to svn HEAD, I now get different names for three of the gerb= er output files.<br> <br> By looking at the gerbers in gerbv (see attached screen grab):<br> =C2=A0group1.gbr is the bottom copper layer.<br> =C2=A0group0.gbr looks like the top cooper layer.<br> =C2=A0group2.gbr looks like a subset of group0<br> <br> In the previous pcb-rnd version that I was using (not sure exactly what the= version was, sorry), the gerber names for top and bottom layers were:<br> =C2=A0top.gbr<br> =C2=A0bottom.gbr<br> and there was no corresponding file for what is now group2.gbr.<br> The other gerber filenames have not changed (bottom mask, outline, topmast,= topsilk, etc etc.)<br> <br> I don?t understand why the gerber names changed from version to version (bu= t it makes problems for workflows like my makefile that renames the pcb-rnd= gerbers to match what OSHPark.com expects).<br> I also don?t know why the top copper layer appears in both group0 and group= 2?.<br> Can I safely ignore group2.gbr?<br> <br> I?ve attached a screen grab of the pcb-rnd layer groups for this board (as = well as the .pcb file itself).<br> <br> </blockquote> <br> <br> Thanks, this is a bug. It got introduced a few days ago, during the layer r= ewrite (see below). I'm working on fixing it, it'll take some time.= <br> <br> Layer news<br> ~~~~~~~~~~<br> <br> I'm in the middle of an almost total rewrite of the layer support. The = goal is to remove various assumptions that the original code had hardwired = _repeatedly_ in most exporters and core. These assumptions limit what we ca= n do with our layers without breaking everything immediately (see later). T= hey also make the code unreadable and hard to maintain. Like if you know yo= u have 4 copper layers, indexed 0..3, why do you address layer 5?<br> <br> (Because the code assumes there will be two extra silk layers right after t= he copper layers. Which means you can't have more or less than 2 silks.= Then one would think the same happens to top/bottom mask or paste layers, = following the silks, but no, those are handled totally differently.)<br> <br> These assumptions sort layers in two classes: the "copper" layers= (including silks and outline layers!) and everything else (mask, paste, fa= b, drill, "the other side" layers). Instead of taking a layer as = a layer, the code tries to do random strange things depending on whether it= thinks the given layer is "copper" or not. Determining this some= times need the layer index, sometimes the user editable layer name (!), som= etimes the magic bits in the layer group index. Then if someone wanted to l= oop over all layers, it had to be done differently for "copper" a= nd "non-copper" layers. Layer groups behaved differently per clas= s too. The physical location of the layers, especially silk, mask and paste= are not really stored, just assumed.<br> <br> It's a mess. One can feel all the historical layers of code built up sl= owly in the spirit of "let's hack this in without having to clean = this up" over the decades. By now we really reached a point where we h= ave to bite the bullet and clean it up before we can proceed.<br> <br> Current state and plans<br> ~~~~~~~~~~~~~~~~~~~~~~~<br> <br> The first step was to provide a new, simpler, more uniform and more flexibl= e layer API in core. This API present all layers as equal, generic canvases= , with a set of type bits that tells where the layer is and what's on t= he layer (e.g. "copper" on "top side", "silk"= on "bottom side", "outline" (no side)). This also clea= red up the terminolog about layers, layer groups and their relation to phys= ical layers (remember how much criticism PCB gets for this on geda-user@). = This is all done by now.<br> <br> The second step (I am doing currently), is rewriting the calls to use the n= ew API. At the end of this step we will have all the code doing exactly the= same as before, but without random assumptions. All layer-related knowledg= e groupped in a single spot in core. We are about 1/3 into this effort. Unt= il we finish, I expect to see such layer-related bugs. I plan to finish thi= s within a week.<br> <br> The third step that we can do after all those above, is the exciting one: w= e can extend the layer support without breaking anything. This means:<br> <br> - real physical layers: thickness, material, explicit substrate layers (sor= t of required for FEM, but making these explicit will help with anything mo= re complex than 2 sided hobby boards) - this is a low hanging fruit<br> <br> - support for extra custom layers (comment layer, adhesive, multiple silks = e.g. for multiple colors) - another low hanging fruit<br> <br> - we will be able to think about explicit, user editable mask and paste lay= ers (or even editable fab or assy layers!)<br> <br> - easier implemention of blind&buried vias<br> <br> Regards,<br> <br> Igor2<br> <br> <br> </blockquote></div></div> --001a113f9d3051095e0542e8f5e2--
Reply subtree:
194 Re: Layer rewrite new (was: Re: [pcb-rnd] gerber output names have from James Battat <jb...@wellesley.edu>
195 Re: Layer rewrite new (was: Re: [pcb-rnd] gerber output names have from ge...@igor2.repo.hu
197 Re: Layer rewrite new (was: Re: [pcb-rnd] gerber output names have changed after svn up) from James Battat <jb...@wellesley.edu>
201 Re: Layer rewrite new (was: Re: [pcb-rnd] gerber output names have from ge...@igor2.repo.hu
198 [pcb-rnd] Re: Layer rewrite new from John Griessen <jo...@cibolo.com>