Re: gEDA-user: General Layers questions

2011-03-24 Thread John Griessen

On 03/19/2011 12:01 PM, Martin Kupec wrote:
   On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:


No problem here. Just define that conductive ink as copper or conductive
type layer. I don't care how that layer happens to be manufactured.


  No. For describing geometry, I agree that the manufacturing process is

irrelevant. But the layer needs properties, not some arbitrary classification.

I never said that you cannot add additional properties(attributes) to
the layers. I am just saying that there should be some, as you say,
arbitrary classification. And than you refine that clasification by some
properties. But the basic classification will be clean and understood by
all parts of pcb. The additional properties can be admited just by some
parts.


I also like to keep the data structures aligned with a physical reality as in
properties attached to layer data that represents physical stack up existence.

Defining steps in manufacturing processes gets too way off in the unknowable to 
be workable
on a FOSS project.  Just defining what is there is really big and bogs down 
chip designers
if they let it, so we need to watch out for it as board designers.  Boards will 
look like
chips soon enough.  Any time you consider defining something by a process, such 
as
hole making, you could instead define where material is in a 3D pixel and an 
attribute
is fine for that.

A stack-up layer is not the same as a physical layer, since physical
material can fold and compress as layers are processed.  For instance
solder mask -- it flows over etched conductive layer
material until it can make the silkscreen print fill differently because
it is no longer in a planar layer, but a rumpled non-flat but continuous layer.
I think the stack-up of non-flat material is something we should plan for
some, but put off mostly right now.
It's a tough problem.

Allowing that a stack-up layer could have several different materials
in it is current technology that is evolving quickly, so we want that.
Saying the we can model physical stack-up that distorts a little and stays
mostly planar with an error is something we can plan for now and
get a big benefit.  A stack-up layer wouldn't be complete if it was
a hole definition layer, and you can derive the  hole def layer from stack-up,
so use the word layer to mean a model of physical material that is somewhat
flat, with errors less than X away from being a stack of cubic pixels.
That way is bottom up as John Doty recommends and allows extracting physical
model data from simulation for more benefits.

On 03/18/2011 06:34 PM, Stephan Boettcher wrote:
 Still, I do not see a need for outline layers anywhere, except as an
 attribute on a graphical layer that tells an exporter where to stop
 drawing.

I agree that outline as it is done now is not consistent with the above plan.
The function of outline for routing or extent of the board you are
designing could be handled by an attrib on a trace.  To be consistent
with modeling physical material, the outline trace (or future 3D pixel)
should be outside the edge of material
that is kept rather than its centerline defining that edge as it is done
for outline definition RS274-X files.

Even using outline attrib to create an edge is a negative space definition
that could be skipped.   Instead, you could define
all the intermediate physical FR4 composite or printed material including its
extent being a non-default, non-rectangular presence of material.  We now
define FR4 composite material only indirectly.  Besides streamlining the whole
way of representing stack-up materials, additive processes will
naturally demand insulator materials that go down as printed layers, just
as solder mask, copper, silk-screen do now.  Once you go all the way to defining
presence of material as your basic model, you no longer need any definers
of negative space...


John Griessen


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


Re: gEDA-user: General Layers questions

2011-03-21 Thread Kai-Martin Knaak
Steven Michalske wrote:

 And your kind of bottom-up design never gets done at all, because of
 impossible-to-meet requirements for unlimited flexibility.
 
 Wow all my bottom up designs in shipping products must not exist 

IMHO, the emphasis here was on your kind of, with you pointing to 
John Doty. Please, don't get carried away by emotion -- all of you.

---)kaimartin(---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53



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


Re: gEDA-user: General Layers questions

2011-03-20 Thread Kai-Martin Knaak
Martin Kupec wrote:

 I am the one who is willing to code it. And my majority I simply mean
 number of people involved. I am democratic, just counting heads :-).

In that case, just count me in on DJs side  by default ;-)

---)kaimartin(---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53



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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Stephan Boettcher
Martin Kupec martin.ku...@kupson.cz writes:

 Hi all,

 I appreciate the discussion.

So do I.  It started out a bit of a mess, because we were talking about
different things, but in the end I think there was not left much
disagreement about fundamental issues.

 There we nearly no objections to my layer concept, just to the
 via/footprint/composite.

 I have updated the page (http://geda.seul.org/wiki/geda:pcb_layers)
 and I hope it not reflects the 'opinion of majority'.

I will now have a look at that.  But what do you call majority?  The
most vocal people here, like John and myself did not offer to do any
coding, yet.  In the end, those that code (DJ, you ?) decide.

I appreciate that you asked for out opinion!

 So again. Coments are welcome, the discussion was a bit fast so I may
 have missed something important again.

I think it is worth to read the whole thing once again. I will send
myself a digest message of the whole thread so that it is easier to
read, and I may try to identify the core arguments.

 Thank you all for participating,

Thank you!

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Martin Kupec
On Sat, Mar 19, 2011 at 11:02:55AM +0100, Stephan Boettcher wrote:
 I will now have a look at that.  But what do you call majority?  The
 most vocal people here, like John and myself did not offer to do any
 coding, yet.  In the end, those that code (DJ, you ?) decide.
I am the one who is willing to code it. And my majority I simply mean
number of people involved. I am democratic, just counting heads :-).

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Markus Hitter


Am 19.03.2011 um 02:29 schrieb John Doty:


... comparison to the C language snipped ...


Proper bottom-up design *never* results in impossible-to-meet  
requirements because it starts from capabilities.


Nice description, John.

What can a layered description of tame plane geometries (no  
fractals ;-) actually represent?


To some extents I can't get rid of the feeling layouts shouldn't be  
considered as layers with components on them, but as tracks, holes,  
pads and components which happen to be manufactured on layers.


For example you have holes, which happen to be plated or unplated,  
which happen to connect to pads, which happen to connect to layer  
2-4, and so on. Low level data representation describes those  
elements with their properties, higher level functionality provides  
functions ensuring this makes sense in a layered design.


Currently, components are handled this way; resistors, ICs, and that  
stuff are listed as parts in a .pcb file. The lacking part is, there  
is no clear description of all their properties, e.g. to which tracks  
or layers they connect. Tracks should be handled the like components.


BTW., there were electronic circuitries before PCBs were invented and  
the future of electronics manufacturing is most likely something  
three-dimensional, arbitrarily shaped.



my $0.02,
Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/







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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Stephan Boettcher
Stephan Boettcher boettc...@physik.uni-kiel.de writes:

 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.

The morphable composits can also support lines with soldermask opening
and paste.  Maybe we call the wires.  These composits allow to
manipulate endpoints of contained objects, where a plugin makes sure
that the stack of features representing the wires move together.

-- 
Stephan Böttcher FAX: +49-431-85660
Extraterrestrische PhysikTel: +49-431-880-2508
I.f.Exp.u.Angew.Physik   mailto:boettc...@physik.uni-kiel.de
Leibnizstr. 11, 24118 Kiel, Germany


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread John Doty

On Mar 19, 2011, at 4:57 AM, Markus Hitter wrote:

 BTW., there were electronic circuitries before PCBs were invented and the 
 future of electronics manufacturing is most likely something 
 three-dimensional, arbitrarily shaped.

Yes. I'm now working with two groups that are fabricating parts with 3-D 
printers. I've been wondering when the technology will reach the point where 
the printing could include conductors, with components placed during the 
build-up, and then buried. 

But I suppose describing this is beyond what we can conceptualize here at this 
time. Planes are difficult enough.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Stephan Boettcher
Martin Kupec martin.ku...@kupson.cz writes:

 On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote:
 Martin Kupec martin.ku...@kupson.cz writes:
  That is a bit complicated. I need a clean definition of layer types, so
  one can pick the right layer when needed. But some attributes in
  addition to layer type are possible.
 
 I do not understand that argument.

 Ok. We probably don't understand each other, so I will just state my fears.

 I would like to know about each drawing layer where it belongs to.

 If layers types would be defined by attributes, someone would be able to
 declare one layer both as conductive and as silk for example. That could
 cause me a nighmares. That is why I insist on 'typed' layers, not
 'tagged' layer.

Hmm.  I think that is the old trap of overloading.  When you say that a
layer type defines what you can do with it, then this one type attribute
becomes messily overloaded.

-- 
Stephan



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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Stephan Boettcher
John Doty j...@noqsi.com writes:

 On Mar 19, 2011, at 4:57 AM, Markus Hitter wrote:

 BTW., there were electronic circuitries before PCBs were invented and
 the future of electronics manufacturing is most likely something
 three-dimensional, arbitrarily shaped.

 Yes. I'm now working with two groups that are fabricating parts with
 3-D printers. I've been wondering when the technology will reach the
 point where the printing could include conductors, with components
 placed during the build-up, and then buried.

 But I suppose describing this is beyond what we can conceptualize here
 at this time. Planes are difficult enough.

As long as this 3D structure is built mainy manhattan style, with
horizontal conductive layers and vias, all conductive layers become
component layers, an element must define keepout zones on those layers
that it's housing penetrates.  It's pads are on layers that correspond
to the z-positions of it's pins.  Before you start making your footprint
library you need to decide on the thickness and distance between the
conductive layers.  The kind of tool we were discussion here could do
that very nicely.  A GUI plugin needs to be written, that allows to move
the 3delements up and down in the layer stack. Maybe even rotate off
plane, but that is initially best done by hand as a separate
3dfootprint.

One more argument to implement holes as shapes on a hole layers.

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread John Doty

On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:

 If layers types would be defined by attributes, someone would be able to
 declare one layer both as conductive and as silk for example. That could
 cause me a nighmares. That is why I insist on 'typed' layers, not
 'tagged' layer.

No. The nightmare is classification.

It's perfectly possible to put conductive ink on a board with a silkscreen 
process.

Layers should, of course, have electrical properties: conductivity, dielectric 
constant, permeability. Also thermal and mechanical. More grist for the 
composition machinery, of course, because users will want to use copper as 
shorthand for a list of properties. But the properties are what the code should 
be paying attention to.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Martin Kupec
On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:
 
 On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:
 
  If layers types would be defined by attributes, someone would be able to
  declare one layer both as conductive and as silk for example. That could
  cause me a nighmares. That is why I insist on 'typed' layers, not
  'tagged' layer.
 
 No. The nightmare is classification.
 
 It's perfectly possible to put conductive ink on a board with a silkscreen 
 process.
No problem here. Just define that conductive ink as copper or conductive
type layer. I don't care how that layer happens to be manufactured.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Martin Kupec
On Sat, Mar 19, 2011 at 04:43:29PM +0100, Stephan Boettcher wrote:
 Martin Kupec martin.ku...@kupson.cz writes:
 
  On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote:
  Martin Kupec martin.ku...@kupson.cz writes:
   That is a bit complicated. I need a clean definition of layer types, so
   one can pick the right layer when needed. But some attributes in
   addition to layer type are possible.
  
  I do not understand that argument.
 
  Ok. We probably don't understand each other, so I will just state my fears.
 
  I would like to know about each drawing layer where it belongs to.
 
  If layers types would be defined by attributes, someone would be able to
  declare one layer both as conductive and as silk for example. That could
  cause me a nighmares. That is why I insist on 'typed' layers, not
  'tagged' layer.
 
 Hmm.  I think that is the old trap of overloading.  When you say that a
 layer type defines what you can do with it, then this one type attribute
 becomes messily overloaded.

So far we have like 10 types. That is not that bad. Some new may come,
but it is still keeping low.

The other way is to have a dozen of different attributes. And probably
with some constrains and hierarchy. I think that is more complicated.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-19 Thread John Doty

On Mar 19, 2011, at 10:50 AM, Martin Kupec wrote:

 On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:
 
 On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:
 
 If layers types would be defined by attributes, someone would be able to
 declare one layer both as conductive and as silk for example. That could
 cause me a nighmares. That is why I insist on 'typed' layers, not
 'tagged' layer.
 
 No. The nightmare is classification.
 
 It's perfectly possible to put conductive ink on a board with a silkscreen 
 process.
 No problem here. Just define that conductive ink as copper or conductive
 type layer. I don't care how that layer happens to be manufactured.

No. For describing geometry, I agree that the manufacturing process is 
irrelevant. But the layer needs properties, not some arbitrary classification.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Martin Kupec
On Sat, Mar 19, 2011 at 10:56:27AM -0600, John Doty wrote:
 
 On Mar 19, 2011, at 10:50 AM, Martin Kupec wrote:
 
  On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:
  
  On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:
  
  If layers types would be defined by attributes, someone would be able to
  declare one layer both as conductive and as silk for example. That could
  cause me a nighmares. That is why I insist on 'typed' layers, not
  'tagged' layer.
  
  No. The nightmare is classification.
  
  It's perfectly possible to put conductive ink on a board with a silkscreen 
  process.
  No problem here. Just define that conductive ink as copper or conductive
  type layer. I don't care how that layer happens to be manufactured.
 
 No. For describing geometry, I agree that the manufacturing process is 
 irrelevant. But the layer needs properties, not some arbitrary classification.

I never said that you cannot add additional properties(attributes) to
the layers. I am just saying that there should be some, as you say,
arbitrary classification. And than you refine that clasification by some
properties. But the basic classification will be clean and understood by
all parts of pcb. The additional properties can be admited just by some
parts.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-19 Thread John Doty

On Mar 19, 2011, at 11:01 AM, Martin Kupec wrote:

 On Sat, Mar 19, 2011 at 10:56:27AM -0600, John Doty wrote:
 
 On Mar 19, 2011, at 10:50 AM, Martin Kupec wrote:
 
 On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:
 
 On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:
 
 If layers types would be defined by attributes, someone would be able to
 declare one layer both as conductive and as silk for example. That could
 cause me a nighmares. That is why I insist on 'typed' layers, not
 'tagged' layer.
 
 No. The nightmare is classification.
 
 It's perfectly possible to put conductive ink on a board with a silkscreen 
 process.
 No problem here. Just define that conductive ink as copper or conductive
 type layer. I don't care how that layer happens to be manufactured.
 
 No. For describing geometry, I agree that the manufacturing process is 
 irrelevant. But the layer needs properties, not some arbitrary 
 classification.
 
 I never said that you cannot add additional properties(attributes) to
 the layers. I am just saying that there should be some, as you say,
 arbitrary classification. And than you refine that clasification by some
 properties. But the basic classification will be clean and understood by
 all parts of pcb. The additional properties can be admited just by some
 parts.

That's a design approach that leads to metastatic problems down the road. You 
should avoid the sloppy mental tendency of humans to classify where nature is 
continuous.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske





On Mar 18, 2011, at 2:19 PM, DJ Delorie d...@delorie.com wrote:

 
 I don't want to end up with the current state that some 'specialy
 named' layers receive special treatment.
 
 From a practical standpoint, I think it makes sense to have a fast way
 to scan for layers of some high-level type, as well as further typing
 them by name.
 
 My original design had an enumerated type for each drawing layer, that
 was one of (for example) copper, silk, soldermask, paste, outline,
 other with flags for normal, inverted and an assignment to a
 physical layer (1..N).
 
 That way, when you're doing something compute-intensive like
 connectivity checks for auto-enforce drc clearance you aren't doing
 a bazillion string compares.
 
You can build a hash for storage in ram,  the file format uses strings.  This 
way you get fast integer math with flexibility of not needing to pre ordain 
types.  The cost is on import. Where everything is string compairasons.  This 
is a kind of premature optimization.

Steve

 Actions that are performed less often, like mapping a footprint to an
 element, can use a more open-ended string-attribute with more complex
 rules.
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske





On Mar 18, 2011, at 3:07 PM, DJ Delorie d...@delorie.com wrote:

 
 That's the kind of top down design that produces a tool that meets
 today's requirements in the minimum amount of time, but produces an
 inflexible tool limited to those requirements.
 
 And your kind of bottom-up design never gets done at all, because of
 impossible-to-meet requirements for unlimited flexibility.
 
Wow all my bottom up designs in shipping products must not exist  A few 
million users disagree.  Top down and bottom up are a preference, not set in 
stone.  FWIW I use both methods.  My diagnostic tools start by me normally 
building small useful functions that get then assembled into larger functions.  
The team working on the top down diagnostics gave up after my bottom up design 
for lab testing  was doing all that they planned and more. To top the cake, 
they implemented a feature that they were expecting to take two weeks in about 
45 minutes because my bottoms up design had functions that were the bulk of 
what they needed.

 But if you start from a data representation that spans the space of
 the possible, it drives you toward flexibility and extensibility in
 the upper layers.
 
 The problem is, the space of the possible is infinitely large, and
 we have a very small finite set of developers.  Unless we know how the
 tool is going to be used, we don't even know what the space of the
 possible *is*.
 
 
Being an engineer is partly knowing when enough is ready to ship.  Bottom up 
designs do have high level goals,  it's our job to keep feature creep at a 
minimum. 

As far as I know I have only asked for file format requirements that are used 
in current technology mass-produced boards and for extra data to allow the 
manufacturing and simulation to be enhanced.

Layer materials and diamentions to allow impedance measurement in object 
reports 

Steve


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske





On Mar 18, 2011, at 3:22 PM, Stephan Boettcher boettc...@physik.uni-kiel.de 
wrote:

 DJ Delorie d...@delorie.com writes:
 
 ... I think the tool we have is pretty good already. Very good.  Thanks!
 
 The tool we have already is nearly impossible to maintain, though.
 
 Please do not expect that users write plugins.  The tool is already too
 good as it is to make is worth the effort to learn how to do that.
 
 I expect the plugin mechanism to be the way to write *all* the core
 bits, though. 
 
 The more important it is, that what is below the plugin mechanism is as
 general as necessary, and since that is difficult to judge up front: as
 general as possible, without compromising the final goals.
 
 I'd propose a very basic, very general storage data representation.
 Just layers, shapes, and arbitray levels of composites, the layout
 implicitly being the top level composit. Everything with arbitrary
 attributes.
 
 On top of that is a memory representation, that introduces the concepts
 of elements, vias, surface-layers (layer sets: copper, mask, silk,
 courtyard, keepout), connectivity,   
 
 It provides basic operations on these concepts.  The implementation of
 these concepts builds on the objects of the storage data layers.  It
 must not be an error if a via has two holes, a polygon shaped hole or
 silk in it.  DRC may flag such things, but it must not be an error.

Ahh, dreaming of a via that is untented, circled automatically, and net named.  
Instant testpoint!  Perhaps by a testpoint tool,  that would make pads centered 
on a trace with the same properties.

 The attributes that this memory representation and it methods understand
 shall be in namespace pcb: and unknown attributes in that namespace
 shall emit warnings.


 
 The plugins define their own attributes.  Attributes shall not be
 overloaded.  If a plugin operates on attributes of the memory
 representation, it shall do that via methods of that representation, if
 possible.  
 
 Higher level parts of the concepts element, via, surface layer
 may be implemented in plugins.
 
 
 
 
 I cannot keep up, there are 15 new messages in my inbox, lets see what
 what new arguments come up :-)
 
 I cannot make up my mind if I should continue to argue for hole layers,
 or if holes shall be shapes with hole attribute on layers.
 
 The fact that the *user* can write them *also* is a side-effect :-)
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
 
 -- 
 Stephan Böttcher FAX: +49-431-85660
 Extraterrestrische PhysikTel: +49-431-880-2508
 I.f.Exp.u.Angew.Physik   mailto:boettc...@physik.uni-kiel.de
 Leibnizstr. 11, 24118 Kiel, Germany
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske





