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=date:from:to:subject:message-id:in-reply-to:references:mime-version
	:content-type:content-transfer-encoding;
	bh=CitRZFXuNGOfgQ9hUA71gT64Y74/MT5hL4XTHVet8NA=;
	b=InHc17hyoc70LSHRs/c26uA7PkBPrI3lPLfIdclkJTdnX97TEJyq83TYCkNW3w4+JN
	TH5xCox44hsj+KePWUi29jpifxJOPOCozLDCpWt3wgHk289McyOrqHrpu0NoyUG1KUdo
	IN6VMUWBwS8I0I8u/n2zDXFF69Ww5VqbnN9ebnQSi7+SaAfhxB3eBszWB/OhvUQ8ugRN
	KTpB69n4dey7PuFLC1YUGNTZ8URI0nda+7AJOe50nZPsplecwi1FLu1mwf6o5F74BCP+
	/oR4tZ8hVitT4nE7AbDbD2ngNmPdsTPswFNVAzbjMNr2FKu6Olkb23atRcKuFAkC4CZB
	TF+g==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to
	:references:mime-version:content-type:content-transfer-encoding;
	bh=CitRZFXuNGOfgQ9hUA71gT64Y74/MT5hL4XTHVet8NA=;
	b=GTAer6du1Ra8YE04qY22WPqNyUghhwFfEGAlcpaKT+VjSlflLItrRc8UwV+2PqV3m6
	bdAlJDld+fsYjvtBf+jMv5IpvOIzD3/4LcZXSDF/+D+L2Gv6ENQjx6KcvXMvBzYci1tJ
	62id08yz4le5oZoNf7Vlh/+ucPH9pfYWL+SJi3Dag0z90M1W2AzGBhjQnTD1OJxm5XT0
	dQNWMzFlc8xBBk6/PpYmrfggXzA1etpcp/pUnBUVAATpTuN71E/jx7mNrINph/uvRbeG
	8c0KpQ3OJfOeW+azw0EplzWIlr+geH/JgIOAK4+DMujA/OnW1zu/0AsgJGy6tAlDJOBl
	855g==
X-Gm-Message-State:	AG10YOScO1FX7+O/dRDIokP4LTzdofJ0Eo1ebuLby59CJd6swcebXMAV0Q/bMahNQst5dQ==
X-Received:	by 10.28.73.70 with SMTP id w67mr2048442wma.31.1453452554397;
	Fri, 22 Jan 2016 00:49:14 -0800 (PST)
Date:	Fri, 22 Jan 2016 09:49:09 +0100
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
Subject:	Re: [geda-user] PCB data structures (was: features: layers stack,
	padstack/vias)
Message-Id:	<20160122094909.08704cd6e4dfc8a35e1ac734@gmail.com>
In-Reply-To:	<CAC4O8c-jS6spZU0yh3oZJ02G9GU7pE5hwvP2O_LfC9k6dCD96A@mail.gmail.com>
References:	<1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG>
	<20160106143629 DOT 4D39D809D79B AT turkos DOT aspodata DOT se>
	<CACwWb3BXbnQXs+DwVVzmC8DrhwOYxPgVyUhZTPL9bM9cJbHimw AT mail DOT gmail DOT com>
	<20160106164022 DOT D0D4E809D79B AT turkos DOT aspodata DOT se>
	<20160106180912 DOT 42ddf4079d91384f206b7c35 AT gmail DOT com>
	<20160106191433 DOT 5dc5cb59 AT jive DOT levalinux DOT org>
	<20160106202817 DOT 56197b2c539d426a1b724c9e AT gmail DOT com>
	<568E09ED DOT 1080508 AT m0n5t3r DOT info>
	<CACwWb3AhSh-+NNu--bVMGZBfjaoA+hHg7gbXnoyNv3oMq=e17g AT mail DOT gmail DOT com>
	<568E6354 DOT 80302 AT m0n5t3r DOT info>
	<20160108002640 DOT 03233b24 AT jive DOT levalinux DOT org>
	<20160108175259 DOT 127a3f073616758434f7edff AT gmail DOT com>
	<20160109020345 DOT 1e07cb84 AT jive>
	<CAC4O8c-nqs2+9rgsD-Gsks-wSmJ1eCkJ9PFMi3XqMrYE2FO3Ew AT mail DOT gmail DOT com>
	<20160109112851 DOT 1129dc38 AT wind DOT levalinux DOT org>
	<CAC4O8c_tFOOXCA5ABEMuSU8BnXMZWauV+uJYy-TJO7nJYBS9+A AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 11 DOT 1601111649470 DOT 5421 AT nimbus>
	<CAC4O8c-jS6spZU0yh3oZJ02G9GU7pE5hwvP2O_LfC9k6dCD96A AT mail DOT gmail DOT com>
