X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Date:	Wed, 12 Jul 2017 20:55:15 +0200 (CEST)
X-X-Sender:	igor2 AT igor2priv
To:	"Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug:	to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From:	gedau AT igor2 DOT repo DOT hu
Subject:	Re: [geda-user] PCB, load element bug (know then but not why)
In-Reply-To:	<20170712201339.bdab1cbf6238d8da3354e439@gmail.com>
Message-ID:	<alpine.DEB.2.00.1707122040160.27212@igor2priv>
References:	<20170711005040 DOT d96eccaffe490027849789c3 AT gmail DOT com> <20170711020955 DOT 0108aaea AT akka> <alpine DOT DEB DOT 2 DOT 00 DOT 1707110515450 DOT 27212 AT igor2priv> <20170711110940 DOT 84467c71877716992ddc3b11 AT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1707121629340 DOT 27212 AT igor2priv>
	<20170712201339 DOT bdab1cbf6238d8da3354e439 AT gmail DOT com>
User-Agent:	Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version:	1.0
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

On Wed, 12 Jul 2017, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:

> Sounds good.
>
> You have or are planning a tree like structure like this: root object layout --> sub circuits --> footprints --> pads --> drawing primitives?
>
> In sort of any object could appear anywhere? To connect with netlist it must be possible to find footprints by refdes and pin number but otherwise what is counted as a pad os circuit is more about where they are saved?

What I already have:

board -> primitives

board -> subcircuit -> primitives

What I plan to have:

board -> subcircuit -> subcircuit -> ... -> primitives

This also means a hierarchic pcb could reflect a hierarchic netlist which 
in turn could be derived from a hierarchic schematics (low prio, long 
term plan).

Pins & pads: I will implement what I've developed for tEDAx: there won't 
be a special pin or pad object any more, but there will be logical 
terminals. A terminal will have an ID, similar to pin or pad number now, 
and other, optional metadata (such as symbolic name). You would just tag 
any primitive within a subcircuit to belong to a specific terminal ID. 
Or in other words, your "pin 1" could constructed of a via, your "pad 2" 
could be a line, a polygon or even an arc, and your "pad 4" can be a 
combination of any of the above.

Since subcircuits are free of the layer restrictions as well, this 
also means you will be able to bind a mask cutout object to a specific 
terminal.

After this is done, I will remove the pin, pad, element, element-line, 
element-arc primitives from core.

Meanwhile I have a lower priority (due to lack of user demand) long term 
plan to turn via into padstack. I would also make the hole optional. The 
pad stack recipe would be able to install different polygon shapes on 
different layers, not restricted to copper layers, not required to have a 
pad on every layer. The optional hole would be part of this game. This 
would solve the pad stack and bbvia problems in an elegant, clean way and 
would produce the trivial pin/pad primitive for subcircuit. E.g. a pad is 
just a padstack without a hole, with a top copper polygon and a top mask 
cutout polygon. A pin can be built from a padstack that affects more 
copper layers, both mask layers and has a hole. Anything more complicated 
can be combined/built of individual lines, arcs, polygons, pad stacks and 
text objects by just tagging them all to the same terminal ID.

Regards,

Igor2

- Raw text -