Re: gEDA-user: General Layers questions

[Steven Michalske <smichalske@xxxxxxxxx>]

This message makes me think that COW should remember what master it was copied from and an edited flag.





On Mar 18, 2011, at 5:16 PM, Stephan Boettcher <boettcher@xxxxxxxxxxxxxxxxxx> wrote:

> DJ Delorie <dj@xxxxxxxxxxx> writes:
> 
>>>> Except gerbers have special cases for thermals and pads, for example.
>>> 
>>> So there need to be attributes on shapes.
>> 
>> No, the exporters really need to have access to the whole collection
>> of shapes that means "pin" so they can do pin-specific things.  If the
>> exporter doesn't need that high-level access, then the default action
>> breaks it down into shapes and exports them individually.
>> 
>> The gerber exporter needs to be given a whole "pin" because it has a
>> command that means "put pin here, with this aperture and thermal
>> settings".  If you wait until the core descends to "circle, arc,
>> line", it's too late to look at the attributes and figure out what's
>> happening.  CAM tools know about this, and can adjust thermals and
>> pins as needed, but in PCB's case they can't do it because we break
>> pins down into raw shapes.
> 
> I do not understand this.  The gerber exporter exports each layer
> separately, no?  On some layer it finds a circle with a thermal
> attribute surounded by a polygon.  What else does in need?
> 
>>>> and containing other layers as sub-layouts.  I have never disagreed
>>>> with this!
>>> 
>>> Oh.  My understanding of composites is different.  I assume a composite
>>> contains shapes that go on a global set of layers.
>> 
>> This is part of the communication problem we're having, yes ;-)
>> 
>> Consider these:
>> 
>> * A footprint is a global resource, but an instance of a footprint (an
>>  element) must be mapped to the physical layout.  When do you manage
>>  the footprint as an element (indivisible) and when do you access its
>>  parts (changing pad size)?
> 
> Is the footprint still part of the layout?  Wouldn't it's genereic
> layers (top,inner,bottom) be mapped to the layout layers
> (oben,innen1,innen2,unten) when imported?
> 
>> * A sub-circuit that's replicated N times on a board.
> 
> composites instances are objects inside other composites, next to
> shapes.  You can do most operations to composites, that you do to shapes
> (move, rotate, mirror, delete, ...).  Vias and elements are special in
> the memory representation, as there are methods, or callback hooks that
> allow access to some internals without explicitly decending into the
> composit.  It should be possible to flag any composit as Element or vise
> versa, to turn on and off this special access.  If you exlicitly decend
> into an element, you can move its pins and pads.  But pads size, text
> positions e.t.c. are still directly accessible for elements.  Maybe it
> is not even necessary to have any special treatment and treat all
> composites the same.
> 
>> * A flex cable that has 4 layers at each end, but only 2 layers in the
>>  middle.  The extra layers on the end are on opposite sides of the
>>  cable.
> 
> You want to describe the rigid ends as outlines of a composite?  That
> attaches high-level semantics to a low level concept in an inapropriate
> way.
> 
> Here you need outline layers with attributes that tell the autorouters
> not to cross the lines on certain layers.
> 
>> * buried vias are limited to certain pairs of layers because of the
>> way the fab is assembling the board.
> 
> A DRC problem.  With hole layers, the GUI tool to add/manipulate these
> hole layers can provide a view on the layer stack that represents the
> stacking and drilling order, just like you once proposed as an
> underlying data structure.  The tool would refuse to configure holes
> layers that cannot be drilled, unless you say "please".
> 
>> * 400 instances of a standard via, but the user needs to modify the
>>  pad stack on just one of them, and only for one layer.
> 
> Vias may be COW by default, like they are now.  But you can decend in
> non-copy mode into the composite, so they all change.  That composit is
> also the master copy in the Via menu, so that future vias of that type
> are affected by the edit.  When you edit the via definition in the Via
> menu, you may need to answer a question if you want all existing
> instances to change, of only new vias.
> 
>> These are all examples of a need for both a semantic and data
>> heirarchy, where parts of your design are grouped together and treated
>> as a single object, sometimes replicated, sometimes customized.  What
>> we call them is not important.
>> 
>>> Well, yes, it can, except that a via is not sufficiently special to
>>> justify the distiction.  What would we have in a composite, the layout
>>> being the top-level composite?
>>> 
>>>  Vias
>>>  Elements
>>>  Composits that are not Vias or Elements
>>>  Lines
>>>  Shapes outside of composits that are not Lines
>> 
>> Consider: you can move a via, but for lines, you can move either the
>> line or its endpoints.  For a polygon you can move its corners.  Ah,
>> but a via can include polygons and lines - but when it's a via, you
>> *don't* move their endpoints and corners, unless you specifically edit
>> the via.  A pin is just like a via, except you *don't* move it - you
>> move the element it's in.
> 
> shapes (lines and polys) in the current composite can be editied as
> before, moved, endpoints moved, size, pcb:endcap attributes changed ...
> 
> Some internals of composites may be accessible, like clearances and
> sizes, just as before. A composite attribute may define it its COW or it
> all instances are changed.  Vias and Elemets are COW by default if past
> behavious shall be kept.
> 
> When you want to change something inaccessibe inside a composite, you
> can decend into it, either in copy mode or non-copy mode.  Everything
> higher up than the edited instances may be grayed out on screen now. You
> can also choose to only see the instance you are editing.  Now you can
> manipulate, autoroute, ... the content of the composit.  There is your
> footprint/via editor.
> 
>> Now consider a differential pair.  It's a line but you *don't* move
>> the *line* endpoints, you move the *pair* control points.
> 
> That is a hard one.  You could define a composit of type "morphable" The
> endpoints of shapes inside such a composite become pointable/selectable,
> and a plugin can register callbacks to be called when such an endpoint
> is manipulated.  The plugin would check to see if a "diffpair" attribute
> is set, and decline the callback if not, so that the "magic_poly" plugin
> has a chance.
> 
>> So yes, a via is special.  Many other composite objects will be
>> special too, because the tools need to know what the appropriate way
>> of interacting with them are.  PCB layout is *not* a paint program,
>> it's a design tool.  It *must* understand "the design" if it's to be
>> the most useful to the user.
>> 
>>> When an how to map generic element layers to layout layers is
>>> another good question.
>> 
>> Yup.
>> 
>>> Global layers can be mapped at load time.  Local layers inside
>>> composits must be mapped a runtime, don't they?
>> 
>> The mapping can be computed at load time, and just stored.  I suspect
>> there'll be lots of "recurse through the data heirarchy" code.
> 
> 
> 
> ... 21 new messages in my inbox
> 
> -- 
> Stephan
> 
> 
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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