Mail Archives: geda-user/2016/01/28/06:18:50

X-Authentication-Warning: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Virus-Scanned: by amavisd-new (Uni-Kiel/l2ms-sc)
From: geda AT psjt DOT org (Stephan =?utf-8?Q?B=C3=B6ttcher?=)
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] The nature of gEDA layers
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1601180756390 DOT 9035 AT igor2priv>
<CANEvwqgs3YFnt7m8mA1DN6X2KdWbyr4zpXCVH321vDo1f7CyxA AT mail DOT gmail DOT com>
<201601261804 DOT u0QI4KEQ009550 AT envy DOT delorie DOT com>
<E7D351BF-5BBB-41AC-B996-D5E27079A82C AT noqsi DOT com>
<CAC4O8c-ZyNnCzCDHXkYYabSD4fG8vf+CKmhMycNJujGMPKzQDQ AT mail DOT gmail DOT com>
<s6nr3h49hrq DOT fsf AT blaulicht DOT dmz DOT brux>
<DDB07351-7C94-4B5C-99FA-83750CD4592A AT noqsi DOT com>
<20160126233332 DOT dec2f06f5c74354a3841989c AT gmail DOT com>
<s6n1t93h4ub DOT fsf AT blaulicht DOT dmz DOT brux>
<20160127091746 DOT 1c7a976c2752f913921688ac AT gmail DOT com>
<s6npowne74w DOT fsf AT blaulicht DOT dmz DOT brux>
<20160127141334 DOT c738feb9dbeb54a7dec3dff8 AT gmail DOT com>
<s6n37tjt1tv DOT fsf AT falbala DOT ieap DOT uni-kiel DOT de>
<56A8F74B DOT 8080304 AT ecosensory DOT com>
<CAC4O8c9UKLsh5FAAwUMEtHThKH-w3gUmCU2i9dRW9igkyRt-TQ AT mail DOT gmail DOT com>
<CAJZxidDmjMtd_fKvR5qZVRa+hwDUbvfaz79oZjkBgDuE1m8RBg AT mail DOT gmail DOT com>
<56A961BC DOT 3040405 AT ecosensory DOT com>
<CAJZxidC=nbxAinOtpfGHHqwPXbEMrhfat7jKgA9KBp3EVVg4_Q AT mail DOT gmail DOT com>
<s6nbn863xlu DOT fsf AT blaulicht DOT dmz DOT brux> <56A9E416 DOT 8080500 AT ecosensory DOT com>
Date: Thu, 28 Jan 2016 12:17:40 +0100
In-Reply-To: <> (John Griessen's message of
"Thu, 28 Jan 2016 03:49:10 -0600")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
X-MIME-Autoconverted: from quoted-printable to 8bit by id u0SBHlGv006680
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

John Griessen <john AT ecosensory DOT com> writes:

> On 01/28/2016 02:41 AM, Stephan Böttcher wrote:
>> "Chad Parker (parker DOT charles AT gmail DOT com) [viageda-user AT delorie DOT com]"  writes:
>>> >My experience has always been that hard to read spaghetti code is the
>>> >result of dealing with special cases that arise from having data structures
>>> >and functions that weren't designed quite right. Making things more generic
>>> >reduces the number of special cases and allows for the maximum reuse of
>>> >structures and functions.
>>> >
>>> >As I stated in my opening remark, feel free to take or leave my
>>> >suggestions. Obviously I think it would be wise to heed them
>> So do I.
> OK.  If having generic containers for data about a pc board and an
> assembly of parts onto it helps coding
> be easy let's do that.  Naming and documentation needs help in PCB.
> The word layer gets associated with
> layers of FR4  

I associate copper with the word layer, when I order boards, not FR4.
Each laminate layer can support two copper layers.

FR4 layers in PCB are only need for the RF tools.  And even those just
need attributes about the dielectric properties between adjacent copper
layers.  Similar for 3D export HIDs.

> that are laminated together just by talking about board design, as in
> whether a layer is between ground or power plane layers for
> transmission-line purpose and/or shielding purpose...
> So, if one generic container of data holds a 2D conductor on insulator
> pattern, and one holds
> solder mask and one holds top-to-bottom-via connectivity they don't
> all get talked about as layers or it
> is confusing.

Our primary output is Gerber.  I'd call a "Layer" whatever we draw on.
Everything we can look at with Gerbv.  But since conectivity is a
central concept in the core, the word "Layer" may be restricted to
conductive drawing planes, if that helps.  I don't see how.

> What is a good name for these containers?  Spec group? Pattern group? Data group?
> Layer is not a good name -- that should be reserved for documentation
> of board design concepts relation to commands and such.
> If the wording data group or just group is used, you can add a word in
> front to concisely say most of what's needed:

A Group is a collection of properties, attributes and objects on
multible layers.

  Librecad used the term "Block"
  Inkscape uses the term "Group"

> For instance the futuristic buried via is likely to be specified as:
> attach the buried-via property to each via pad of data groups to
> connect.  All in between data groups get a default sized buried-via
> pad magically placed at the buried via location, but not more outward
> layer data groups.

I don't think there should be a "buried-via" property.  I don't think
those should be attached to the pads.

We export a plated-drill file.  We should have a layer that corresponds
to the geometry exported in that file. And we be able draw on them (in
expert mode).  If there are any non-circle objects on that layer you
will need to discuss this with your boardhouse.

The drill-layers are marked as such with a property that is hardwired to
the code that handled connectivity.  That property tells which layers
the objects on this layer connect to.  That property should not be an
Attribute, but hardwired.  Alternatively, each copper layer could tell
to which drill layer it connects to.

Geometry and connectivity needs to be hardwired in the core data
structures. That is the core of what is needed to be efficient while

The via editor will help the user to define all required via layers
and apply designrules that test for manufacturability.

> Top to bottom via is likely to be specified as: Add a via pad to the
> via data group where you want a top-to-bottom-via.

Any Via is a Group with copper pads and a drill pad, clearance pads and
other objects for thermals.

An SMD pad is a Group with all that but nothing on any drill layer.

A thermal tool can convert any line into a Group and attach thermals.

> The "magically" part above will be difficult if more than one buried
> via not touching, but in one X,Y location is desired -- maybe that
> will
> become: place buried-via pads on each in between layer data group to
> connect so there is a pad at every layer data group
> in between connected traces layer data groups.
> Maybe pad rings in between along a vertical conductive path is not
> even needed by some fabbers of buried vias.

This sounds to complicated and special cased.  This is DRC tool

The Via Group shall have explicit pads on all layers it runs through,
where needed.  Make those as big as the boardhouse needs.

Stephan Böttcher Tel: +49-431-880-2508
Extraterrestrische Physik, IEAP, Leibnizstr. 11, 24118 Kiel

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019