X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=ha4UNjSEWYTjQfglQySsSlTMxbsNwBzWUuVgfT9t7Ns=;
	b=0CgcQIG69yzmH5GH3OATG0XQSecHxtR1wOWmvkN0vqQ9d8JHIdWHB0w25IVwKGC5ID
	2Ol08uo8tWWM5Om05pJlWH/VeZ2R/m3T1fe/spPcax7/3EpazW2wFgXXyM6Ad1DMwPwZ
	0oZ/T6GbQdVAQ9xBZVHLktkuq0i0CI1oSL19K3BTwCWx7TMcwKEJAeYInK6gzpilE0Rg
	7mLirnHnziEK1afUdGLupX0U9v6NqndxhFMSP2IwZWNI2c47OhABp9Js11O+0gs3tzot
	SFzoAcjUmXXJg51tiTQ+ABYoT31ef3swjXTQWbhcWnKIe8ilCE5fSEHQPGbeYIbr+9+z
	41GQ==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=ha4UNjSEWYTjQfglQySsSlTMxbsNwBzWUuVgfT9t7Ns=;
	b=MTymzUtrZ2KSaQhyh/WEpvt+fubitiIMbVFCqaW2NRCQ03gkv0KIOJBP5axeAziIwP
	+U3gJGbQA64CYmkZUuiT10e35kfdmHLFtNFXghjA3WQV1jiyi7eU+kUDCBmPO068jtI7
	8w6iOPeBRKFlnzJ4mSxzMSB1IZZNaKCUmIJIHGMV8f6GgBFtx8SgiwRrtBbP4SlZRCYq
	5Pu/MEZBftKTefXN7DiHGXgsZI4ssn6/IO3pvILosNsejmmDqNY5IAefDunxDYVlkBM+
	o0PLYH5dTq4Ffw1Vz5/WyKKMqga14EQzORvtuYJFWXaLOlsAvqqtIOHrm8eQ8jPbs3On
	vIkw==
X-Gm-Message-State:	AG10YOSwWQx8S39Lm32PQezog+Y0q7WB3TJ309jsF7SXi2c2wABWfj/ZPtyd7EaOXBM59yEg7ZbyU0K9NPJ8TA==
MIME-Version:	1.0
X-Received:	by 10.60.177.67 with SMTP id co3mr10827830oec.62.1454156215152;
	Sat, 30 Jan 2016 04:16:55 -0800 (PST)
In-Reply-To:	<82868AE2-27A4-44AE-92F2-47A2FAA12BB4@icloud.com>
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1601180756390 DOT 9035 AT igor2priv>
	<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>
	<s6nfuxirm0b DOT fsf AT falbala DOT ieap DOT uni-kiel DOT de>
	<CAC4O8c9D-F3p8sAm2UumoE+uoMZM1ufSP=mNEPeHHpn8YrcSyg AT mail DOT gmail DOT com>
	<20160128200126 DOT 0fe1bb26d5c28e59d56dfd0e AT gmail DOT com>
	<CAC4O8c8prUS=NSm_7BCwkCPntsCRRMCMu9--eXXVBtD0C4pYOg AT mail DOT gmail DOT com>
	<201601282134 DOT u0SLYET7002642 AT envy DOT delorie DOT com>
	<82868AE2-27A4-44AE-92F2-47A2FAA12BB4 AT icloud DOT com>
Date:	Sat, 30 Jan 2016 13:16:55 +0100
Message-ID:	<CADL2oCVmfyUPC=zGA2OebmsYSsoOVhGo85jc4euQ2hWkxfDgMg@mail.gmail.com>
Subject:	Re: [geda-user] The nature of gEDA layers
From:	"Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
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

--047d7bd76468a6f5b7052a8c2076
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think I saw and example from Stefan B=C3=B6tcher a few days ago with a vi=
a
layer. Although i disagree and say via layer really belong to board
layer(s) since this is the layer(s) where vias end up the example he used
should work really well !!

For the most layers it make sense to draw on the actual layer but for the
board/via layer it might be better to say which layer(s) they connect.

Motivation: I assume a drilled hole is equal to round cut out and assume
there may exist cut out of any shape. Then it is known between which layers
cut out should span it is simple to generate these cut outs on "real" board
and plating layer(s) if needed. To work the opposite direction and add
drawing primitives to board and plating layers will in particular have
problem with alignment between drilled hole and plating. It may also have
some problems with placement in the stackup. It would be possible to
automatically add these drawing primitives from via/board layer to a real
layer with possibility to add more drawing primitives or simply add the
objects to via layer.

Last word: If board "outline" or board layer is drawn as polygon it would
be no problem to add cut outs from via layer in this polygon to get a
proper model of the board layer(s).

