| ID: | 193 |
| From: | ge...@igor2.repo.hu |
| Date: | Mon, 5 Dec 2016 08:09:38 +0100 (CET) |
| Subject: | Layer rewrite new (was: Re: [pcb-rnd] gerber output names have |
| in-reply-to: | 191 from James Battat <jb...@wellesley.edu> |
| replies: | 194 from James Battat <jb...@wellesley.edu> |
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
Reply subtree:
193 Layer rewrite new (was: Re: [pcb-rnd] gerber output names have from ge...@igor2.repo.hu
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>