kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Mon, Sep 02, 2013 at 08:53:45PM +0200, jp charras wrote:
> 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
> changed:

I agree in avoiding renaming tech layers which have a special function
(like mask and silk). However user draft only could be usefully renamed
*if* some kind of merge is handled. Which is difficult (and you agree on
that). What I asked in the past was a user-seen only 'cosmetic' change
at the board level (i.e. on *this* board ECO1 is a keepout, but for all
the world it's still ECO1). In short only changing the user visible name
(the module editor would *still* show ECO1).

> 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 other board.

Exactly what I meant. However extra 'customizable' layers would be
useful only if allowed in module (for example for keepouts), so that
limitation would make useless the extension (the no board edge in module 
rule is already a nuisance for people doing card edges and similar
things).

> 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)

Some kind of runtime translation would be needed, which is difficult to
do. Some kind of layerset object handling the conversion would be needed
and a lot of thing would need changes (apparently trivial example: when
instantiating a component the library layers would need to be translated
to the board one *and then back around* from the board to the library
editor). The layers in a layer set would be allocated on an as-needed
base and then the various entities would be 'moved' to the right layer.
It's actually more difficult than it seems (also it's a *very* invasive
modification)

> And what about board merging ?.

Same algorithm as before (in fact each module would be a 'board' in
itself). I agree it would be a mess to implement, but I don't see
another way to do it.

> 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 in libraries.

Defining a pad stack in a library doesn't make a lot of sense, the pad
stack is on the final board... from the library side I would only define
attributes for:

- Component side
- Inner layers (could be usefully divided in 'plane' and 'signal', since
  we have the attribute for the specctra exporter).
- 'Other' side

Rationale: on the component side there is the capillary joint (for
THT), on the other side there is the main (wave) joint. Clearance in inner
layer is often different (for technology reason), and somebody likes to
handle planes differently from signal layers (no idea why... aren't they
pressed in the same way at the end?)

In short the same, say, connector could be used in various stackups, and it
isn't possibile to specify in the library 'on inner 2' since it could be
a power plane, or a signal layer or maybe even not exist. Inner pad
removal is yet another 'controversial' feature. These should be
pad-by-pad modification issued on the instanced footprint, not on the
library source (when editing a pad in the board a full copper layer mask
could be edited for that, for example; ideally each layer should have
its pad parameters but the current data structure can't handle that)

Padstacks aside, I looked over how Altium handle the thing (more knowledgeable
user can correct me): 

- Copper: Top+Bottom+30 inner signal layer; we have 14, enough for now:P
  16 planes (we don't handle them)

- Silk, solder, paste: Top+Bottom (obviously!)

- 'Drafting' layers: 32 mechanical layers, pairable (like adhesive)

- Drill drawing and drill master: we generate it on the fly during plot

- Keep out layer: we do it with zones (more or less)

- Multi layer: strange thing... I think it is an internal artifact for
  handling thru vias, can't see another good use for it.

All of the 'generic' things are done with the mechanical layers, it
seems... the tutorial has a screenshot of the spectacular Board Layers
& Colors dialog (that thing is *huge*), so their 'mechanical' layers
cover our: adhesives, drawing, comments, eco1, eco2, assembly, courtyard
and so on. The 3D models is stored aside... AFAIK the courtyard as
a special layer is more a Mentor-only concept (and it's mostly for human
consumption, even if a DRC could be usefully done on it).

If I get it correctly, what Brian is asking for is the support for the
Altium 'mechanical' layers. From what I reckon from the doc these are
handled by number and named/paired at the board level (it's not clear
how the transition from the library to the board is done). It would be
interesting to know how libraries done with different layer convention
interact in Altium...

Given the current state of the code, I think the best course is to
decide on a 'useful' set of layer and fix it (possibly with the
'cosmetic renaming' feature). Of course any genial idea on how to handle
the dynamic layer allocation/translation would be accepted:P

-- 
Lorenzo Marcantonio
Logos Srl