kicad-developers team mailing list archive
Mailing list archive
Re: Experiments and considerations for more layer
Le 02/09/2013 13:47, Lorenzo Marcantonio a écrit :
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
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
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).
More layers is certainly a serious enhancement, and mainly courtyear layers.
After reading mails about layers, I am happy you have *actually* the
same opinion as Dick about the fact non copper layer names cannot be
There are very non trivial issues if they are renamed, because a
footprint lives in a footprint library, therefore outside a board,
and layer names live in a given board, and differs from a board to an
Therefore, as you said, how to match a renamed layer in a board, with a
renamed layer in a footprint, many times created by an other guy, for an
other board? (example: ECO1 name top_courtyard in a board, and ECO1
renamed silk_screen_aux in a footprint)
And most of tech layers having a special meaning, renaming them is very
Just remember the lot of issues due to layer names translations.
Obviously, unless you have a *very good* idea, I know only 2 way:
- Do not accept the tech layer renaming (This is what Dick made)
- Accept layer renaming, but do not accept use of tech layer in
footprint, for layers which can be renamed (currently does not exists in
I'll be happy to know other ways.
Renaming layers like silkscreen, or solder paste, is something like
renaming a board.kicad_pcb to board.ps, send it to your PS printer, and
expecting it will be printed.
And what about board merging ?.
Note: Copper layers can be renamed because pads know only 3 cases: top
layer, bottom layer, or all layers, which do not create issues relative
to copper layer names, or copper layer count.
From this point of view, Pad stacks are a serious issue, when defined
By the way, I am reworking on the layer box selector (stackup dialog)
(and committed the first changes), which could help you for your