On Mar 18, 2011, at 3:43 PM, DJ Delorie d...@delorie.com wrote:

 
 I expect the plugin mechanism to be the way to write *all* the core
 bits, though. 
 
 The more important it is, that what is below the plugin mechanism is as
 general as necessary, and since that is difficult to judge up front: as
 general as possible, without compromising the final goals.
 
 As general as neccessary, but not as general as *possible*.
 
 On top of that is a memory representation, that introduces the concepts
 of elements, vias, surface-layers (layer sets: copper, mask, silk,
 courtyard, keepout), connectivity,   
 
 This is the part I wish we were discussing.
 
 It provides basic operations on these concepts.  The implementation of
 these concepts builds on the objects of the storage data layers.  It
 must not be an error if a via has two holes, a polygon shaped hole or
 silk in it.  DRC may flag such things, but it must not be an error.
 
 There must be *some* limits, however, or the tools cannot be written.
 Defining a hole in a silk layer is nonsensical, if you wish to
 support it, we cannot define what the tools would do with it.
 
I would make it mask out the area that is defined as the hole.  Can't put silk 
on a hole.  ( in the gerber exporter )

 The attributes that this memory representation and it methods
 understand shall be in namespace pcb: and unknown attributes in
 that namespace shall emit warnings.
 
 You assume that attributes are the way to organize groups of things.
 Why?
 
 Higher level parts of the concepts element, via, surface layer
 may be implemented in plugins.
 
 How does a move tool plugin interact with an element plugin, then?
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske





On Mar 18, 2011, at 4:02 PM, DJ Delorie d...@delorie.com wrote:

 
 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.
 
 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)?
 
 * A sub-circuit that's replicated N times on a board.
 
 * 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.
 
 * buried vias are limited to certain pairs of layers because of the
  way the fab is assembling the board.
 
 * 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.
 
 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.
 
 Now consider a differential pair.  It's a line but you *don't* move
 the *line* endpoints, you move the *pair* control points.
 
 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.
 

I read this as groups in the memory model should have a sort of locked flag,  
so that tools like move don't dig deeper to move the individual parts of a 
group,  unless forced (unlocked).  And that groups need group control point(s)


 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.
 
I see a load time generated list of objects in a layer.  That gets added to and 
removed from doubly linked to the composites the objects belong to.  This would 
allow the object to manipulate the list and for the list to get right to the 
object.

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


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske





On Mar 18, 2011, at 4:17 PM, Stephan Boettcher boettc...@physik.uni-kiel.de 
wrote:

 DJ Delorie d...@delorie.com writes:
 
 I expect the plugin mechanism to be the way to write *all* the core
 bits, though. 
 
 The more important it is, that what is below the plugin mechanism is as
 general as necessary, and since that is difficult to judge up front: as
 general as possible, without compromising the final goals.
 
 As general as neccessary, but not as general as *possible*.
 
 But we cannot know what is necessary.
 
 On top of that is a memory representation, that introduces the concepts
 of elements, vias, surface-layers (layer sets: copper, mask, silk,
 courtyard, keepout), connectivity,   
 
 This is the part I wish we were discussing.
 
 As John said, bottom up works better in the long term :-)
 
 It provides basic operations on these concepts.  The implementation of
 these concepts builds on the objects of the storage data layers.  It
 must not be an error if a via has two holes, a polygon shaped hole or
 silk in it.  DRC may flag such things, but it must not be an error.
 
 There must be *some* limits, however, or the tools cannot be written.
 Defining a hole in a silk layer is nonsensical, if you wish to
 support it, we cannot define what the tools would do with it.
 
 Why not?  The tool can move it arount and not much else, like with all
 objects on a sliklayer.
 
 But that's why I argue for hole layers. A hole is a shape on a hole
 layer.  The layers attributes define what needs to be drilled.
 Actually, they only define to which layers they electrically conduct.
 That is all the tools needs to know until checkout.  DRC checks if all
 shapes are circles, unless the shape has a DRC overide attribute.
 
 There would be one hole layer for each drill pattern, i.e., one, unless
 there are partial vias.  John's insulating layers will be mentioned in
 the attributes, so they get drilled too.
 
What you call a hole layer is what I consider the insulating layer.

Or do your hole layers span physical layers? Mimicking the ability of the 
process.  (required to make the blind and burried vias your design dictates)

Side note,  the full stackup is a core part of the pcb design and should be 
chosen at an early stage.  Meaning that all the materials are chosen and 
dimensioned.

An example is: a four layer board is two double sided boards with prepreg 
between.  Such that the top copper, fr4, and second layer are a hole layer.  
The bottom copper, fr4, and third copper layer are the next hole layer.  And 
the third hole layer is the top copper all the way to the bottom copper?


 A via with variable hole size for different layers must be built as a
 composit with multiple holes on as many hole layers. Inefficient but
 appropriate for such an obscure case.
 
 The attributes that this memory representation and it methods
 understand shall be in namespace pcb: and unknown attributes in
 that namespace shall emit warnings.
 
 You assume that attributes are the way to organize groups of things.
 Why?
 
 So that everything is just shapes on layers. Very simple, very powerful.
 
 Higher level parts of the concepts element, via, surface layer
 may be implemented in plugins.
 
 How does a move tool plugin interact with an element plugin, then?
 
 The memory core representation provides methods to move, rotate, mirror
 shapes and composits.  (Element composits may have an attribute that
 forbids mirroring.)  To bring an element to the other side od the board
 is method of the Element plugin, relying on attributes of the relevant
 layers how they map to the other side.
 
 I don't think that the concept of vias and elements shall be fully
 implemented in plugins, for efficiency, and since most other plugings
 may need refer to these concepts.  At least some callback hooks need to
 be specific to elements or vias, that a plugin can register. So that a
 plugin can intercept composite methods (e.g., move) for elements or
 vias.
 
 
 -- 
 Stephan
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske





On Mar 18, 2011, at 4:37 PM, DJ Delorie d...@delorie.com wrote:

 
 Still, I do not see a need for outline layers anywhere, except as an
 attribute on a graphical layer that tells an exporter where to stop
 drawing.
 
 Hmmm... so you think PCB should let the user place an element in a
 physically impossible location, because it doesn't care about the
 outlines?
 
Yes,  I hate how pcb used to limit moving footprints silk off the edge of a 
board.   Yes easily solved by adding the outline layer.

It is also useful for staging your placement. 

Perhaps color portion off of the outline of it's base layer?  In other words, 
if you place an element over a transition from rigid to flex, where the rigid 
or flex that has the most pins is defined as the base layer,  I have used 
flexes where components are on the flex portion.  Avoid resistors and ceramic 
caps,  they tend to get their end caps ripped off, bit a sc-70 works fine 
usually.
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske





On Mar 18, 2011, at 4:39 PM, DJ Delorie d...@delorie.com wrote:

 
 It is the exporter's job to understand drilling. For geometry
 capture, all you need to know is the shape. Modules with no need to
 know should not know.
 
 The autorouter needs to know not to run traces across unplated
 holes...
 
This is what bothers me about a hole layer,  un plated vs plated,  the holes do 
not define electrical contact, the plating does.

Or, rivits, or the soldered wires on hand assembled multilayer boards.

Well with silver ink circuit printing. The hole in the sprayed on insulators 
does define the connectivity
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske
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 boettc...@physik.uni-kiel.de 
wrote:

 DJ Delorie d...@delorie.com 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, 

Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske





On Mar 19, 2011, at 8:13 AM, John Doty j...@noqsi.com wrote:

 
 On Mar 19, 2011, at 4:57 AM, Markus Hitter wrote:
 
 BTW., there were electronic circuitries before PCBs were invented and the 
 future of electronics manufacturing is most likely something 
 three-dimensional, arbitrarily shaped.
 
 Yes. I'm now working with two groups that are fabricating parts with 3-D 
 printers. I've been wondering when the technology will reach the point 
 where the printing could include conductors, with components placed during 
 the build-up, and then buried. 
 
Put in a conductive silver epoxy nozzle and a pick and place head,  bam your 
done!

:-)


 But I suppose describing this is beyond what we can conceptualize here at 
 this time. Planes are difficult enough.

You would add this capability to something like solid works.

 
 John Doty  Noqsi Aerospace, Ltd.
 http://www.noqsi.com/
 j...@noqsi.com
 
 
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread John Doty

On Mar 19, 2011, at 1:20 PM, Steven Michalske wrote:

 This is what bothers me about a hole layer,  un plated vs plated,  the holes 
 do not define electrical contact, the plating does.
 
 Or, rivits, or the soldered wires on hand assembled multilayer boards.
 
 Well with silver ink circuit printing. The hole in the sprayed on insulators 
 does define the connectivity
 

This demonstrates a flaw in the hole layer concept. It doesn't actually 
capture the geometry. But if the layers are physical, the objects in them might 
have different properties. So a plated-through hole is geometrically a place in 
a layer that is mostly insulator, but has a conductive annulus at a particular 
place.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske





On Mar 19, 2011, at 9:50 AM, Martin Kupec martin.ku...@kupson.cz wrote:

 On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:
 
 On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:
 
 If layers types would be defined by attributes, someone would be able to
 declare one layer both as conductive and as silk for example. That could
 cause me a nighmares. That is why I insist on 'typed' layers, not
 'tagged' layer.
 
 No. The nightmare is classification.
 
 It's perfectly possible to put conductive ink on a board with a silkscreen 
 process.
 No problem here. Just define that conductive ink as copper or conductive
 type layer. I don't care how that layer happens to be manufactured.
 

Simulation!  As long as the parameters can be specified then were good.

And when I say simulation it can be either a exporter to a field solver for 
antennas,  or a trace width calculator for current limits used while specifying 
line widths. i.e. Not an exporter.

Imagine drawing a trace with a width of 50 ohms single ended to ground.  When 
you move layers it would make the correct via with the proper clearances to the 
plane.  The realtime DRC prevents you from crossing the edge of your reference 
plane.  And when your top layer is separated from the ground plane by .2 mm of 
FR4 it know the width,  and when it dropped to layer 3 between 2 planes it 
asked how to calculate the trace.  Referenced to one or both.  Or it could have
Known that the separation of 1mm from layer 4 plane was enough not to consider 
it.

Ahh, that would be fantastic!
Martin Kupec
 
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread Steven Michalske





On Mar 19, 2011, at 12:33 PM, John Doty j...@noqsi.com wrote:

 
 On Mar 19, 2011, at 1:20 PM, Steven Michalske wrote:
 
 This is what bothers me about a hole layer,  un plated vs plated,  the holes 
 do not define electrical contact, the plating does.
 
 Or, rivits, or the soldered wires on hand assembled multilayer boards.
 
 Well with silver ink circuit printing. The hole in the sprayed on insulators 
 does define the connectivity
 
 
 This demonstrates a flaw in the hole layer concept. It doesn't actually 
 capture the geometry. But if the layers are physical, the objects in them 
 might have different properties. So a plated-through hole is geometrically a 
 place in a layer that is mostly insulator, but has a conductive annulus at a 
 particular place.
 
Oh my!  You can draw The plating on the insulator layer. Thus making the 
plating a real object of conductor This is more 3d cad leaking through.

That would mean that drawing on a insulator/separator would define some 
material to replace the seperator with,  and they would need properties.  
Plated through hole, conductive epoxy filled, thermal epoxy filled.

The drawn shapes would need properties 

The exporter would see a hole and it's anulis and drill a hole the size of the 
anulis or hole based on a flag in the exporter about the fab shop's preference 
on finished or drill sizes.

Edge plating would be a line drawn at the egge of the board that moved in the 
outline of the pcb by the plating thickness.

A plating tool could be made to draw the required shapes on each layer through 
the board.  Like the copper trace on the copper layers to plate to and the 
plating on the insulator.

 John Doty  Noqsi Aerospace, Ltd.
 http://www.noqsi.com/
 j...@noqsi.com
 
 
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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


Re: gEDA-user: General Layers questions

2011-03-19 Thread John Doty

On Mar 19, 2011, at 2:03 PM, Steven Michalske wrote:

 Oh my!  You can draw The plating on the insulator layer. Thus making the 
 plating a real object of conductor This is more 3d cad leaking through.

DJ once made the observation that pcb's basic problem is the lack of a proper 
layer stackup abstraction. My opinion is that designing for metaphysical 
pseudo-layers like the proposed hole layer is a major barrier to correctly 
modeling a circuit board as a layered stack. Stacking of plane layers is 
fundamentally a 3D concept.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-19 Thread John Doty

On Mar 18, 2011, at 2:25 PM, DJ Delorie wrote:

 Inkscape gives you complete flexibility, and it's absolutely useless
 as a pcb layout tool.

Indeed. So please remember that the job of a layout tool is to describe the 
*geometry* of *physical* objects. It's *not* just a graphical tool, nor should 
it describe the fabrication procedure. Its foundations must be based on 
geometric abstractions, not metaphysical intentions. It seems to me that your 
conception is much closer to Inkscape than mine is.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Wed, Mar 16, 2011 at 02:09:43AM -0700, Steven Michalske wrote:
 Looking at the layers I would like to propose that the copper layer be
 made not specific to copper, but a conductor.
 Some common alternatives are silver ink traces, embedded resistors, or
 even more exotics like ITO (used for touch screens).
Ok. I will just rename it to 'conductive' layer.
 
 
 For the footprints,
 They should have a routing keepout, different than a  placement
 courtyard.  That is don't rout on these layers in these regions.
The 'countryard' layer should be exactly the keepout layer.
Silk layer is used for normal visible spacing of the component.
 
 Pins and pads should have antipads  that is when the pin goes through
 a plane this antipad is the area in the plane that is cut out for the
 pad on that layer.
 High speed signals often have the ground plane under the pad removed
 to minimize the capacitance/impedance change from the pad's greater
 area.
You can define more copper(now conductive) layers for one footprint.
And some of them can be negative. The only problem to solve is to define
some good mapping.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 The 'countryard' layer should be exactly the keepout layer.

They're two different purposes, though.  The courtyard is for physical
placement restrictions, the keepout is for copper routing
restrictions.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Wed, Mar 16, 2011 at 01:51:36AM -0700, Steven Michalske wrote:
 As for mask and paste layers, we may want to have a way for an object
 in one layer be a transformed version of another layer.
 
 Example, clearing solder mask for a line, or pad, or whatever would
 create a linked object in the adjacent mask layer with a growth in
 size of size X.
 Where X can be 10% or could be +10mil.  Just a basic transform.
I want to have a tool for copying one elements from one layer to
another one. So this will be easily achievable.
 
 
 On a side note,  how could we make special track parameters available?
  Meaning differential and single ended impedance.  Like drawing a uber
 trace that is really a matched diff pair.
 That is a composite trace that is drawn as a virtual trace.

I have no idea how to do this specificly, but it seems that I will
have to introduce some concept of composite object. So I can take this
in consideration.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 01:51:42PM -0400, DJ Delorie wrote:
 
  The 'countryard' layer should be exactly the keepout layer.
 
 They're two different purposes, though.  The courtyard is for physical
 placement restrictions, the keepout is for copper routing
 restrictions.
Right. You are right. I forgot about this :-(.

Ok, so let's have another type of layer (one plus/minus doesn't matter
how when we already have a few of them).

Any name suggestion? Probably for both of the 'countryard's

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
DJ Delorie d...@delorie.com writes:

 The 'countryard' layer should be exactly the keepout layer.

 They're two different purposes, though.  The courtyard is for physical
 placement restrictions, the keepout is for copper routing
 restrictions.

The file format need not know about these distictions.  Both are
graphical layers, with different attributes.  The one has attributes to
tell DRC to flag overlapping components, the other has attributes to
tell some autorouter not to put copper there, and attributes to tell DRC
to check for intruding copper.  Future plugins need more layers to tell
about different constraints.

Ideally, any layer type is fully defined via attributes.  The most
common attribute may be net:conductive for normal copper layers, so
that the HIDs know that the layer contributes to the implementation of
the netlist.  Copper layers need a second attribute gbr:layer=inner5
to tell the (gerber) exporter where to put it.  A third attribute
defines the DRC rules that apply drc:rules=default, plus per layer
override drc:minwidth=6mil.

drc:courtyard=front
drc:keepout=front
route:keepout=front


-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote:
 The file format need not know about these distictions.  Both are
 graphical layers, with different attributes.  The one has attributes to
 tell DRC to flag overlapping components, the other has attributes to
 tell some autorouter not to put copper there, and attributes to tell DRC
 to check for intruding copper.  Future plugins need more layers to tell
 about different constraints.
 
 Ideally, any layer type is fully defined via attributes.  The most
 common attribute may be net:conductive for normal copper layers, so
 that the HIDs know that the layer contributes to the implementation of
 the netlist.  Copper layers need a second attribute gbr:layer=inner5
 to tell the (gerber) exporter where to put it.  A third attribute
 defines the DRC rules that apply drc:rules=default, plus per layer
 override drc:minwidth=6mil.
 
 drc:courtyard=front
 drc:keepout=front
 route:keepout=front


That is a bit complicated. I need a clean definition of layer types, so
one can pick the right layer when needed. But some attributes in
addition to layer type are possible.

Each element has a clearance attribute, so definition of extra space
around pads should be easy. But we can add 'keepout' layer in addition.

Even when we would have more layer, it should be simplier to implement
them than some arbitrary flags.

Defining DRC rules per layer is a bit different story and I hope it will
not be too closely related to changing of layer concept, as I don't want
to touch DRC.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote:
 
 On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote:
 
  Ok. So via should be a circle element on hole typed layer.
  
  No.  A Via is a composit, consisting of a circle on the hole layer, and
  various circles on copper layers, and circles on mask layes, and
  thermals.
 
 The layer concept should be physical, not a metaphysical abstraction. 
 Objects in a layer may contain holes, but a hole layer is nonsensical, a 
 toxic conceptual shortcut. An outline layer is similarly bad: the 
 insulating layers may all have the same shape sometimes, but not always.

The outline layer will be part of 'physical' layer. So if you have 2
'physical' layers with different shape, it will play nicely.

What I am prosposing is 2 level concept. There will be 'physical'
layers, so you can add properties to them. And than there will be
'drawing' surfaces. And 'outline' is just drawing suface telling the
'physical' layer it's edges.

