Re: gEDA-user: General Layers questions

[Martin Kupec <martin.kupec@xxxxxxxxx>]

On Mon, Mar 14, 2011 at 06:11:13PM -0400, DJ Delorie wrote:
> 
> > 1. Line is drawn on copper layer, it has properties like, mask and
> > paste.
> 
> I think for things like mask and paste, we might have to differentiate
> between implicit and explicit contents.  A pad which has a mask
> opening is an implicit object on the mask layer; the user drawing
> additional stuff on the mask layer would be an explicit object.
> 
> However, a *footprint* that defines a mask opening in a mask layer,
> would have explicit content on *its* mask layer.  That content would
> be merged with it's elements' parent's corresponding mask layer during
> draw/output.
> 
> However, I don't think we should start off with "lines have paste".
> They don't.  Pads have paste, pads are made of lines.  In the new way,
> we should define paste separately, so it's never an attribute of
> something else.  However, we could include shortcuts for common
> objects like pins or pads, which are expanded at runtime into the
> corresponding layers.

To all the above I will write another email.
> 
> What attributes lines *do* have is keep-aways, like copper clearance
> in polygons.  Such clearances affect other like-types in the
> same-layer, i.e. clearance on a copper layer clears polygons on that
> layer, clearance in a assembly drawing layer clears filled polys on
> that drawing layer, etc.
Yes, keep-aways are definetly just attributes. The others are not.
> 
> The tricky part of all this is defining ways of referring to a given
> drawing layer in a physical layer by type, class, and name.  I.e. if a
> footprint has a generic "silk" layer, and our design has four
> different types of silk layers, to which do we map the footprint?
That is why I have defined "active layer". So each type of layer has an
"active" one. When I add footprint I add its silk layer to the current
active silk layer. That should work and should be simple.

> 
> I suggest, for performance, we define layer classes as enumerations
> (copper, silk, mask, paste, outline, drawing; plus modifiers like
> "anti-paste" vs "paste") but have a way to further name layers in a
> class-like heirarchy with wildcards.  Thus, a footprint might have a
> layer named "silk::courtyard" that is a silk (enumerated) class named
> "courtyard".  The design might have a courtyard layer, or might define
> a catch-all drawing layer "silk::*" it gets mapped to.  Perhaps
> "silk::assembly::courtyard" which maps to a generic silk layer, unless
> you have a generic assembly layer, unless you have an assembly layer
> just for courtyards.
I have a bit different idea here. Generally all can go to "common"
silk. But elements will be attached "tags". That will be just some
general purpose mark. An element would have any number of tags it needs.
And there will be possibility to put all "tagged" elements of some type
to special layer, other than the active one.
> 
> Allowing a GUI way to enable/disable layers anywhere in the heirarchy
> would be cool; you could disable just the assembly objects in your
> generic silk layer.
It should be simple. Just skip drawing of that part :-). I know it is a
bit more complicated, but it should be possible.
> 
> I've mentioned numbered vs named physical layers before, like
> "top/inner/bottom" vs "1..8" (or top,2..7,bottom) - such mappings
> between symbolically named layers (drawing or physical) and specific
> physical layers in a design is something we need to figure out.
There will be implicit mapping. Each "drawing" layer belongs to some
"physical" layer. And everything will have names, numbers are not needed
at all. Z-order will be implicitly defined by order in memory/file.
> 
> Mapping the layer heirarchy to a "CAM job" engine, that picks out
> which parts of the heirarchy become which parts of each output
> page/sheet/gerber/screen/whatever, is another problem.
I don't see what is the problem :-(.
> 
> > It is needed to decide which concept to use, I have no preferences,
> > and describe closely how it should behave. The problem is that
> > working on copper/mask/paste layers is somewhat interconnected....
> 
> I think the connection should be at the sub-assembly heirarchical
> level.  We should treat footprints as "just another pcb sub-assembly",
> so if you move an element, it's footprint is drawn at a new location,
> which happens to move the lines and paste together.  There is NOTHING
> requiring an assumption that paste and lines correspond; for example,
> a thermal pad often has paste that is a completely different geometry
> than the copper.
Ok. I can define that footprint is that set of elements and it moves
according to origin of the footprint. And I mean "any set" on "any set
of layers".

	Martin Kupec



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user