On Wed, Jun 04, 2014 at 12:13:42PM +0200, Tomasz Wlostowski wrote: > - board outline
PCB Edges, check. > - mounting/mechanical assembly holes Drawings? check > - mechanical component assembly outlines Do you mean the enclosure? another drawing layer > - one or more dedicated layers for mechanical dimensions Drawings? > - PCB corners for manual cutout No idea of this. I presume yet another drawing layer. > - peel-off masks for wave soldering of THT components (2x) Missing, could be useful but often is prepared by the fabricator. > - panelization drawing Panelization issue, CAM people problem :D > - component courtyards (x2) Missing, *could* have behaviour attached (DRC) > - component body drawing (2x, for hand/semi-automatic assembly) Fabrication? missing (adhesive seem to be repurposed for that). Also special behaviour for refdes (plotted always on origin). > ... 12 in total. I'd say that would be two coupled pairs with behavious (fabrication and courtyard) and, let say, about 6 general-purpose drawing layers. If we design some kind of rule for pairing (something like 8 general purpose layers and 16 general purpose *paired* layers) dispensing and other things don't need to be catered for explicitly. > I thought adhesive layers are for SMD glue dispenser machine. The person > doing manual assembly may need another technical layer (and silkscreen is > often useless for densely packed components). Glue programming (when needed) is usually done by the fabricator while programming the pick and place, it's more of a CAM issue. You need to know exactly the kind of adhesive and stuff... then you could define 'pads' on that layer to define the dispensing. AFAIK that was the original meaning of that layer. > IMHO drawing the courtyard using standard graphics primitives on a dedicated > layer is the least disruptive way of achieving above. Agree with that. Ideally courtyard would be zone-based, but at the moment we don't have zone support in modules, so lines are a good compromise. And of course DRC code for this need to be written (however even only eyeballing the layer catches a lot of placement errors in my experience). > What would be the issue to add them to the sexpr file formats, that are > meant to be extensible? Ask Dick. Bring asbestos suit :D > - write a type safe flag container (based on std::bitset, I guess), More or less ready, I have a pervasive enum for that (I'm working with 64 bits); should be replaceable with something more 'heavy' without big problems. Except for literals, these are a problem (unless we dare to use the new C++ literal facility). And IIRC there were some ideas about efficiency concerns passing such an object around. Remember however that 90% of the layer bitset use is only for pads, it's less pervasive than expected (most things are only one layer or a range). > - refactor the current layer set to use it, Do you mean the LAYER_NUM type and machinery? > - add a possibility to rename any layer (without changing its purpose), Talking about these things is treacherous, be warned. Thicken asbestos suit and look in the mailing list archives. Also: problems with mismatching names/number between board and libraries and so on (Altium says: decide once and then it becomes a system global definition; could not be the best design choice...) > - add new layers, > - add show/hide options and layer grouping in the layer manager. In short the UI for layer management; grouping could be seen as a bonus IMHO is not so essential (gimp survived a long without that) -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp