On Mon, Sep 02, 2013 at 12:13:07PM +0100, Brian Sidebotham wrote:
Actually, I think I want to change my answer a bit. Because as I hinted, I
don't need more layers, I need better layer versatility. I want to be able
to rename layers (Already achievable!), but I also want to be able to
Well... *not*, you can only rename copper layers because Dick said so.
And threatened to well... don't remember exactly but probably most
painful if somebody suggested to do otherwise. Something about how he
preferred to read the board file or such. Read the list archives,
I forgot the details.
So ECO1 remains ECO1, even if you use it for mechanical clearance.
All I really want to be able to do is assign names and properties to
layers. How KiCad arranges most of these layers within it's 32 layer limit
is not really my concern. Only the copper layer stack order is important,
and we already had identifiers for these in the new file formats so that we
can select all copper layers (regardless of the number of layers in the
current design).
There are non-trivial issues when merging board or inserting a module
with a different layer usage, in that case. Nothing unmanageable but
a complex thing nonetheless...
I think this has merit as opposed to simply fixing the number of layers to
a higher number and then assigning static layer numbers specific uses. It
would be much more versatile to have the additional properties for each
layer and to let KiCad fit them however it sees fit into the maximum number
of layers it can handle.
Something like that was already proposed in the past. We would need
a layerset container for that to work, containing pairing and stuff.
That's because a board uses a layerset but the modules could use another
one. The current situation is: the board uses 'the user layerset' i.e.
the one with renamed copper layers and the rest of the world uses the
'standard english' layerset; since there is a 1:1 relationship and the
indexing is the same there is nothing to do to switch between them; the
situation would change with your proposal.
Also, that copper layers are 16 and consecutive in numbering is *not*
an easy thing to change (there are lot of for FRONT to BACK loop inside,
requiring consecutive ordering), unless we do some heavy operator
overloading on the layer types.
So at the moment we have
- Copper front + 14 inner + bottom (fixed and not easily changeable)
- Board edges (very special)
- Special technical layers (needing ad hoc code to handle): mask, silk,
paste, (assembly, courtyard). Silk is actually special because it has
custom plotting rules. Paste and mask have the enlarging rules.
Courtyards could have a DRC check and assembly has a special plotting
rule, too (the 'reference to origin' one).
- 'Other' layers: the adhesives have nothing special, other that they
are listed in the pad dialog. Drawing, comments and ECO are, by
design, user layers.
Leaving aside the 'specials' and copper layers, you could generalize and
parametrize all the other layers (adding them to pads and pairing, in
other words). Given that 64 layers are easily available that should make
you happy (without touching the copper layer relationship/ordering). In
short, adhesives, drawing, comment and ECOs would be 'user defined
layers' and the current situation would be a useful default or something
like that.
Of course that would need a *huge* UI rework (a new stackup dialog and
dynamic generation of other layer lists) and provision for merging
etherogeneous layersets (maybe even a bigger work).