But I am not convinced that we need special 'hole' typed layer. Maybe we
can things like 'holes' which are not part of any specific layer just
float in space. I thing that it would work.
 
 Trying to model things that aren't layers as if they were layers is one 
 common mistake in this kind of tool. Equally common is leaving out layers: 
 the insulating layers in a PCB are just as important as the copper, and have 
 their own properties (shape, thickness, material, etc.). They're a critical 
 part of the layer stack.

The problem I see with the insulating layers is that there is nothing on
them...So you don't need them as 'drawing' layers. But I agree that
there should be a way how to add some attributes to them.
 
 The description language needs to be able to express feature p in layer x is 
 aligned with feature q in layer y in order to build up composites. This is 
 the geometrically sensible way to describe the result of drilling through 
 several layers. But the geometric description language should not be tied to 
 any particular fabrication procedure.

I agree with this one.



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Wed, Mar 16, 2011 at 06:09:25PM +0100, Stephan Boettcher wrote:
 For me, a layer is something that the designer puts shapes on.  Shapes
 with atributes, if required.  The semantics of these shapes on a given
 layer shall all be the same.  Some of these are required for netlisting,
 some are steering the physical checkout.

I agree with this one. We are just describing drawing surfaces and the
meaning of elements on that sufrace are defined by type of that sufrace.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread John Doty

On Mar 16, 2011, at 11:09 AM, Stephan Boettcher wrote:

 John Doty j...@noqsi.com writes:
 
 The layer concept should be physical, not a metaphysical
 abstraction. Objects in a layer may contain holes, but a hole layer
 is nonsensical, a toxic conceptual shortcut. An outline layer is
 similarly bad: the insulating layers may all have the same shape
 sometimes, but not always.
 
 So, a via needs a separate hole in each copper and insulating layer?  And
 each layer needs its own discription of it's shape?

Just as a program needs to know that every object in an array of integers is an 
integer. The composition machinery is responsible for keeping track: you don't 
need to declare each array element separately.

 
 Trying to model things that aren't layers as if they were layers is
 one common mistake in this kind of tool. Equally common is leaving out
 layers: the insulating layers in a PCB are just as important as the
 copper, and have their own properties (shape, thickness, material,
 etc.). They're a critical part of the layer stack.
 
 The description language needs to be able to express feature p in
 layer x is aligned with feature q in layer y in order to build up
 composites. This is the geometrically sensible way to describe the
 result of drilling through several layers. But the geometric
 description language should not be tied to any particular fabrication
 procedure.
 
 This is all too physikal for my taste.

I assert that if you do it any other way, you wind up with the following 
catastrophe: the code for every layer type needs to incorporate a specific 
definition of its interaction with the code for every other layer type. A total 
collapse of factoring, poisoning flexibility and maintainability. But if layers 
correspond to actual geometric layers, this can be avoided, I believe.

 
 Why are you so attached to the concept of drilling?

I'm not. Indeed, I would urge our developers to purge the idea that a hole 
implies a drill from their minds when considering geometry. Export to 
instructions for a specific fabrication technology is a different problem from 
geometry capture, and in well factored software these will be kept separate.

  For the design of a
 layout, all that matters is that there are conductive connections
 between layers. 

At the netlist level, that's all that matters. But at the layout level, it's 
geometry that matters.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
Generaly you are proposing that there should be a special type of
footpring called 'via' and it should receive extra care.

I am ok with that, I just need to figure out how to handle mapping from
footprint layers to layout layers. I don't want concept of 'top',
'inner', 'bottom' layer at all...that is too naive for me.

Martin Kupec
On Wed, Mar 16, 2011 at 11:24:42AM +0100, Stephan Boettcher wrote:
 Martin Kupec martin.ku...@kupson.cz writes:
 
  On Wed, Mar 16, 2011 at 02:42:26AM +0100, Stephan Boettcher wrote:
  IMHO, .. holes are circles draw on just another layer.  People were
  asking for slots.  If they find a vendor to do them, they may just draw
  lines on that layer as well.  Else, DRC shall flag non-circles.
  
  Each such hole layer shall have a spec (attribute) to which (copper)
  layers they electrically connect.  There will be at least one such layer
  for each type of blind, burried, and through via.
  
  The GUI will happily stack vias according to the selected routing style
  into a composites and paste them on the layout, so for simple cases
  nothing changes from how we work now.
 
  Ok. So via should be a circle element on hole typed layer.
 
 No.  A Via is a composit, consisting of a circle on the hole layer, and
 various circles on copper layers, and circles on mask layes, and
 thermals.
 
 A library (routing style) Via would have top, inner, (outer?), bottom
 copper layers, which would be mapped to physical copper layers of the
 layout according to some mapping, exactly as for footprints.
 
 In addition, some projects would have their own sets of Vias in a
 library, where those circles are expressed explicitly for the physical
 hole/coper layers of that board, for burried and blind vias, or special
 annular ring config on certain inner layers. That library shall be
 linked to some Via GUI to efficiently choose from.
 
  That object will have some description to which layers of type cooper it
  belongs to. 
 
 The hole _layer_ should have that description.  The default connects to
 all copper.  Blind and burried vias require extra hole type layers, one
 for each set of drill stacks.  This information is needed for
 connectivity checks mostly.  Some DRC check may verify if the drilling
 of the stacks is feasible.
 
 I think this is simpler and more flexible that DJs proposal: to
 hierachically group (copper) layers into drill stacks.  That would be a
 John D violation, since it originates from a narrow view on how PCBs are
 manufactured.  It in no problem to reflect such a narrow view in a DRC
 rule, but it is a mistake to cast it into the core data structure.  A
 HID may present the layers in such an arangement to the user. Said HID
 may then proceed to add the required hole layers and Via types
 automatically, after the user pushed the copper layers around as
 required for the project.
 
  And how would you describe the cooper around via on each layer?
  Someone wanted different cooper size/shape on different layers.
 
 
  Martin Kupec
 
 -- 
 Stephan
 
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread John Doty

On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote:

 Generaly you are proposing that there should be a special type of
 footpring called 'via' and it should receive extra care.

Why single out via and footprint when they are merely members of an 
open-ended list of possible composite objects?

 
 I am ok with that, I just need to figure out how to handle mapping from
 footprint layers to layout layers. I don't want concept of 'top',
 'inner', 'bottom' layer at all...that is too naive for me.

A general mechanism for describing composite objects is needed.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 Why single out via and footprint when they are merely members of
 an open-ended list of possible composite objects?

Because a tool that doesn't deal with real-world concepts in a
user-friendly way is unusable.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 01:44:35PM -0600, John Doty wrote:
  Trying to model things that aren't layers as if they were layers is
  one common mistake in this kind of tool. Equally common is leaving out
  layers: the insulating layers in a PCB are just as important as the
  copper, and have their own properties (shape, thickness, material,
  etc.). They're a critical part of the layer stack.
  
  The description language needs to be able to express feature p in
  layer x is aligned with feature q in layer y in order to build up
  composites. This is the geometrically sensible way to describe the
  result of drilling through several layers. But the geometric
  description language should not be tied to any particular fabrication
  procedure.
  
  This is all too physikal for my taste.
 
 I assert that if you do it any other way, you wind up with the following 
 catastrophe: the code for every layer type needs to incorporate a specific 
 definition of its interaction with the code for every other layer type. A 
 total collapse of factoring, poisoning flexibility and maintainability. But 
 if layers correspond to actual geometric layers, this can be avoided, I 
 believe.

Actually what I am trying to do, is to have concept so layers don't
interract with layers of different type. The composits are a bit
problem, because I would need to consider more layers when performing any
action, but I think that it can still be interaction with object on the
same layer.

So, i.e., If we would have 'hole' layer. I would have check, that holes
on hole layer are not intersecting. And also check the intersection of
attached shapes on each layer. But all what can happen is that some
layer will yell that something bad happend and I should cancel my
action.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
Martin Kupec martin.ku...@kupson.cz writes:

 On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote:
 The file format need not know about these distictions.  Both are
 graphical layers, with different attributes.  The one has attributes to
 tell DRC to flag overlapping components, the other has attributes to
 tell some autorouter not to put copper there, and attributes to tell DRC
 to check for intruding copper.  Future plugins need more layers to tell
 about different constraints.
 
 Ideally, any layer type is fully defined via attributes.  The most
 common attribute may be net:conductive for normal copper layers, so
 that the HIDs know that the layer contributes to the implementation of
 the netlist.  Copper layers need a second attribute gbr:layer=inner5
 to tell the (gerber) exporter where to put it.  A third attribute
 defines the DRC rules that apply drc:rules=default, plus per layer
 override drc:minwidth=6mil.
 
 drc:courtyard=front
 drc:keepout=front
 route:keepout=front


 That is a bit complicated. I need a clean definition of layer types, so
 one can pick the right layer when needed. But some attributes in
 addition to layer type are possible.

I do not understand that argument.

 Each element has a clearance attribute, so definition of extra space
 around pads should be easy. But we can add 'keepout' layer in addition.

 Even when we would have more layer, it should be simplier to implement
 them than some arbitrary flags.

 Defining DRC rules per layer is a bit different story and I hope it will
 not be too closely related to changing of layer concept, as I don't want
 to touch DRC.

   Martin Kupec



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

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 01:52:24PM -0600, John Doty wrote:
 
 On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote:
 
  Generaly you are proposing that there should be a special type of
  footpring called 'via' and it should receive extra care.
 
 Why single out via and footprint when they are merely members of an 
 open-ended list of possible composite objects?

We need to single out 'via' so someone who want's simple board can find
'via' tool as everywhere. And under word 'footprint' I mean any other
composite object.

 
  
  I am ok with that, I just need to figure out how to handle mapping from
  footprint layers to layout layers. I don't want concept of 'top',
  'inner', 'bottom' layer at all...that is too naive for me.
 
 A general mechanism for describing composite objects is needed.
I agree. But we are trying to figure out how.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Steven Michalske
On Fri, Mar 18, 2011 at 12:52 PM, John Doty j...@noqsi.com wrote:

 On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote:

 Generaly you are proposing that there should be a special type of
 footpring called 'via' and it should receive extra care.

 Why single out via and footprint when they are merely members of an 
 open-ended list of possible composite objects?


 I am ok with that, I just need to figure out how to handle mapping from
 footprint layers to layout layers. I don't want concept of 'top',
 'inner', 'bottom' layer at all...that is too naive for me.

 A general mechanism for describing composite objects is needed.


I agree here, that a via and a footprint are essentially the same thing.

A via is a hole through some layers of the board and some copper bits
on those layers,  also known as a pad stack in some board packages.

A footprint is traditionally a grouping of many pad stacks and
additional layers.

No real special treatment in the descriptions of the geometry.

A group that origin is at x,y,rotation,layer

Make a generic group (sub layout) concept and your good to go.

A round via should have a rotation,  it allows easy control of the
thermals orientation.

This is not to say that a special via macro could not be setup that
makes the simplest traditional via or blind/buried vias.

These groups should not be flattened into the layout until export,
thus we loose the free rotate issue that we have today (lossy
rotations).


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread John Doty

On Mar 18, 2011, at 1:53 PM, DJ Delorie wrote:

 
 Why single out via and footprint when they are merely members of
 an open-ended list of possible composite objects?
 
 Because a tool that doesn't deal with real-world concepts in a
 user-friendly way is unusable.
 

I completely agree. So that's why clean composition machinery is needed, 
because *your* needs don't correspond to anybody else's, when it comes down to 
details. Inflexible wired-in behavior makes a mess (as in gschem's slotting 
feature, for example).

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Steven Michalske
On Fri, Mar 18, 2011 at 12:53 PM, DJ Delorie d...@delorie.com wrote:

 Why single out via and footprint when they are merely members of
 an open-ended list of possible composite objects?

 Because a tool that doesn't deal with real-world concepts in a
 user-friendly way is unusable.


User friendly is a subjective qualifier.

IMHO:
free rotate buffer is not user friendly.
Where a group(collection) that has a specific rotation parameter is.


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



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 I agree here, that a via and a footprint are essentially the same
 thing.

Except the user doesn't interact with them the same way.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
DJ Delorie d...@delorie.com writes:

 Why single out via and footprint when they are merely members of
 an open-ended list of possible composite objects?

 Because a tool that doesn't deal with real-world concepts in a
 user-friendly way is unusable.

Yes.  The real world concepts must exist, in a higher level.  In the
attributes.  The HIDs must implement them in a user-friendly way.  At
the lowest level, there shall be abstractions. 

The GUI must present footprints, vias, and hierachical sublayouts, both
in copy on write and in truly hierachical fashion.  But at the core,
they work all just the same. Then there will be no more question if some
feature is supported in elements or not, or how convoluted a via may be.

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Steven Michalske
On Fri, Mar 18, 2011 at 1:08 PM, DJ Delorie d...@delorie.com wrote:

 I agree here, that a via and a footprint are essentially the same
 thing.

 Except the user doesn't interact with them the same way.