X-Mailer:	Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
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

> > The PCB layout has an object of type pcb_layout as the root object, which can contain an arbitrary number of pcb_layer objects--which in turn contain the geometric primitives--and pcb_element objects which aren't associated with a layer.  Objects of type pcb_polygon can have child objects of type pcb_polygon_hole:
> >
> > pcb_layout
> > +- pcb_layer
> >    +- pcb_arc
> >    +- pcb_line
> >    +- pcb_pad
> >    +- pcb_pin
> >    +- pcb_polygon
> >       +- pcb_polygon_hole
> >    +- pcb_rat
> >    +- pcb_text
> >    +- pcb_via
> > +- pcb_element
> 
> Sounds reasonable, and similar to what we have now but with much cleaned up
> naming and hierarchy.

I would say then looking at data layer by layer there are: arc, line, circle, polygon and cutout of these drawing primitives.

Pad/pin/via is a composite of these drawing primitives on different layer, this is the case no matter how they are represented. A hole is equal to a round cut out usually thru all board layers with or without plating. Text is probably also a composite of other drawing primitives.


> > A footprint (element definition) has a pcb_footprint object as the root object which can only contain objects of the types pcb_element_arc, pcb_element_line, pcb_pad, and pcb_pin:
> >
> > pcb_footprint
> > +- pcb_element_arc
> > +- pcb_element_line
> > +- pcb_pad
> > +- pcb_pin

There should probably be: arc, line, circle, polygon and preferably cutout of these primitives. It would be useful with possibility to assign drawing primitives to a layer. Pad, pin and also via is a composite of the drawing primitives even though a short hand notation may be useful. Vias and holes without a pin number are also useful. I guess it should be possible to assign the pin numbers to any of these objects and in such case a pin connection point with arbitrary shape could be done, it would probably only make sense to connect to copper layer but this is probably more of a drc check.

It would be useful with possibility to reference predefined via/pin/pad or connection point from a library.

> When I originally referred to creating a new structure, I had a more humble
> goal in mind:  I just wanted something like PCBType, minus all fields that
> don't go in a pcb file (e.g. the rtree), plus everything not reachable from
> PCBType that does go in a pcb file (e.g. the grid stuff from Settings).
> 
> I've since become even more humble and decided it might be better to just try
> to add a little bit to PCBType such that it consists of a superset of what
> goes in a pcb_file.  This would be a slightl improvement over the existing
> situation (which is that PCBType is neither superset nor identical set).
> 
> I think you have slightly different purpose in mind of creating a foundation
> for a pcb API.  I don't like the idea of an API based off PCBType either,
> but my present goal is a bit more modest than a full API, so I'm not sure
> I want to tackle that at the moment.  It it does materialize I'll be happy
> to use it as a basis for an on-disc format though :).
> 
> Britton

It would also be useful if information with possibility to add information to any of the objects about which sub circuit it belong to. If it is possible to store which sub circuit an object belong to it could be used for example to select all objects belong to a "power supply" even though shape is irregular either for simply moving it or reuse it somewhere else. It would also be useful for multichannel design.


Nicklas Karlsson

- Raw text -