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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