This is a UI representation, not a layer geometry issue.

A via tool that makes the proper composite object and stamps it at a
coordinate, is the via tool.  Even if the UI is a script interface, a
via macro in the layers file, or a GUI window and mouse pointer.

A footprint tool takes the composite from a library and stamps it down.


In the underpinnings the layers now has two composite objects, groups,
or what ever you want to call it at two locations on the layout.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Steven Michalske
On Fri, Mar 18, 2011 at 12:40 PM, Martin Kupec martin.ku...@kupson.cz wrote:
 On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote:

 On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote:

  Ok. So via should be a circle element on hole typed layer.
 
  No.  A Via is a composit, consisting of a circle on the hole layer, and
  various circles on copper layers, and circles on mask layes, and
  thermals.

 The layer concept should be physical, not a metaphysical abstraction. 
 Objects in a layer may contain holes, but a hole layer is nonsensical, a 
 toxic conceptual shortcut. An outline layer is similarly bad: the 
 insulating layers may all have the same shape sometimes, but not always.

 The outline layer will be part of 'physical' layer. So if you have 2
 'physical' layers with different shape, it will play nicely.

 What I am prosposing is 2 level concept. There will be 'physical'
 layers, so you can add properties to them. And than there will be
 'drawing' surfaces. And 'outline' is just drawing suface telling the
 'physical' layer it's edges.

 But I am not convinced that we need special 'hole' typed layer. Maybe we
 can things like 'holes' which are not part of any specific layer just
 float in space. I thing that it would work.

 Trying to model things that aren't layers as if they were layers is one 
 common mistake in this kind of tool. Equally common is leaving out layers: 
 the insulating layers in a PCB are just as important as the copper, and have 
 their own properties (shape, thickness, material, etc.). They're a critical 
 part of the layer stack.

 The problem I see with the insulating layers is that there is nothing on
 them...So you don't need them as 'drawing' layers. But I agree that
 there should be a way how to add some attributes to them.


Embedded resistor and capacitors are in holes in the separating layers.

Some separating layers are more like a solder mask and sprayed down
rather than FR4 and prepreg.

Just because standard FR4 Fabs don't usually use any drawings on that
layer, should not preclude it.

Now the exporter may barf if it finds something it can't cope with,
like a line drawn on a separator layer.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Steven Michalske
On Fri, Mar 18, 2011 at 1:11 PM, Stephan Boettcher
boettc...@physik.uni-kiel.de wrote:
 DJ Delorie d...@delorie.com writes:

 Why single out via and footprint when they are merely members of
 an open-ended list of possible composite objects?

 Because a tool that doesn't deal with real-world concepts in a
 user-friendly way is unusable.

 Yes.  The real world concepts must exist, in a higher level.  In the
 attributes.  The HIDs must implement them in a user-friendly way.  At
 the lowest level, there shall be abstractions.

 The GUI must present footprints, vias, and hierachical sublayouts, both
 in copy on write and in truly hierachical fashion.  But at the core,
 they work all just the same. Then there will be no more question if some
 feature is supported in elements or not, or how convoluted a via may be.


I have had some convoluted vias for high speed signals.  different
diameters on different layers, with different clearances from the
surrounding planes.  And we really could have udes a DRC that checked
if the blind via ended on top of another signal trace.  High speed
noise coupled on to that trace.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
Martin Kupec martin.ku...@kupson.cz writes:

 On Fri, Mar 18, 2011 at 01:44:35PM -0600, John Doty wrote:
  Trying to model things that aren't layers as if they were layers is
  one common mistake in this kind of tool. Equally common is leaving out
  layers: the insulating layers in a PCB are just as important as the
  copper, and have their own properties (shape, thickness, material,
  etc.). They're a critical part of the layer stack.
  
  The description language needs to be able to express feature p in
  layer x is aligned with feature q in layer y in order to build up
  composites. This is the geometrically sensible way to describe the
  result of drilling through several layers. But the geometric
  description language should not be tied to any particular fabrication
  procedure.
  
  This is all too physikal for my taste.
 
 I assert that if you do it any other way, you wind up with the
 following catastrophe: the code for every layer type needs to
 incorporate a specific definition of its interaction with the code
 for every other layer type. A total collapse of factoring, poisoning
 flexibility and maintainability. But if layers correspond to actual
 geometric layers, this can be avoided, I believe.

What I like with PCB is that there is very little interaction.  Only
when special actions are called, the interactions are invoked.  E.g.,
when I hit the O key, the connectivity is evaluated.  For that I only
need to know which layers are conductive and what vias connect which
layers.

 Actually what I am trying to do, is to have concept so layers don't
 interract with layers of different type. The composits are a bit
 problem, because I would need to consider more layers when performing any
 action, but I think that it can still be interaction with object on the
 same layer.

I do not understand what problems you see with composits.  A layer
consists of the union of all shapes on any level of the composits
hierarchy.  Composits may be referenced at multiple positions, so those
shapes appear multiple times.  When a shape is modified in a composit,
it may affect all copies simultaniously, or the composit will be
duplicated (copy on write), depneding on an attribute or explicit user
action.

 So, i.e., If we would have 'hole' layer. I would have check, that holes
 on hole layer are not intersecting. And also check the intersection of
 attached shapes on each layer. But all what can happen is that some
 layer will yell that something bad happend and I should cancel my
 action.

Where do you want to attach holes. To layers, like John proposes?  To
shapes on a layer?  Or as independent entities, like they are now?  

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 Inflexible wired-in behavior

... is MANDATORY if you're going to produce a tool that's usable.

That's the difference between a pcb editor and, say, inkscape.

Inkscape gives you complete flexibility, and it's absolutely useless
as a pcb layout tool.

You seem to be totally blind to the theory that you can have
inflexible wired-in behavior *and* options for flexibility through
alternate mechanisms.  We need both - they are not mutually exclusive.
We need a tool that's easy to learn and use *and* has options for
power user.  Your maniacal lobbying for factoring and abstraction
would leave us with a tool that nobody would *want* to use.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote:
 Martin Kupec martin.ku...@kupson.cz writes:
 
  On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote:
  The file format need not know about these distictions.  Both are
  graphical layers, with different attributes.  The one has attributes to
  tell DRC to flag overlapping components, the other has attributes to
  tell some autorouter not to put copper there, and attributes to tell DRC
  to check for intruding copper.  Future plugins need more layers to tell
  about different constraints.
  
  Ideally, any layer type is fully defined via attributes.  The most
  common attribute may be net:conductive for normal copper layers, so
  that the HIDs know that the layer contributes to the implementation of
  the netlist.  Copper layers need a second attribute gbr:layer=inner5
  to tell the (gerber) exporter where to put it.  A third attribute
  defines the DRC rules that apply drc:rules=default, plus per layer
  override drc:minwidth=6mil.
  
  drc:courtyard=front
  drc:keepout=front
  route:keepout=front
 
 
  That is a bit complicated. I need a clean definition of layer types, so
  one can pick the right layer when needed. But some attributes in
  addition to layer type are possible.
 
 I do not understand that argument.

Ok. We probably don't understand each other, so I will just state my fears.

I would like to know about each drawing layer where it belongs to.

So when I am performing DRC check, I will know, that it is conductive
layer and I should consider it. I can take care of special DRC rules for
some conductive layers later.

If layers types would be defined by attributes, someone would be able to
declare one layer both as conductive and as silk for example. That could
cause me a nighmares. That is why I insist on 'typed' layers, not
'tagged' layer.

That example is probably silly, but someone would probably come up with
something more realistic, but still giving me nightmares.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
Martin Kupec martin.ku...@kupson.cz writes:

 On Fri, Mar 18, 2011 at 01:52:24PM -0600, John Doty wrote:
 
 On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote:
 
  Generaly you are proposing that there should be a special type of
  footpring called 'via' and it should receive extra care.
 
 Why single out via and footprint when they are merely members of
 an open-ended list of possible composite objects?

 We need to single out 'via' so someone who want's simple board can find
 'via' tool as everywhere. And under word 'footprint' I mean any other
 composite object.

That is up to the HID to find the composits with attribute
type=via, and present them in a via toll selector.

And to maintein an in memory list of composits of type=element and akt
on those when the users asks for elements.

  I am ok with that, I just need to figure out how to handle mapping from
  footprint layers to layout layers. I don't want concept of 'top',
  'inner', 'bottom' layer at all...that is too naive for me.

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 But at the core, they work all just the same.

The core includes the autorouters, optimizers, DRC, exporters,
reports, and even simple editing - we have a hide vias button.  How
does that work if you no longer have vias as an inherent type?

PCB has a lot of tools that know a lot about how PCBs are designed.
These tools are essential to making PCB a viable layout editor.  The
input we need at this stage is from people who design a lot of PCBs,
so we know what kinds of abstractions make sense to expose and what
kinds need to be hidden behind other data structures.

Maybe to the rendering engines they all work the same, but saying
they all work the same *in general* just isn't applicable here.
They don't.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Jared Casper
On Fri, Mar 18, 2011 at 1:23 PM, Martin Kupec martin.ku...@kupson.cz wrote:
 If layers types would be defined by attributes, someone would be able to
 declare one layer both as conductive and as silk for example. That could
 cause me a nighmares. That is why I insist on 'typed' layers, not
 'tagged' layer.

 That example is probably silly, but someone would probably come up with
 something more realistic, but still giving me nightmares.


But what if I want a silk layer to just be a copy of a copper layer?
That may be just as silly, but I'm sure someone could come up with a
use for it.  Why would such a layer cause nightmares?  When the code
is worried about connectivity etc., it sees this layer is tagged as
conductive and includes it in whatever its doing, ignoring the fact
that it is also silk.  When the code is putting out the silkscreen, it
notices this layer is tagged as silk and puts it out, ignoring that it
is also a conductive layer.

Jared


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 That is up to the HID to find the composits with attribute
 type=via, and present them in a via toll selector.

I disagree with this.

The HID is the Human Interaction Device - how the information is
presented to the user.  GUI, printer, etc.

The HID is the wrong place to be assigning *meaning* to the data.
That is still in the core.  The fact that some composites are vias
is something intrinsic to the pcb design, independent of what color
you make it on the screen, and independend of how vias are implemented
at the lowest internal levels.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 01:20:43PM -0700, Steven Michalske wrote:
 On Fri, Mar 18, 2011 at 1:11 PM, Stephan Boettcher
  The GUI must present footprints, vias, and hierachical sublayouts, both
  in copy on write and in truly hierachical fashion.  But at the core,
  they work all just the same. Then there will be no more question if some
  feature is supported in elements or not, or how convoluted a via may be.
 
 
 I have had some convoluted vias for high speed signals.  different
 diameters on different layers, with different clearances from the
 surrounding planes.  And we really could have udes a DRC that checked
 if the blind via ended on top of another signal trace.  High speed
 noise coupled on to that trace.

That is still ok, to consider it as 'composite object'.
There are just 2 problems.

1. The composite will really need different hole size on different layers.

2. There should be some clever DRC check added.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
Steven Michalske smichal...@gmail.com writes:

 On Fri, Mar 18, 2011 at 12:40 PM, Martin Kupec martin.ku...@kupson.cz wrote:
 On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote:

 On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote:

  Ok. So via should be a circle element on hole typed layer.
 
  No.  A Via is a composit, consisting of a circle on the hole layer, and
  various circles on copper layers, and circles on mask layes, and
  thermals.

 The layer concept should be physical, not a metaphysical abstraction. 
 Objects in a layer may contain holes, but a hole layer is nonsensical, a 
 toxic conceptual shortcut. An outline layer is similarly bad: the 
 insulating layers may all have the same shape sometimes, but not always.

 The outline layer will be part of 'physical' layer. So if you have 2
 'physical' layers with different shape, it will play nicely.

 What I am prosposing is 2 level concept. There will be 'physical'
 layers, so you can add properties to them. And than there will be
 'drawing' surfaces. And 'outline' is just drawing suface telling the
 'physical' layer it's edges.

 But I am not convinced that we need special 'hole' typed layer. Maybe we
 can things like 'holes' which are not part of any specific layer just
 float in space. I thing that it would work.

 Trying to model things that aren't layers as if they were layers is one 
 common mistake in this kind of tool. Equally common is leaving out layers: 
 the insulating layers in a PCB are just as important as the copper, and 
 have their own properties (shape, thickness, material, etc.). They're a 
 critical part of the layer stack.

 The problem I see with the insulating layers is that there is nothing on
 them...So you don't need them as 'drawing' layers. But I agree that
 there should be a way how to add some attributes to them.


 Embedded resistor and capacitors are in holes in the separating layers.

 Some separating layers are more like a solder mask and sprayed down
 rather than FR4 and prepreg.

 Just because standard FR4 Fabs don't usually use any drawings on that
 layer, should not preclude it.

 Now the exporter may barf if it finds something it can't cope with,
 like a line drawn on a separator layer.

If you have a foundry that does such things, probably you send them a
gerber layer and tell them that those are the embedded resistors between
copper 2 and 3.  And that other layer are those between copper 5 and 6.

No special exporter required.  But you must keep the drawing layers a
bit more abstract, else you confuse the tools that have invalid
assumptions.

The embedded resitors will be elements in a process specific library.
Not top/inner/bottom layers, that get mapped to the layer present in the
layout, but footprints with explicit layers.  Including a shape on the
resistive layer, and pads on the adjacent copper layers.

The pcb layout tool will not need to know anything about those embedded
devices.  They just emerge and work.  All you need is layers that are
not marked conductive.

And if those strange embedded deviced become common, somebody needs to
add some DRC rules, which at that time are just a few boolean ops on some
layers in a config file.

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Jared Casper
On Fri, Mar 18, 2011 at 1:32 PM, DJ Delorie d...@delorie.com wrote:
 The core includes the autorouters, optimizers, DRC, exporters,
 reports, and even simple editing - we have a hide vias button.  How
 does that work if you no longer have vias as an inherent type?


You go through and hide all the composites marked as a via.  For pcb
to deal with vias differently doesn't mean that vias needs to be
something fundamentally different than a footprint.

On Fri, Mar 18, 2011 at 1:38 PM, DJ Delorie d...@delorie.com wrote:
 The HID is the wrong place to be assigning *meaning* to the data.
 That is still in the core.  The fact that some composites are vias
 is something intrinsic to the pcb design, independent of what color
 you make it on the screen, and independend of how vias are implemented
 at the lowest internal levels.

From my reading of this conversation there is a disconnect between
what people are talking about w.r.t. words like the core.  Some are
talking about the lowest internal levels where a via can just be
another composite object.  Some are talking about everything in pcb
besides the gui, where do you need to distinguish a via from a
footprint.  While others seem to be using gui as everything but the
lowest internal levels

Jared


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 09:29:04PM +0100, Stephan Boettcher wrote:
 Martin Kupec martin.ku...@kupson.cz writes:
 
  On Fri, Mar 18, 2011 at 01:52:24PM -0600, John Doty wrote:
  
  On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote:
  
   Generaly you are proposing that there should be a special type of
   footpring called 'via' and it should receive extra care.
  
  Why single out via and footprint when they are merely members of
  an open-ended list of possible composite objects?
 
  We need to single out 'via' so someone who want's simple board can find
  'via' tool as everywhere. And under word 'footprint' I mean any other
  composite object.
 
 That is up to the HID to find the composits with attribute
 type=via, and present them in a via toll selector.
 
 And to maintein an in memory list of composits of type=element and akt
 on those when the users asks for elements.

Yes. With 'special care' I just ment in the GUI. Inside it will be
a compsoite object like any other.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 But what if I want a silk layer to just be a copy of a copper layer?

This is a different category of problem - the CAM job.  Typically,
you'd have a file that describes how to map design layers to output
layers.  In that file, you'd say this copper layer should be output
as a silk layer also.  Such a file could also say copper objects
with the also-paste attribute should be drawn on the paste layer etc.

At the design/edit level, that layer is a copper layer.  Note to John:
We just call them copper.  You can assume we mean any conductive
substance but people get the idea more reliably if you use terms
they're familiar with.

 When the code is worried about connectivity etc., it sees this layer
 is tagged as conductive and includes it in whatever its doing,
 ignoring the fact that it is also silk.  When the code is putting
 out the silkscreen, it notices this layer is tagged as silk and puts
 it out, ignoring that it is also a conductive layer.

And DRC freaks out because it has two separate incompatible sets of
rules to apply to it.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
Martin Kupec martin.ku...@kupson.cz writes:

 On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote:
 Martin Kupec martin.ku...@kupson.cz writes:
 
  On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote:
  The file format need not know about these distictions.  Both are
  graphical layers, with different attributes.  The one has attributes to
  tell DRC to flag overlapping components, the other has attributes to
  tell some autorouter not to put copper there, and attributes to tell DRC
  to check for intruding copper.  Future plugins need more layers to tell
  about different constraints.
  
  Ideally, any layer type is fully defined via attributes.  The most
  common attribute may be net:conductive for normal copper layers, so
  that the HIDs know that the layer contributes to the implementation of
  the netlist.  Copper layers need a second attribute gbr:layer=inner5
  to tell the (gerber) exporter where to put it.  A third attribute
  defines the DRC rules that apply drc:rules=default, plus per layer
  override drc:minwidth=6mil.
  
  drc:courtyard=front
  drc:keepout=front
  route:keepout=front
 
 
  That is a bit complicated. I need a clean definition of layer types, so
  one can pick the right layer when needed. But some attributes in
  addition to layer type are possible.
 
 I do not understand that argument.

 Ok. We probably don't understand each other, so I will just state my fears.

 I would like to know about each drawing layer where it belongs to.

 So when I am performing DRC check, I will know, that it is conductive
 layer and I should consider it. I can take care of special DRC rules for
 some conductive layers later.

So we do need layer specific DRC rules.  Silk layers get the silk rules
attached.  Copper layers get copper rules attached.

 If layers types would be defined by attributes, someone would be able to
 declare one layer both as conductive and as silk for example. That could
 cause me a nighmares. 

Well, that would be a DRC violation :-) The DRC tool shall not suffer
from nightmares if it finds positives.

 That is why I insist on 'typed' layers, not 'tagged' layer.

As long as the user can define arbitrary types, the type becomes an
attribute.  If the user cannot define new types, then there shall be
only very few very abstract types, connected to basic properies, e.g.,
conductive, hole/via, other.

 That example is probably silly, but someone would probably come up with
 something more realistic, but still giving me nightmares.

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
Jared Casper jaredcas...@gmail.com writes:

 On Fri, Mar 18, 2011 at 1:23 PM, Martin Kupec martin.ku...@kupson.cz wrote:
 If layers types would be defined by attributes, someone would be able to
 declare one layer both as conductive and as silk for example. That could
 cause me a nighmares. That is why I insist on 'typed' layers, not
 'tagged' layer.

 That example is probably silly, but someone would probably come up with
 something more realistic, but still giving me nightmares.


 But what if I want a silk layer to just be a copy of a copper layer?
 That may be just as silly, but I'm sure someone could come up with a
 use for it.  Why would such a layer cause nightmares?  When the code
 is worried about connectivity etc., it sees this layer is tagged as
 conductive and includes it in whatever its doing, ignoring the fact
 that it is also silk.  When the code is putting out the silkscreen, it
 notices this layer is tagged as silk and puts it out, ignoring that it
 is also a conductive layer.

You can always tell the board house to use copper minus soldermask as
silk.


 Jared

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 You can always tell the board house to use copper minus soldermask as
 silk.

That sounds like fun...

Now I want to make a pcb plugin that copies all copper to the silk
layer, but only where there's soldermask.  You get a picture of your
circuit in white-on-green, that actually works :-)


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Jared Casper
On Fri, Mar 18, 2011 at 1:44 PM, DJ Delorie d...@delorie.com wrote:

 But what if I want a silk layer to just be a copy of a copper layer?

 This is a different category of problem - the CAM job.  Typically,
 you'd have a file that describes how to map design layers to output
 layers.  In that file, you'd say this copper layer should be output
 as a silk layer also.  Such a file could also say copper objects
 with the also-paste attribute should be drawn on the paste layer etc.


Okay, but you are just moving the layer/object tags out to a separate
file and process, the layers are still tagged so some extent
somewhere.  But I get your point.

 At the design/edit level, that layer is a copper layer.  Note to John:

 And DRC freaks out because it has two separate incompatible sets of
 rules to apply to it.


But if I am doing that (just to extend this silly example too far), I
would want the DRC checker to ensure that it obeys both the rules for
copper _and_ for silk.  If those are incompatible sets then I have to
deal with the failed DRC for one of them because I am asking the tool
to do something that doesn't agree with with the DRC rules I have
asked it to check, but I would still like to know that is what I'm
doing.

Jared


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
DJ Delorie d...@delorie.com writes:

 Inflexible wired-in behavior

 ... is MANDATORY if you're going to produce a tool that's usable.

 That's the difference between a pcb editor and, say, inkscape.

 Inkscape gives you complete flexibility, and it's absolutely useless
 as a pcb layout tool.

 You seem to be totally blind to the theory that you can have
 inflexible wired-in behavior *and* options for flexibility through
 alternate mechanisms.  We need both - they are not mutually exclusive.
 We need a tool that's easy to learn and use *and* has options for
 power user.  Your maniacal lobbying for factoring and abstraction
 would leave us with a tool that nobody would *want* to use.

We are talking about different thinks, I guess.  The tool shall be very
focussed on traces, elements, vias.  But the engine at the bottom shall
be flexible.  The user shall see this flexibility deep down in the
advanded options section of the via editor, where he will be told to go
when he asks for square via holes in this mailing list.

-- 
Stephan



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 09:49:08PM +0100, Stephan Boettcher wrote:
 Martin Kupec martin.ku...@kupson.cz writes:
  Ok. We probably don't understand each other, so I will just state my fears.
 
  I would like to know about each drawing layer where it belongs to.
 
  So when I am performing DRC check, I will know, that it is conductive
  layer and I should consider it. I can take care of special DRC rules for
  some conductive layers later.
 
 So we do need layer specific DRC rules.  Silk layers get the silk rules
 attached.  Copper layers get copper rules attached.
Yes. That is not a problem. And later we can easily add 'drc rules' as
layer attributes, so different layers of the same type will get
a bit different DRC treatment.

  That is why I insist on 'typed' layers, not 'tagged' layer.
 
 As long as the user can define arbitrary types, the type becomes an
 attribute.  If the user cannot define new types, then there shall be
 only very few very abstract types, connected to basic properies, e.g.,
 conductive, hole/via, other.

Partly. User will not be able to define new types. Because each type
get's a different treatment in different parts of code.
But I want have 'close to zero'(TM) inter layer interaction, so I will
be easy to add new type.

What I want to allow the user to do, is some 'tweaks' of layer types.
Like 'silk:refdefs'. But this 'tweaks' will have to be coded in advance,
the user will add just 'parameters' so it will start working.
So 'silk:refdefs' is still commong 'silk' typed layer with special
attributed 'refdefs' causing that 'refdefs' will magicaly go here and
not to common 'silk'.

We cannot stick with just the 'basic' layers. As i.e. countryard layers
is basicaly non-conductive layers, but there are some special DRC check
added. And those needs to be coded. I don't want to end up with the
current state that some 'specialy named' layers receive special
treatment.

Internaly it will be probably just 'common' layer on most places and
will receive special treatment on special places like now. But it should
be a bit more 'obvious' what treatment and where it receives.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread John Doty

On Mar 18, 2011, at 2:55 PM, Stephan Boettcher wrote:

 DJ Delorie d...@delorie.com writes:
 
 Inflexible wired-in behavior
 
 ... is MANDATORY if you're going to produce a tool that's usable.
 
 That's the difference between a pcb editor and, say, inkscape.
 
 Inkscape gives you complete flexibility, and it's absolutely useless
 as a pcb layout tool.
 
 You seem to be totally blind to the theory that you can have
 inflexible wired-in behavior *and* options for flexibility through
 alternate mechanisms.  We need both - they are not mutually exclusive.
 We need a tool that's easy to learn and use *and* has options for
 power user.  Your maniacal lobbying for factoring and abstraction
 would leave us with a tool that nobody would *want* to use.
 
 We are talking about different thinks, I guess.  The tool shall be very
 focussed on traces, elements, vias.  But the engine at the bottom shall
 be flexible.  The user shall see this flexibility deep down in the
 advanded options section of the via editor, where he will be told to go
 when he asks for square via holes in this mailing list.

Yes!

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 We are talking about different thinks, I guess.

Probably.

 The tool shall be very focussed on traces, elements, vias.

To be this kind of focused, it needs to have some understanding of
what a via is.  You wouldn't want to invoke the via editor on a trace,
but you wouldn't want the move option on a trace to not be able to
move either the endpoints or the whole trace.  Regardless of how the
underlying data is stored, the tools need to organize the data in a
way that helps them serve the user, and be aware of various levels of
semantics that need to be applied to what would otherwise be
meaningless groups of composites.

For example:

User level - a via is a connection between layers that I can add,
remove, edit, and move around.

