kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

Wayne Stambaugh wrote:
> Dick Hollenbeck wrote:
>
> > > ** the first copper layer is number 0 but has a special name 'front', in 
> > > addition to any name the user gives it.
> > Clarification: each copper layer has both a user given name, and a 
> > layer number, just as now. The reserved token 'front' and 'back' are 
> > simply "special layer numbers", not actually in the same name space as 
> > layer names.
> >
> > After declaring the layers up front in the file, throughout the board we 
> > will use layer numbers rather than layer names. However, rather than 
> > becoming too dependent on the layer count, which changes the numeric 
> > value of the back of the board, we will use 'back' in certain situations 
> > in place of the layer number for back. Likewise for front, it is a 
> > layer number, not a layer name per se.
> >
> > We saw an example of this a few postings ago:
> >
> > (layers front back) # a LAYERSET object which includes only the front 
> > and back copper layers.
> >
> > (layers front 1 back ) # I suppose this has to be legal also
>
> Dick,
>
> I'm assuming from the previous discussion about single layer boards that:
>
> ( layers front ) # Front layer only.
> ( layers back ) # Back layer only.
>
> are also legal. But what about:
>
> ( layers front 1 2 ) # No back layer.
> ( layers 1 2 back ) # No front layer.


These would be valid LAYERSET specifications. Where such a LAYERSET 
specification is used is a longer conversation. Previously we talked 
about using LAYERSETs in lieu of having a full padstack definition for 
pads. The pad editor in the module editor limits us to this path. It 
is not a severe limitation, because you can give more than one pad the 
same pad number. But our LAYERSET let's us overcome the lack of 
padstack support. On the other hand, our LAYESET lets us exceed the 
specctra padstack capability in that we intend to support LAYERSET with 
range, and *all coppers*. Specctra has no such notion. This means you 
can add layers to a board after having done a footprint, and not have a 
PAD definition be obsoleted should that pad reside on both sides of the 
board, or all copper layers of the board. A specctra padstack cannot 
specify *all* layers in a layer count independent manor.


Ultimately what we put into the file depends on the richness of the 
module editor, and its pad editing capabilities. This new file format 
is only intended to give us the ability to flap our wings, it does not 
represent a commitment to actually flap them. We don't often 
contemplate file format changes like this, so when we speak about 
flexibilities, we are not actually committing to doing the work to fully 
utilize all the capabilities of the file format, at least not immediately. 


In fact, the practicality of doing this change reliably depends on the 
fact that little or no internal code changes are needed, other than file 
load and save, and layer drawing order, and layer selection logic.


BTW, tokens need to be uniquely used, so 'layers' could be used for 
LAYERSETs or for layer definitions, but not both. Would need two 
unique tokens obviously.


Dick


> I don't know if this makes sense or even if any pcb manufacturers would
> make boards with these types of layer stacks. Just curious.
>
> Wayne
>
>
> > Techical layers:
> >
> > In the case of technical layers, I would be inclined to not expose nor 
> > support any "user defined technical layer names". This is as now. But 
> > in the board file, I would chose to use a fixed special token to these 
> > special layers similar to 'front' and 'back'.
> >
> > examples: soldp_fr, soldp_bk, silks_fr, silks_bk.
> >
> > These special tokens are treated like layer numbers.
> >
> > This way the board never becomes dependent on layer numbers other than 
> > copper layer numbers.
> >
> > Scream now if this hurts, nod if it seems reasonable.
> >
> >
> > Dick
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links