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=wellesley.edu; s=gmail;
	h=subject:to:references:from:message-id:date:user-agent:mime-version
	:in-reply-to:content-transfer-encoding:content-language;
	bh=J3O6DWbotT1YUbtshCKuWjOosvMFwZgIVgOEGk0WSlM=;
	b=SPsNkV8p6qKom5/xyT91AUjpRQiIQQ7EvhcwiyEHTY3KhqD3pZcwlFf+D2ID7eK8AK
	dNCmYZi6RYwHKyncAqFD0GpGefhn7oMnb/OcFeQ8K6l+a0HU6UWLjTaX9WfdQqP9qAnK
	tNjngqnVe5SnCDkNSj8idvYsJnXScwRDsYGTeYukxG3CaIVHLFWPr4u6O4mQe4qjsk/z
	ds4bu9vFNnBy6BFLgt+ztx/e/fIgAWyNw6i4nGIqJeOQwfYIRBKOSTjqZWTsA/V2VTWX
	Af52GQ7h5AFDlH1R8kCCEUTxsY4fwEbCKPWBchxNwqfGgLZt6vcPKhBKvXvF0dLjnyLj
	15bA==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:references:from:message-id:date
	:user-agent:mime-version:in-reply-to:content-transfer-encoding
	:content-language;
	bh=J3O6DWbotT1YUbtshCKuWjOosvMFwZgIVgOEGk0WSlM=;
	b=SnkSkEyY2Jmn0CvLDz/78BFkBmHTuML/eqA82CoWxU0PKYXU+ZQqrRF74eNr6ejSgo
	kLvnVsGpOlAsaX+7z4iwyCH0VpUMPEdbw3ZRW6dUTU2KBQWoQ+MdGoU+3L9MqupD7Nxk
	Jrw+UCnYinHpr7g0u+vAy52KJQImWd/p6Mw/wbKZEH17N3xowzAliQfiZPBK75lKl0HT
	pjAWIZz7glJnipMDo2OFKLwWjAReoceeAxgAs34XuNLqo1p7xuCDji92Z9WH50cZ/JCr
	VXl9vDUYPXDxgQPrLvAoXDefp+HkAQgLyoRBR0hTwn1rnTp1srSaTGmJj22GDXqqsrST
	sInA==
X-Gm-Message-State:	AODbwcBuWQ3wuKF7OpYtqcclA8+fEVoLX6EaS29TCuy9TedEp9zaviv3
	CFHnPYlBsI1u+9cCfGK1PQ==
X-Received:	by 10.200.50.216 with SMTP id a24mr23881901qtb.91.1496160705579;
	Tue, 30 May 2017 09:11:45 -0700 (PDT)
Subject:	Re: [geda-user] [pcb-rnd] up next: subcircuits (a.k.a. footprint
	model redesign)
To:	geda-user AT delorie DOT com
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1705300721100 DOT 27212 AT igor2priv>
From:	"James Battat (jbattat AT wellesley DOT edu) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID:	<ae8d0788-7ecd-9d9d-0b2e-22deef0b8350@wellesley.edu>
Date:	Tue, 30 May 2017 12:11:44 -0400
User-Agent:	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
	Gecko/20100101 Thunderbird/52.1.1
MIME-Version:	1.0
In-Reply-To:	<alpine.DEB.2.00.1705300721100.27212@igor2priv>
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

Igor2, all,

I'd be very happy to provide testing for any improvements on how to 
specify and re-use a layout for a collection of footprints.

Specific example: say I'm designing a board that reads out 24 
temperature sensors (RTDs).  Each RTD channel has a pair of op-amps and 
surrounding circuitry, with identical layout.  Can I specify/layout a 
single channel, and then tell pcb-rnd to repeat this layout for the 
other 23 channels? (without manually updating the REFDES for each 
component in channels 2-24)? This may already be possible, but I don't 
know how to do it...

James