Tool level - a via is an anonymous (i.e. not part of an element) hole
between layers electrically connecting copper pads on each layer.

Data layer - a via is a collection of N shapes on M conducting layers,
with a collection of one or more shapes penetrating the insulators
between those layers.


I feel that the data layer is easiest to implement, but it seems to be
what we're arguing about the most.  I say we should ignore that
problem for now, until we have a better understanding of what we want
at the other two layers.  The tool layer is going to be the hardest to
design, because that's where we blend flexibility with ease of use.
Picking the right tool-level design will give us both flexibility and
ease of use (use includes both the user and the plugin writer).


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Steven Michalske





On Mar 18, 2011, at 1:32 PM, DJ Delorie d...@delorie.com wrote:

 
 But at the core, they work all just the same.
 
 The core includes the autorouters, optimizers, DRC, exporters,
 reports, and even simple editing - we have a hide vias button.  How
 does that work if you no longer have vias as an inherent type?
 
Via the via tag attached to the generic composite that the via tool made.  
Sorry had to use the pun.

 PCB has a lot of tools that know a lot about how PCBs are designed.
 These tools are essential to making PCB a viable layout editor.  The
 input we need at this stage is from people who design a lot of PCBs,
 so we know what kinds of abstractions make sense to expose and what
 kinds need to be hidden behind other data structures.
 
 Maybe to the rendering engines they all work the same, but saying
 they all work the same *in general* just isn't applicable here.
 They don't.
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
DJ Delorie d...@delorie.com writes:

 But at the core, they work all just the same.

 The core includes the autorouters, optimizers, DRC, exporters,
 reports, and even simple editing - we have a hide vias button.  How
 does that work if you no longer have vias as an inherent type?

Hide all composites with attribute type=via.  The GUI probably
maintains an extra list of those, as well as a list of elements, for
performance.

The autorouter is told to route on all enable conductive layers, and
choose from a set of selected vias to go between those layers.

Exporters can only export what they know about.  All layers can be
turned into gerbers.  More complicated exports may need a technology
description, like an advanced concept of the current layer groups. An
exporter shall define a set of attibutes it expects to find on layers
and objects to do its special deeds, and those attribute shall not be
overloaded attributes that the core tool needs.

 PCB has a lot of tools that know a lot about how PCBs are designed.
 These tools are essential to making PCB a viable layout editor.  The
 input we need at this stage is from people who design a lot of PCBs,
 so we know what kinds of abstractions make sense to expose and what
 kinds need to be hidden behind other data structures.

At the bottom, a layout is a set of layers with attributes, containing
shapes, maybe with attributes.

The semantics of those attributes is what encapsulates the builtin
knowledge how to make PCBs, and the tool must fully exploit that
knowledge when presenting a layout to the user.

When we morph the current pcb towards such an abstract layer concept,
the user shall not see the difference unless she activates the new
features that become available with these concepts.

 Maybe to the rendering engines they all work the same, but saying
 they all work the same *in general* just isn't applicable here.
 They don't.

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 But if I am doing that (just to extend this silly example too far), I
 would want the DRC checker to ensure that it obeys both the rules for
 copper _and_ for silk.

Hmmm... DRC is already fab-specific anyway.  Maybe DRC should be on
the other side of the CAM job?  I.e. make DRC an exporter, so it gets
the layer mappings you want, and can apply rules based on the *mapped*
layers, not the *design* layers?

That also lets us code the DRC rules in the CAM job file, so different
jobs check different rule sets.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 01:52:38PM -0700, Jared Casper wrote:
 On Fri, Mar 18, 2011 at 1:44 PM, DJ Delorie d...@delorie.com wrote:
  At the design/edit level, that layer is a copper layer.  Note to John:
 
  And DRC freaks out because it has two separate incompatible sets of
  rules to apply to it.
That is one of the things that causes me nightmares. I know that is
should cause nightmares just to the DRC, but I can imagin that the set
of rules will be even incompatible 'inside' the DRC checker.
Like: This type of element is not considered in this layer, so just drop
it. And add that same element to each of those elements because they are
just there and it is not needed to draw them.

This kind of thing can REALLY happen inside DRC checker.
 
 
 But if I am doing that (just to extend this silly example too far), I
 would want the DRC checker to ensure that it obeys both the rules for
 copper _and_ for silk.  If those are incompatible sets then I have to
 deal with the failed DRC for one of them because I am asking the tool
 to do something that doesn't agree with with the DRC rules I have
 asked it to check, but I would still like to know that is what I'm
 doing.

I can provide some 'copy on write' mechanism for copying one layer into
another. But I still don't want to have two types in one layer.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
DJ Delorie d...@delorie.com writes:

 That is up to the HID to find the composits with attribute
 type=via, and present them in a via toll selector.

 I disagree with this.

 The HID is the Human Interaction Device - how the information is
 presented to the user.  GUI, printer, etc.

 The HID is the wrong place to be assigning *meaning* to the data.
 That is still in the core.  The fact that some composites are vias
 is something intrinsic to the pcb design, independent of what color
 you make it on the screen, and independend of how vias are implemented
 at the lowest internal levels.

Physical meaning is here is a hole in the board, here is a copper
circle on layer 1. Those meanings appear in elements, vias, whatever.
That a hole with concentric pads is a via has no meaning except for how
those came to be.  DRC does not care about vias.  It cares about hole
diameters and copper annulus. Connectivity also does not care about
vias.  Only the human in front of the screen cares about vias.

-- 
Stephan



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 I don't want to end up with the current state that some 'specialy
 named' layers receive special treatment.

From a practical standpoint, I think it makes sense to have a fast way
to scan for layers of some high-level type, as well as further typing
them by name.

My original design had an enumerated type for each drawing layer, that
was one of (for example) copper, silk, soldermask, paste, outline,
other with flags for normal, inverted and an assignment to a
physical layer (1..N).

That way, when you're doing something compute-intensive like
connectivity checks for auto-enforce drc clearance you aren't doing
a bazillion string compares.

Actions that are performed less often, like mapping a footprint to an
element, can use a more open-ended string-attribute with more complex
rules.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote:
 
  But if I am doing that (just to extend this silly example too far), I
  would want the DRC checker to ensure that it obeys both the rules for
  copper _and_ for silk.
 
 Hmmm... DRC is already fab-specific anyway.  Maybe DRC should be on
 the other side of the CAM job?  I.e. make DRC an exporter, so it gets
 the layer mappings you want, and can apply rules based on the *mapped*
 layers, not the *design* layers?
 
 That also lets us code the DRC rules in the CAM job file, so different
 jobs check different rule sets.

I am sorry, but I don't think this is a good idea.
The DRC should work on the hierarchy. While the exporters will receive
somewhat 'flattened' stackup.

And I want represent the resulting layer mapping somewhat in the
stackup, so the exporters will receive how are the layer ordered.
This should brink some code from the exporters to the core = less code.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 05:19:10PM -0400, DJ Delorie wrote:
 
  I don't want to end up with the current state that some 'specialy
  named' layers receive special treatment.
 
 From a practical standpoint, I think it makes sense to have a fast way
 to scan for layers of some high-level type, as well as further typing
 them by name.
The types I am trying to introduce are quite 'high-level' ones. And
futher typing will be by attributes, and I can convert the most used
ones to some nice internal representation.
 
 My original design had an enumerated type for each drawing layer, that
 was one of (for example) copper, silk, soldermask, paste, outline,
 other with flags for normal, inverted and an assignment to a
 physical layer (1..N).
 
 That way, when you're doing something compute-intensive like
 connectivity checks for auto-enforce drc clearance you aren't doing
 a bazillion string compares.
I don't want to use the names (strings) internaly at all. Just at
import/export to file. Internaly it should all be pointer based
structures.
 
 Actions that are performed less often, like mapping a footprint to an
 element, can use a more open-ended string-attribute with more complex
 rules.

This will have to use names, but that should be 'less often' as you say.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 05:09:09PM -0400, DJ Delorie wrote:
 User level - a via is a connection between layers that I can add,
 remove, edit, and move around.
 
 Tool level - a via is an anonymous (i.e. not part of an element) hole
 between layers electrically connecting copper pads on each layer.
 
 Data layer - a via is a collection of N shapes on M conducting layers,
 with a collection of one or more shapes penetrating the insulators
 between those layers.
 
 
 I feel that the data layer is easiest to implement, but it seems to be
 what we're arguing about the most.  I say we should ignore that
 problem for now, until we have a better understanding of what we want
 at the other two layers.  The tool layer is going to be the hardest to
 design, because that's where we blend flexibility with ease of use.
 Picking the right tool-level design will give us both flexibility and
 ease of use (use includes both the user and the plugin writer).

All I am right now trying to figure out is how to do the Data level
in the right way, so the Tool level has no obstructions in it.

And it seems that we got some kind of agreeament in that.
Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 Hide all composites with attribute type=via.  The GUI probably
 maintains an extra list of those, as well as a list of elements, for
 performance.

Why the GUI?  Why can't the core maintain that list, since a lot of
things will need it?  I care a lot about performance.

 Exporters can only export what they know about.  All layers can be
 turned into gerbers.

Except gerbers have special cases for thermals and pads, for example.
If you use the special cases, other CAM tools empower their users to
do more things (like auto-generate paste stencils when you forget the
paste mask, which does NOT work with pcb's gerbers).  But for the
exporters to offer these special cases, they need to know more about
the data they're given than just draw circle here.

 At the bottom, a layout is a set of layers with attributes,
 containing shapes, maybe with attributes.

and containing other layers as sub-layouts.  I have never disagreed
with this!

What I disagree with is using this at the bottom information to
re-produce the semantic information inherent in a pcb layout.  I see
no reason why there can't be a semantic heierarchy to the data, so at
a high level we have a collection of all vias that's a child of
this layout, so that the tools can find them easier and deal with
them as a group.

 The semantics of those attributes is what encapsulates the builtin
 knowledge how to make PCBs, and the tool must fully exploit that
 knowledge when presenting a layout to the user.

Forcing tools to fully exploit data at too low a level makes it very
difficult to create such tools in the first place.  The move tool
needs to know the difference between an element, a via, and a trace,
so it can function properly.  We need to consider these types of
issues when designing the internal data structures, or it will be so
difficult to write the software that it just won't get done.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
DJ Delorie d...@delorie.com writes:

 We are talking about different thinks, I guess.

 Probably.

 The tool shall be very focussed on traces, elements, vias.

 To be this kind of focused, it needs to have some understanding of
 what a via is.  You wouldn't want to invoke the via editor on a trace,
 but you wouldn't want the move option on a trace to not be able to
 move either the endpoints or the whole trace.  Regardless of how the
 underlying data is stored, the tools need to organize the data in a
 way that helps them serve the user, and be aware of various levels of
 semantics that need to be applied to what would otherwise be
 meaningless groups of composites.

 For example:

 User level - a via is a connection between layers that I can add,
 remove, edit, and move around.

 Tool level - a via is an anonymous (i.e. not part of an element) hole
 between layers electrically connecting copper pads on each layer.

 Data layer - a via is a collection of N shapes on M conducting layers,
 with a collection of one or more shapes penetrating the insulators
 between those layers.

Except, I see no need to specify any insulating layers here.  The data
does not care.  It's the exporter that may care.  If, for some
technology, the data does care, there will be a very special layer of
type other to make it care.

 I feel that the data layer is easiest to implement, but it seems to be
 what we're arguing about the most.  

Yes.  because ...

 I say we should ignore that problem for now, until we have a better
 understanding of what we want at the other two layers.  The tool layer
 is going to be the hardest to design, 

... I think the tool we have is pretty good already. Very good.  Thanks!

 because that's where we blend flexibility with ease of use.  Picking
 the right tool-level design will give us both flexibility and ease of
 use (use includes both the user and the plugin writer).

Please do not expect that users write plugins.  The tool is already too
good as it is to make is worth the effort to learn how to do that.

It's good to know that is is possible when a real need arises, but that
will not be often the case.

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 ... I think the tool we have is pretty good already. Very good.  Thanks!

The tool we have already is nearly impossible to maintain, though.

 Please do not expect that users write plugins.  The tool is already too
 good as it is to make is worth the effort to learn how to do that.

I expect the plugin mechanism to be the way to write *all* the core
bits, though.  The fact that the *user* can write them *also* is a
side-effect :-)


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
Martin Kupec martin.ku...@kupson.cz writes:

 On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote:
 
  But if I am doing that (just to extend this silly example too far), I
  would want the DRC checker to ensure that it obeys both the rules for
  copper _and_ for silk.
 
 Hmmm... DRC is already fab-specific anyway.  Maybe DRC should be on
 the other side of the CAM job?  I.e. make DRC an exporter, so it gets
 the layer mappings you want, and can apply rules based on the *mapped*
 layers, not the *design* layers?
 
 That also lets us code the DRC rules in the CAM job file, so different
 jobs check different rule sets.

 I am sorry, but I don't think this is a good idea.
 The DRC should work on the hierarchy. While the exporters will receive
 somewhat 'flattened' stackup.

