On Sun, 17 Feb 2008 19:33:28 -0500 (EST) Stuart Brorson <[EMAIL PROTECTED]> wrote:
> > To move forward with some projects, PCB needs to understand more about > > the physical stackup of the board. Harry mentioned once that the > > drawing layer stack should BE the physical layer stack. I.e. the > > topmost copper layer in the menus should represent the component side > > copper, the next ones the inner planes, and the last one the solder > > side copper. > > > Anyway, does anyone object to this type of change? > > Do it! Sounds great! > > One thing: You forgot to mention layers like silk, outline, solder > mask, paste mask, and so on. Here's a list of layers we probably > want to support, from top to bottom: > > DRC layer > top keepout layer > drill (maybe support more than one drill layer to allow for e.g. > plated vs. non-plated holes) > outline (& other mechanical notations) > top silkscreen > top paste mask > top solder mask > top Cu > (an arbitrary number of intermediate Cu layers) > bottom Cu > bottom solder mask > bottom paste mask > bottom silkscreen > bottom keepout layer > > Some of these layers correspond to functionality not yet supported by > PCB (e.g. keepouts). However, if we can at least provide hooks for > them now, that would be a great thing. > > (And if I forgot one, please forgive me.....) > > Also, please take a look at how gerbv handles layers starting with the > gerbv-2.0.0 releases. This is not my work; it is Julian's, and it's > absolutely great. Moreover, it makes a lot of sense. It allows one > to assign different colors to layers, turn them on an off > (visibility), add and delete them, and move their order using > drag-and-drop. Anyway, it shows how PCB should handle the layers, > IMO. > > > The projects that need this type of conceptual change are: > > > > * The layer types thing (i.e. drawing layers can be more than "just > > copper") (this is more of a "we should solve both problems together, > > to avoid headaches later" issue). > > See above. > > > * Blind/buried vias. > > > > * Any type of 3-D renderer. > > > > It would also allow us to cut/paste/tile boards with different > > stackups more reliably, by canonicalizing them. Currently, merging > > boards is sensitive to the order of layers, without regard to which > > are component/solder/inner. > > Yes, yes, yes! Yay! > > > There was also some discussion of getting rid of the "layer groups" > > concept and forcing one drawing layer per physical layer. I suspect > > we'd need to be able to color tagged nets differently to make up for > > this type of loss. Thoughts? > > Yes, please get rid of it. The concept doesn't exist anywhere else in > layout land. There are two ways to make up for it: > > 1. Allow highlighting of nets by netname. That is, you open a dialog > box, type in the netname, click OK, and the corresponding net changes > color to white. I think we can do at least some of that right now, > right? Using this mechanism you can easily identify which planes are > GND, which are power, and which are some random net. That's what the > layer groups concept is meant to allow for, but doesn't do it as > neatly. And please define a fileformat with color assignments for netnames, and/or regular expressoins. For example GND* green V* red A* lightble ...etc Just my EUR0.02 > 2. Allow for PCB to merge layers during export. Then, you can draw > GND planes on one layer and signal nets on another. Then, when you > export, you can merge the two layers together into one Gerber. This > accomplishes the same thing as the layer groups concept -- keeping > nets of different classes separate until the very end, when they end > up in teh same Gerber. Of course, I don't have a good idea about how > you would use the UI to specify which two layers to merge...... > > Thanks for the ping! > > Stuart > > > _______________________________________________ > geda-dev mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev > -- Levente http://web.interware.hu/lekovacs _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