On 5/30/17 2:21 AM, gedau AT igor2 DOT repo DOT hu wrote:
> Hi all,
>
> now that pcb-rnd 1.2.3 is out, it's time to celebr^W focus on the next 
> big chunk of work.
>
> A few months back we made a feature poll among pcb-rnd users about 
> which feature was the most wanted. The result was:
>
> 1st: editable layers (just released)
>
> 2nd: subcricuits (see below)
>
> 3rd: pad stacks and blind/buried vias (with the lowest score possible 
> - seems to be a lower priority task with no real user demand, 
> postponed for a later date)
>
> So next big chunk is subcircuits: footprint model redesign.
>
> Current situation: pcb elements
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> There are a lot of feature requests out there about extending the 
> footprint model. A few random example:
>
> - polygon in footprint, 2009, 2010 
> http://archives.seul.org/geda/user/Sep-2010/msg00619.html
> http://archives.seul.org/geda/user/Jun-2009/msg00370.html
>
> - arc in footprint, 2010:
> http://archives.seul.org/geda/user/Apr-2010/msg00613.html
>
> - how to work around missing mask editing feature in footprints, 2004:
> https://www.mail-archive.com/search?l=geda-user AT seul DOT org&q=subject:%22Re%3A+gEDA-user%3A+PCB%3A+how+to+clear+soldermask+from+entire+footprint%22&o=newest&f=1 
>
>
> It would be possible to add code just for these cases. However, each 
> such example would introduce a new set of special cases in the code 
> base, and these cases will always interact with almost all other such 
> specil cases. Which means an exponential growth in special case vs. 
> sepcial case interaction that would be rather hard to maintain long 
> term. This is not the route we take in pcb-rnd.
>
> Generally speaking, the problem is that our footprint model is a bag 
> of special cases: footprints can have the special objects, for example:
>
>  - element-line, but that's only lines drawn on silk
>
>  - (smd) pad, which can't have arbitrary shape and must be on top or 
> bottom copper
>
>  - pin, which is basically just an "element-via", with some pin number 
> and pin name attached; mostly code dup of via plus code dup from smd 
> pads for the number/name
>
>  - exactly 3 silk text objects, from which only 1 can be dispalyed at 
> any given time (refdes, footprint description, value)
>
>  - a bunch of automatic side effects, like mask and paste on smd pads
>
> There are some clever hacks to work around some of the limitations, 
> usually by combining pads and pins. But this is not building from 
> pure, orthogonal bricks, but building from fuzzy haystacks, mainly 
> trying to combine and cancel side effects. I know this "works", I know 
> we do this since forever, but this is far from the optimal solution.
>
>
> Future: subcircuits
> ~~~~~~~~~~~~~~~~~~~
> I am going to slowly replace this old mechanism in pcb-rnd with a new 
> system called "subcircuits". From the user's point of view, a 
> subcircuit takes the same role as a "footprint" (... in a lib, or 
> "element", when placed on a board - as of gEDA/pcb terminology).
>
> A subcircuit does not have special objects like "pins", "pads" or 
> "element-lines". Instead, it has the same objects that the layout has: 
> lines, arcs, polygons, text and vias. (In fact I am going to use the 
> same C struct that the board uses, which is pcb_data_t in pcb-rnd).
>
> Trick #1: flexible layer handling
>
> Just like a board, a subcircuit also has a layer stack. When the 
> subcircuit is a footprint, this layer stack is not a particular 
> physical stack, rather a recipe. E.g. instead of fixed layer numbers, 
> this stack would contain patterns like "this layer should be in the 
> top copper physical layer on the board". It could indirectly reference 
> any physical layer: copper, silk, mask, paste, outline; top, bottom or 
> even inner layers. Once the subcircuit is placed on a board with an 
> actual physicla layer stack, the layer binding is performed: with or 
> without interactive user intervention, using the layer stack recipe, 
> each layer the subcircuit uses is boud to one of the actual layers of 
> the board.
>
> Trick #2: flexible terminal handling
>
> Just like in tEDAx, pins/pads are no special objects but plain drawing 
> primitives tagged for a given terminal. Terminal is the "pin number, 
> pin name" concept. A multiple vias, lines, arcs, polygons or even text 
> objects can be tagged to be part of a terminal. The netlist sees 
> terminals only.
>
> Result:
>
> In practice this means our new footprints will be capable of hosting:
>
> - arbitrary shaped pads drawn as lines and polygons
>
> - arbitrary shaped copper objects not being pads; a.k.a. pcb antenne; 
> but this includes copper text or mask cutout text too; your company 
> logo can really be a footprint
>
> - arbitrary mask cutouts, mask cutouts that are not derived from pads
>
> - arbitrary placement of paste; want a grid of paste blobbs on the 
> center pad of your largish qfn? no need t emulate it with 10 pads, 
> just draw them on the paste layer
>
> - slots or other cutouts/edge-contour-patterns; even the whole board 
> shape can be a footprint
>
> - text and polygon on silk
>
>
> Schedule
> ~~~~~~~~
>
> This will probably take a long time, spanning multiple development 
> cyclces, just like the layer rewrite did.
>
> Stage 1:
>
> We will start implementing it in the current cycle and will make it 
> gradually grow until it reaches its full featured, final form. We will 
> make sure that at every intermediate release subcircuits are usable 
> and alreayd provide extra features over footprints. We will keep the 
> original footprints in place during this process.
>
> Lihata board v3 will have support for subcircuits. The subcircuit 
> subtree will also be avaialble as a subcircuit file format for sharing 
> footprints.
>
> While we are in this stage, we'll encourage users to use subcricuits 
> instead of footprints, and always save in lihata board v3 instead of 
> other formats. However, the code will still be able to use the old 
> footprints in parallel.
>
> Stage 2:
>
> At some point in time subcircuits will be capable enough to replace 
> footprints. At this point we will remove footprints, pins, pads, 
> element-lines, element-arcs. We will also need to rewrite import code 
> to convert old elements to subcricuits on load and rewrite export code 
> to convert subcircuits back to elements for old formats.
>
> Stage 3:
>
> We'll convert pcblib from the old, element based .fp files to lihata 
> subcircuit files. We'll rewrite the parametric footprint scripts to 
> generate lihata subcircuits instead of pcb elements. This will include 
> extending some of the parametrics with features that was not possible 
> with pcb elements because of the limitaiton of the model/format.
>
> (This also means our parametric footprints won't be available for pcb 
> mainline without a conversion or without mainline upgraded to lihata 
> formats and the subcircuit model)
>
>
>
> What you can do to help
> ~~~~~~~~~~~~~~~~~~~~~~~
>
> Most wanted: testers. We are again going to change a critical part of 
> the system, we need all sort of testing. Testers with even only a few 
> hours a week are very valuable for getting such new features stable.
>
> Second most wanted: contributors on non-coding material (e.g. docs, 
> tutorials, test files)
>
> Production users: people who use the stable version of pcb-rnd for 
> actual production boards and report bugs. Especially those who are 
> willing to try out new features that are already labelled stable by 
> developers.
>
> Programmers: we have a growing number of developers and contributors, 
> but there's always more work than resources, obviously. Anyone is 
> welcome if they have some free time and willing to accept the pcb-rnd 
> ways of doing things. Be part of one of the most dynamic projects of 
> gEDA!
>
> Regards,
>
> Igor2

- Raw text -