Absolutely not. The DRC shall check the final flat result.  And yes, the
DRC should be a separate tool examining the CAM output.

OTOH, some DRC functionality inside the layout tool is at least nice to
have, if not required, for doing life checks when editing.  These will
probably never reach the coverage that a final checkout DRC should
provide.  But that is a problem to write such a tool in the first place.

 And I want represent the resulting layer mapping somewhat in the
 stackup, so the exporters will receive how are the layer ordered.
 This should brink some code from the exporters to the core = less code.

This kind of information shall be in the layer attributes.  Ben-mode
image export will need to know that.

-- 
Stephan



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher

DJ Delorie d...@delorie.com writes:

 I don't want to end up with the current state that some 'specialy
 named' layers receive special treatment.

From a practical standpoint, I think it makes sense to have a fast way
 to scan for layers of some high-level type, as well as further typing
 them by name.

I do not agree with the term high level here.  I agree that there may be
layers of different types, that require special treatment.  These are
low-level types, like conductive for layers that electrically connect
things, or holes for connections between layers, and other for
anything else.  What kind of high-performance processing is needed in
addition to that?  Well, when you figure out that there is something
else, it's a good justification to add anothe type.

At the storage data level they are still all layers with attributes.
When loading the layout, they are collected into separate lists, or get
a binary attribute attached, by enumerating known values of the
attribute pcb:type=

 My original design had an enumerated type for each drawing layer, that
 was one of (for example) copper, silk, soldermask, paste, outline,
 other with flags for normal, inverted and an assignment to a
 physical layer (1..N).

 That way, when you're doing something compute-intensive like
 connectivity checks for auto-enforce drc clearance you aren't doing
 a bazillion string compares.

 Actions that are performed less often, like mapping a footprint to an
 element, can use a more open-ended string-attribute with more complex
 rules.

-- 
Stephan


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 09:23:20PM +0100, Stephan Boettcher wrote:
 Martin Kupec martin.ku...@kupson.cz writes:
  Actually what I am trying to do, is to have concept so layers don't
  interract with layers of different type. The composits are a bit
  problem, because I would need to consider more layers when performing any
  action, but I think that it can still be interaction with object on the
  same layer.
 
 I do not understand what problems you see with composits.  A layer
 consists of the union of all shapes on any level of the composits
 hierarchy.  Composits may be referenced at multiple positions, so those
 shapes appear multiple times.  When a shape is modified in a composit,
 it may affect all copies simultaniously, or the composit will be
 duplicated (copy on write), depneding on an attribute or explicit user
 action.
I don't see problems, just need for special care.

And I am glad that you mentioned the 'copy on write' and multiple
reference.
 
  So, i.e., If we would have 'hole' layer. I would have check, that holes
  on hole layer are not intersecting. And also check the intersection of
  attached shapes on each layer. But all what can happen is that some
  layer will yell that something bad happend and I should cancel my
  action.
 
 Where do you want to attach holes. To layers, like John proposes?  To
 shapes on a layer?  Or as independent entities, like they are now?  

As someone proposed, it is possible to have different hole size on
different layers. So I think the best would be to have special 'hole'
object on each layer. And that object will always be in composite
container, and all of them will be forcebly aligned to the same center.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 I do not agree with the term high level here.  I agree that there
 may be layers of different types, that require special treatment.
 These are low-level types, like conductive for layers that
 electrically connect things, or holes for connections between
 layers, and other for anything else.

We're talking about the same thing, but what you call low level I
call high level, since I'm considering their place in the heirarchy
of categorization (conductor - copper - 1oz copper, or drawing -
assembly - courtyards), not the data structures they're implemented
with.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 As someone proposed, it is possible to have different hole size on
 different layers. So I think the best would be to have special 'hole'
 object on each layer. And that object will always be in composite
 container, and all of them will be forcebly aligned to the same center.

What I suggested before is that each composite itself have outline
type layers, which contains any holes, cutouts, or physical outline
shapes that need to be applied to all of the layers therein.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread John Doty

On Mar 18, 2011, at 3:09 PM, DJ Delorie wrote:

 I feel that the data layer is easiest to implement, but it seems to be
 what we're arguing about the most.  I say we should ignore that
 problem for now, until we have a better understanding of what we want
 at the other two layers.

That's the kind of top down design that produces a tool that meets today's 
requirements in the minimum amount of time, but produces an inflexible tool 
limited to those requirements.

But if you start from a data representation that spans the space of the 
possible, it drives you toward flexibility and extensibility in the upper 
layers.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-18 Thread John Doty

On Mar 18, 2011, at 3:31 PM, Stephan Boettcher wrote:

 Except, I see no need to specify any insulating layers here.

I see no need is exactly the kind of thinking that produces an inflexible, 
limited tool. I see *every* need to base the description on geometry, so that 
the tool's limits   are defined by necessity and not by the limited imagination 
of any particular group of developers. 

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-18 Thread John Doty

On Mar 18, 2011, at 3:11 PM, DJ Delorie wrote:

 
 But if I am doing that (just to extend this silly example too far), I
 would want the DRC checker to ensure that it obeys both the rules for
 copper _and_ for silk.
 
 Hmmm... DRC is already fab-specific anyway.  Maybe DRC should be on
 the other side of the CAM job?  I.e. make DRC an exporter, so it gets
 the layer mappings you want, and can apply rules based on the *mapped*
 layers, not the *design* layers?
 
 That also lets us code the DRC rules in the CAM job file, so different
 jobs check different rule sets.

Now you're talking!

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 That's the kind of top down design that produces a tool that meets
 today's requirements in the minimum amount of time, but produces an
 inflexible tool limited to those requirements.

And your kind of bottom-up design never gets done at all, because of
impossible-to-meet requirements for unlimited flexibility.

 But if you start from a data representation that spans the space of
 the possible, it drives you toward flexibility and extensibility in
 the upper layers.

The problem is, the space of the possible is infinitely large, and
we have a very small finite set of developers.  Unless we know how the
tool is going to be used, we don't even know what the space of the
possible *is*.

So I can grant you your wish right now - delete your pcb tree and you
have the result of your design process.


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 10:40:02PM +0100, Stephan Boettcher wrote:
 Martin Kupec martin.ku...@kupson.cz writes:
 
  On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote:
  
   But if I am doing that (just to extend this silly example too far), I
   would want the DRC checker to ensure that it obeys both the rules for
   copper _and_ for silk.
  
  Hmmm... DRC is already fab-specific anyway.  Maybe DRC should be on
  the other side of the CAM job?  I.e. make DRC an exporter, so it gets
  the layer mappings you want, and can apply rules based on the *mapped*
  layers, not the *design* layers?
  
  That also lets us code the DRC rules in the CAM job file, so different
  jobs check different rule sets.
 
  I am sorry, but I don't think this is a good idea.
  The DRC should work on the hierarchy. While the exporters will receive
  somewhat 'flattened' stackup.
 
 Absolutely not. The DRC shall check the final flat result.  And yes, the
 DRC should be a separate tool examining the CAM output.
 
 OTOH, some DRC functionality inside the layout tool is at least nice to
 have, if not required, for doing life checks when editing.  These will
 probably never reach the coverage that a final checkout DRC should
 provide.  But that is a problem to write such a tool in the first place.

The problem here is that it have to be possible to point out the
problematic parts. So I guess it have to be able to flatten the
hierarchy by itself and so I knows where the problem comes form.

But I want to talk about DRC later.. DRC lives on top of layers and
will need nearly no support from it.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Martin Kupec
On Fri, Mar 18, 2011 at 05:58:29PM -0400, DJ Delorie wrote:
 
  As someone proposed, it is possible to have different hole size on
  different layers. So I think the best would be to have special 'hole'
  object on each layer. And that object will always be in composite
  container, and all of them will be forcebly aligned to the same center.
 
 What I suggested before is that each composite itself have outline
 type layers, which contains any holes, cutouts, or physical outline
 shapes that need to be applied to all of the layers therein.

If you mean 'physical layer' by 'composite', than yes. Each of those
will have it's 'outline' layer.

But I didn't wanted to have the 'hole' here, but now I don't see why.
We can probably do that.

The problem here is: How to recognice board 'outline' from cutouts?

I don't want to draw the actual 'outline' to all physical layers if it
is the same. So I cannot take 'the biggest one' as outline.

Martin Kupec



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


Re: gEDA-user: General Layers questions

2011-03-18 Thread John Doty

On Mar 18, 2011, at 4:07 PM, DJ Delorie wrote:

 
 That's the kind of top down design that produces a tool that meets
 today's requirements in the minimum amount of time, but produces an
 inflexible tool limited to those requirements.
 
 And your kind of bottom-up design never gets done at all, because of
 impossible-to-meet requirements for unlimited flexibility.

Absolutely not. The right kind of flexibility is even more important to the 
developers than to the users.

 
 But if you start from a data representation that spans the space of
 the possible, it drives you toward flexibility and extensibility in
 the upper layers.
 
 The problem is, the space of the possible is infinitely large, and
 we have a very small finite set of developers.  Unless we know how the
 tool is going to be used, we don't even know what the space of the
 possible *is*.

In your sense, you have no idea what the space of the possible is for the 
integers. Yet all integers can be represented by strings of two digits. Not 
much of a developer burden.

Ales did an incredible job of representing the space of the possible for 
schematics with a very clean bottom level. The troublesome issues in gEDA come 
from upper levels that fail to respect its generality. But there are far fewer 
issues there than there are with pcb.

Good, clean, simple, highly general foundations can *drastically reduce* the 
burden on the developer (been there). The most common cause of bad foundations, 
in my experience, is limited vision.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
DJ Delorie d...@delorie.com writes:

 ... I think the tool we have is pretty good already. Very good.  Thanks!

 The tool we have already is nearly impossible to maintain, though.

 Please do not expect that users write plugins.  The tool is already too
 good as it is to make is worth the effort to learn how to do that.

 I expect the plugin mechanism to be the way to write *all* the core
 bits, though. 

The more important it is, that what is below the plugin mechanism is as
general as necessary, and since that is difficult to judge up front: as
general as possible, without compromising the final goals.

I'd propose a very basic, very general storage data representation.
Just layers, shapes, and arbitray levels of composites, the layout
implicitly being the top level composit. Everything with arbitrary
attributes.

On top of that is a memory representation, that introduces the concepts
of elements, vias, surface-layers (layer sets: copper, mask, silk,
courtyard, keepout), connectivity,   

It provides basic operations on these concepts.  The implementation of
these concepts builds on the objects of the storage data layers.  It
must not be an error if a via has two holes, a polygon shaped hole or
silk in it.  DRC may flag such things, but it must not be an error.
The attributes that this memory representation and it methods understand
shall be in namespace pcb: and unknown attributes in that namespace
shall emit warnings.

The plugins define their own attributes.  Attributes shall not be
overloaded.  If a plugin operates on attributes of the memory
representation, it shall do that via methods of that representation, if
possible.  

Higher level parts of the concepts element, via, surface layer
may be implemented in plugins.




I cannot keep up, there are 15 new messages in my inbox, lets see what
what new arguments come up :-)

I cannot make up my mind if I should continue to argue for hole layers,
or if holes shall be shapes with hole attribute on layers.

 The fact that the *user* can write them *also* is a side-effect :-)


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

-- 
Stephan Böttcher FAX: +49-431-85660
Extraterrestrische PhysikTel: +49-431-880-2508
I.f.Exp.u.Angew.Physik   mailto:boettc...@physik.uni-kiel.de
Leibnizstr. 11, 24118 Kiel, Germany


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


Re: gEDA-user: General Layers questions

2011-03-18 Thread DJ Delorie

 If you mean 'physical layer' by 'composite', than yes. Each of those
 will have it's 'outline' layer.

I meant sub-assemblies.

This is hard to describe because of the near-impossible list of things
we want to support, but...

There are two types of sub-assemblies.  First, composite objects which
are mapped to the physical board, and second, the physical board
itself.

So, a footprint is a composite sub-assembly that includes some holes,
copper, cutouts, etc.  It needs to be mapped to the physical board
on-the-fly as we want to maintain it as an object.  But the PCB
itself could have different numbers of layers at different locations,
such as flex cable assemblies, and you could describe the stackup
itself in terms of how the layers are put together (i.e. buried vias
are drilled through a subset of layers, that subset has its own
holes layer).

In both cases, there's information about holes that applies to some
subset of the layout.


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


  1   2   3   >