Mail Archives: geda-user/2014/07/09/23:55:22
On 07/09/2014 10:50 AM, DJ Delorie wrote:
>> I think any layer objects embeded in footprints (might as well include silk and copper in the same way going forward), ought to reference predefined symbolic layer name or ID.
>>
>> "TOP-SILK" "TOP-MASK" "TOP-COPPER" "INNER-COPPER" "INNER-ANTI-COPPER"* "BOTTOM-COPPER" etc...
>>
>> *(inner anticopper might need some thought, possibly not one for today!).
> Yeah, IMHO symbolic layers is a must.
>
> I also think we need a way of "stacking" or "nesting" drawing layers
> within a physical layer to do fill/cut/draw operations. For example:
>
> * "Fill" - positive, first rendered, used for power plane polygons
> * "Cut" - used for keep-outs, and cutting planes into sub-planes with traces
> * "Trace" - used to draw traces over polygons (clear polygons but ignore cuts)
>
> Each layer needs a positive/negative flag, so you could (for example)
> draw negative text over a filled rectangle.
>
> But given that footprints might have their own fill/cut/trace layers,
> which may be drawn on top of the board-layer cuts, we need to be
> flexible in making these stacks...
>
> * board-level fill
> * board-level cut
> * footprint-level fill
> * footprint-level cut
> * traces
>
> but if you want to support "sub-layouts" it gets even more complex.
>
> Perhaps a heirarchical design?
>
> * board-level fill
> * board-level cut
> * sub-layouts and footprints ->
> * . . .
> * . . .
> * . . .
> * board-level traces
>
> And all that is just *per layer*
It strikes me that this is an excellent layer model for talking about
footprint models, even though pcb doesn't support arbitrary symbolic
layers. If we define a model consisting of symbolic logic layers, each
containing sublayers, and define rendering rules, then we can map what
pcb *currently* does onto that same model.
So while ultimately it would be great if users could create arbitrary
layer stacks with arbitrary names, and define their rendering order,
right now today pcb *has* a set of logical layers, with defined names,
and a defined rendering order. That means one could go ahead and define
a footprint model around some future flexible layer model. The
footprint file format can target the flexible layer model, its just that
if you code a footprint today there is exactly one layer model available
to you, with pre-defined layer names, so your footprint needs to live
within those constraints. As pcb moves forward, more of the semantics
of the footprint model become available as layer constraints are relaxed.
- Raw text -