Nicklas Karlsson


2016-01-30 11:49 GMT+01:00 Chris Smith (space DOT dandy AT icloud DOT com) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com>:

>
> > On 28 Jan 2016, at 21:34, DJ Delorie <dj AT delorie DOT com> wrote:
> >
> >>> - Allow more/all things inside Elements, on explicit layers.
> >>
> >> This one in particular is not a small incremental step but a fairly
> >> drastic change.  A lot of work is likely to be required to fix all the
> >> points that make assumptions about Elements.  I'm not saying it's a
> >> bad idea, but it's hard.
> >
> > Yeah, hard :-)  Internals-wise, the problems are many-fold:
> >
> > * The GUI needs a way of letting the user specify a BBvia
> > * The GUI needs to be able to *draw* a BBvia (+1 in 3D mode)
> > * The GUI needs a way to let the user specify which layer pairs may hav=
e
> BBVias
> > * The exporters need to know how to export a BBVia (esp drill files)
> > * DRC needs BBVia-specific rules
> > * DRC needs to know where BBVias connect to
> > * Find, likewise
> > * Report, likewise
> > * auto-drc needs to know when to let you go "past" a BBVia
> > * ...which implies a real physical stackup is needed, and enforced
> > * ...which implies more GUI changes
> > * will autoroute use BBVias?
> > * what about the optimizers?
> > * We need a way of storing BBVias in a file
> > * ...and storing them internally
> > * ...and hooking them up to all the object-oriented code throughout
> > * ...and hooking them up to the rtrees
> > * ...and teaching rtrees how to find only BBVias that intersect the
> layers in question
> > * ...and define "layers in question" accordingly
> > * etc
> >
> > So let's call this a "drastic incremental change" - it's doable in the
> > context of the current code set but it's a lot of work.
>
>
> Isn=E2=80=99t this a bit too specific?  Why does PCB need to know specifi=
cally
> about BBVias, or any other type of via?  Wouldn=E2=80=99t it be better to=
 allow the
> concept of a =E2=80=98foreign=E2=80=99 connection, i.e. a connection that=
 is made outside
> of PCB=E2=80=99s routing.  You would do this by allowing the user to atta=
ch one or
> more connection attributes (call them net names, if you will) to a
> primitive; PCB would then run its existing geometrical/graphical algorith=
ms
> to determine connectivity, collecting all explicit connection attributes =
at
> the same time.  The final connection would then be a logical OR=E2=80=99i=
ng of all
> graphically connected primitives with common explicit connection attribut=
es.
>
> In this way any type of via is simply a group of primitives on a number o=
f
> layers, with those on copper layers sharing a common connection attribute=
.
> DRC and auto-DRC would work as normal, with little to no change.  It woul=
d
> also provide a mechanism to do other, similar things, like wire
> connections, internally connected pins, wrap-around board edge connectors=
,
> etc =E2=80=94 it would all work in exactly the same way.
>
> In terms of GUI you would then =E2=80=98only' need:
>
> - sub layouts or groups/blocks of primitives
> - unique connection attribute for each =E2=80=98paste=E2=80=99 of a block=
/group.
>
> It would be up to the user to ensure that their via groups are physically
> manufacturable, but you could also provide a GUI mechanism to cover the
> common options.
>
> Surely this is much cleaner and more flexible than providing Via and BBVi=
a
> specific functionality?
>
> Chris
> =E2=80=94
> Chris Smith <space DOT dandy AT icloud DOT com>
>
>
>
>

--047d7bd76468a6f5b7052a8c2076
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I think I saw and example from Stefan B=C3=B6tcher a =
few days ago with a via layer. Although i disagree and say via layer really=
 belong to board layer(s) since this is the layer(s) where vias end up the =
example he used should work really well !!<br></div><div><br></div><div>For=
 the most layers it make sense to draw on the actual layer but for the boar=
d/via layer it might be better to say which layer(s) they connect.</div><di=
v><br></div><div>Motivation: I assume a drilled hole is equal to round cut =
out and assume there may exist cut out of any shape. Then it is known betwe=
en which layers cut out should span it is simple to generate these cut outs=
 on &quot;real&quot; board and plating layer(s) if needed. To work the oppo=
site direction and add drawing primitives to board and plating layers will =
in particular have problem with alignment between drilled hole and plating.=
 It may also have some problems with placement in the stackup. It would be =
possible to automatically add these drawing primitives from via/board layer=
 to a real layer with possibility to add more drawing primitives or simply =
