On Thu, 2011-02-24 at 23:04 +0100, Martin Kupec wrote: > Hi, > > I have written something to: http://geda.seul.org/wiki/geda:pcb_layers > > It is still a bit work in progess, but you can start editing it to fit your > ideas. I have tried to incorporate all ideas discussed. I'll let you incorporate any comments you wish from this, rather than editing directly.. > Physical layer: > Name â this will be used in gerber export > Layers â linked list of layers in this âphysical layerâ > Attributes â we can come up with a list of âexpected attributesâ like > âpermittivity, thickness,..â Isn't permittivity of a "layer" more related to the prepeg material glueing layers together or core on which it is made - rather than a property of the copper "layer". I think the physical layer stack needs to take into account the pre-peg and other stack-up components which the user doesn't actually design (as such). > Layer: > Name > Number â for reference to this layer ^__ Why not refer to it by its name, or internal memory pointer? > Contained lines, arcs, polygons,â > Rtree of contained ^^^^ > Flag â flags described below > Type â type list below > Color > Selected color ^__ Properties of the view, not the underlying data - I'd prefer to abstract this to the renderer. > Attributes > Dimentions â layer doesn't have to be across whole board > Z-order â defines in what order the layers stack up ^__ I would far prefer to see some linked list of layers in stack-up order along with other data. Just storing Z-order in each layer number is not a good interface for the renderer code ot use. > Pointer for linked list of âlayersâ > Pointer for linked list contained in âphysical layerâ > Layer types: > Cooper ^___ Copper > Mechanical > Silk > Mask > Solder Paste Outline (as distinct from "Mechanical"?) I need to use a layer I can identify as an outline to render the board shape properly (GL renderer at least). OTOH - perhaps we could add outline shape as an explicit property of the board stack-up. (Rather figuring it out from the "outline" layer). > Layer attributes: > Visible â So i can hide it and not see :-) ^__ View attribute, not core data. > Show Pin/Via/Pads â On some layers for special purpose it make sense > to not include Via/Pin/Pads > Components allowed â This layer is âouterâ and can contain things > attached to it. > Negativness â Layer is negative layer Going on from this, we require a concept of how layers are merged together. We might (for example) want to subtract from an existing layer. If so, we need a defined operation order (or precedence) to give consistent results. > Exportable â Should this layer be exported? Or is just for some > internal use ^__ I don't see the use-case for this. It might be a CAM job parameter, and could vary between CAM jobs. I'd prefer to see it defined elsewhere. Overall, I dislike the concept of layer groups. I think the only vaguely justifiable reason for their existence is to do complex build up of geometry by addition and subtraction. Everything else should IMO be by done by tagging objects. I guess we could define keep-out layer(s) which could associate with one or more physical layers. That would be a possible use-case for having grouped sub-"layers", but even then I wonder if the grouping is causing limitation of flexibility. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user