www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2015/12/20/21:05:19

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]" <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: <CAOFvGD6OiYxcGkOiQRVnvXW3TLs42bt7PE5Ot9s09hsukYicKA@mail.gmail.com>
References: <CAOFvGD6OiYxcGkOiQRVnvXW3TLs42bt7PE5Ot9s09hsukYicKA 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

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]" <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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019