Re: gEDA-user: General Layers questions

[DJ Delorie <dj@xxxxxxxxxxx>]

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

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.

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?

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.

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.

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.

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.

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


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