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=wzUpZ5NHMhJc7UWsk9ewJIvCT2L7AgzSb7fvgIcjd5c=; b=W+H8YoZF1J2RuiPBc3cf9nGQ7wxTRSMNNFD1AMuCt552awy95T6BjwJUnl1XToGikx 6KZ9MHlAfp28VHE7QL/u2Ru88IGMNbmPdDSOAdXvaJnfFlFOfB043EFeI2k4jyWRnKDV 3WbvpYfJvQ4fEGjieAdIsbWoHqGuWyLgyT6mt25sv9rplc5J+rJfu/O4sFVNA+M/88Wc tQyyjo2k3z0rinhiqpGt8mutXQ5tXZknpxV2swxwTF6eg44lfF8+1qqxULIF7ryCar6h 7ccTNiQ6oqG5VslZdJMzD2Cg307v2/B2pFEdVgMfEyHbu7vTbfSlHoWbEgJtVliJczgo PDNw== X-Received: by 10.194.216.100 with SMTP id op4mr3979790wjc.85.1450663493520; Sun, 20 Dec 2015 18:04:53 -0800 (PST) Date: Mon, 21 Dec 2015 03:04:51 +0100 From: "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] Proposing a New Hierarchical Data Structure? Message-Id: <20151221030451.02399163eb3e40f21c622c41@gmail.com> In-Reply-To: References: X-Mailer: Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Precedence: bulk There is a basic problem then grouping objects: 1. Each object could have an attribute to tell which group it belong to: layer, sub-layout, footprint, padstack, ... 2. Objects could be embedded in group for example between a start and an end delimiter. This will not work if an object should belong to both a layer and a sub-layout and a footprint. 3. In each group: layer, sub-layout, footprint, ... the object is referenced but in such case it must have an identifier. This is about creating objects: which could be done either by copy or reference. I think (2.) is used then creating an object for example a padstack within a footprint or creating drawing objects within a padstack. For objects possible to reference for example then creating padstacks from library of padstacks it is useful to store both a copy and the reference so it could be updated if changed. (1.) Is used to assign already existent objects to a group, this is probably very useful for objects hard to reference like for example put a line on a layer and sub-layout. On Sun, 20 Dec 2015 19:15:14 -0500 "Jason White (whitewaterssoftwareinfo AT gmail DOT com) [via geda-user AT delorie DOT com]" wrote: > I have taken the liberty of restating Nicklas Karlsson's thread in a > (hopefully) more productive manner: > > The purpose of this thread is to discuss the merits of various data > structures to represent (primarily) PCB Layouts and (possibly) > Schematics. The discussion of the of specific data encoding mechanisms > such as XML, SQL, Plain Text, YAML, and JSON is NOT to be discussed in > this thread (Please take it to a separate thread!). We are only > talking about structure and representation. > > In addition, this thread is not to contain discussion about low level > implementation details - Again, Only data structure and > representation. > > With that said I am looking for ideas regarding the most general > way(s) to represent multilayer PCB designs with features such as: > (these are random things off of the top of my head) > * Padstacks > * Blind and buried vias > * Repeated sub-layouts (picture a 16 channel audio mixer) > * Internal cutouts > * Dimensioning > * Differential signal pairs > * Arbitrary footprint attributes (ie. showing resistor value, and > refdes at the same time on silkscreen) > * Representing RF structures (Better trapezoids and arcs) > * Elements rotated at arbitrary angles (not just multiples of 90) > * Arbitrary groups of elements (that can be rotated) > * Arbitrary shaped pins (groups of simple shapes) > * Ability to remove solder mask from arbitrary traces and areas > * Netlist attributes > > Feel free to post your thoughts on the subject, below are my thoughts: > > > Probably most PCB designs could be represented by using a set of basic > shapes ("graphical primitives") such as: > * Lines > * Arcs > * Polygons > * Circles > * Text > > If the data representation were to allow for groups of elements to be > treated as one, then if we had a footprint requiring a pin with > complex shape not, the complex shaped pin could be represented nicely > using a single group of primitives. > > One area where much improvement can be made is in the representation > of layers. All of the basic shapes should be drawable on every layer. > (For instance drawing arbitrary shapes in solder mask) For this all > layers should be treated the same by the format from the start all the > way up to the point that the layer is processed to produce the > Gerber/Artwork files. > > The most general representation would allow for any primitive (line, > polygon, etc.) to be assigned to any layer. While certain layers are > associated with certain outputs, it is necessary to decouple the basic > primitives from their function. (ie. a line ion the silkscreen layer > is just a line, not a special "slikscreen line"). > > There should be some common predefined layers for top and bottom. Now > stay with me, what I am about to propose may not sit well with some: > layers would be well represented as a 2D grid. Each copper layer (top, > bottom, inner 1, inner 2 etc.) would be a row in this grid. Then each > column would be the purpose of layer, for example "top:copper", > "bottom:silkscreen", "inter1:keepout." This would allow an arbitrarily > shape to be assigned to a layer such as "inter1:keepout." > > As for grouping: > * Padstacks could be represented using groups graphical primitives > * Pins are either a predefined padstack or a group of primitives > defined on the spot > * Footprints consist of a number of pins plus some arbitrarily placed > elements such as lines and text. > * Sub layouts consist of instances of footprints plus some arbitrarily > placed elements such as lines and text. > > > There are probably better ways than what I have proposed, feel free to share. > > --Jason White