add the objects to via layer.</div><div><br></div><div>Last word: If board =
&quot;outline&quot; or board layer is drawn as polygon it would be no probl=
em to add cut outs from via layer in this polygon to get a proper model of =
the board layer(s).</div><div><br></div><div class=3D"gmail_extra">Nicklas =
Karlsson</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">2016-01-30 11:49 GMT+01:00 Chris Smith (<=
a href=3D"mailto:space DOT dandy AT icloud DOT com">space DOT dandy AT icloud DOT com</a>) [via <=
a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <span di=
r=3D"ltr">&lt;<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">ge=
da-user AT delorie DOT com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; On 28 Jan 2016, at 21:34, DJ Delorie &lt;<a href=3D"mailto:dj AT delorie.=
com">dj AT delorie DOT com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt;&gt; - Allow more/all things inside Elements, on explicit layers.<b=
r>
&gt;&gt;<br>
&gt;&gt; This one in particular is not a small incremental step but a fairl=
y<br>
&gt;&gt; drastic change.=C2=A0 A lot of work is likely to be required to fi=
x all the<br>
&gt;&gt; points that make assumptions about Elements.=C2=A0 I&#39;m not say=
ing it&#39;s a<br>
&gt;&gt; bad idea, but it&#39;s hard.<br>
&gt;<br>
&gt; Yeah, hard :-)=C2=A0 Internals-wise, the problems are many-fold:<br>
&gt;<br>
&gt; * The GUI needs a way of letting the user specify a BBvia<br>
&gt; * The GUI needs to be able to *draw* a BBvia (+1 in 3D mode)<br>
&gt; * The GUI needs a way to let the user specify which layer pairs may ha=
ve BBVias<br>
&gt; * The exporters need to know how to export a BBVia (esp drill files)<b=
r>
&gt; * DRC needs BBVia-specific rules<br>
&gt; * DRC needs to know where BBVias connect to<br>
&gt; * Find, likewise<br>
&gt; * Report, likewise<br>
&gt; * auto-drc needs to know when to let you go &quot;past&quot; a BBVia<b=
r>
&gt; * ...which implies a real physical stackup is needed, and enforced<br>
&gt; * ...which implies more GUI changes<br>
&gt; * will autoroute use BBVias?<br>
&gt; * what about the optimizers?<br>
&gt; * We need a way of storing BBVias in a file<br>
&gt; * ...and storing them internally<br>
&gt; * ...and hooking them up to all the object-oriented code throughout<br=
>
&gt; * ...and hooking them up to the rtrees<br>
&gt; * ...and teaching rtrees how to find only BBVias that intersect the la=
yers in question<br>
&gt; * ...and define &quot;layers in question&quot; accordingly<br>
&gt; * etc<br>
&gt;<br>
&gt; So let&#39;s call this a &quot;drastic incremental change&quot; - it&#=
39;s doable in the<br>
&gt; context of the current code set but it&#39;s a lot of work.<br>
<br>
<br>
</div></div>Isn=E2=80=99t this a bit too specific?=C2=A0 Why does PCB need =
to know specifically about BBVias, or any other type of via?=C2=A0 Wouldn=
=E2=80=99t it be better to allow the concept of a =E2=80=98foreign=E2=80=99=
 connection, i.e. a connection that is made outside of PCB=E2=80=99s routin=
g.=C2=A0 You would do this by allowing the user to attach one or more conne=
ction attributes (call them net names, if you will) to a primitive; PCB wou=
ld then run its existing geometrical/graphical algorithms to determine conn=
ectivity, collecting all explicit connection attributes at the same time.=
=C2=A0 The final connection would then be a logical OR=E2=80=99ing of all g=
raphically connected primitives with common explicit connection attributes.=
<br>
<br>
In this way any type of via is simply a group of primitives on a number of =
layers, with those on copper layers sharing a common connection attribute.=
=C2=A0 DRC and auto-DRC would work as normal, with little to no change.=C2=
=A0 It would also provide a mechanism to do other, similar things, like wir=
e connections, internally connected pins, wrap-around board edge connectors=
, etc =E2=80=94 it would all work in exactly the same way.<br>
<br>
In terms of GUI you would then =E2=80=98only&#39; need:<br>
<br>
- sub layouts or groups/blocks of primitives<br>
- unique connection attribute for each =E2=80=98paste=E2=80=99 of a block/g=
roup.<br>
<br>
It would be up to the user to ensure that their via groups are physically m=
anufacturable, but you could also provide a GUI mechanism to cover the comm=
on options.<br>
<br>
Surely this is much cleaner and more flexible than providing Via and BBVia =
specific functionality?<br>
<br>
Chris<br>
=E2=80=94<br>
Chris Smith &lt;<a href=3D"mailto:space DOT dandy AT icloud DOT com">space DOT dandy AT iclou=
d.com</a>&gt;<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--047d7bd76468a6f5b7052a8c2076--

- Raw text -