www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2015/12/20/20:37:50

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=nFCEhBVGZQmsHzq8f2uOS61m/e4quSlZmJeCrysRMyE=;
b=Q5EqBilh5F0Px4MRULIRabB/DQabYwYC6FNsToE8/5u6gUSoD+Z5TOnjARfBvGOiIV
2BsrQ788Lhzx5AiyNhEiztKG2XRYi7OKt8GZaoWdn7RU5z4ISLFtF4lRr+jzHj9RTXbi
Bap08meJ8L26JXhWQRvSuseqSKujQ+U3NJeWRM+M2g1dmrwjsTRJBHUMKYEgNITcsg2o
ucW0nmEtMwfnIG6hywvFK4XDckMlLKAkJAi6uaeG0hiNDvibAPf2W09hvZT6g9T0Sqyt
CRqoNac9xH6fWQaeKexpFs96ZNP5r71vpAgJEkggLw361QCXxQoN+q9/sJHvCvQ42mC7
xSRw==
X-Received: by 10.194.7.230 with SMTP id m6mr17493793wja.124.1450661851678;
Sun, 20 Dec 2015 17:37:31 -0800 (PST)
Date: Mon, 21 Dec 2015 02:37:30 +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: <20151221023730.1cc8237648d37123bbc9fc5c@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

I am almost certain there must be a possibility to add attributes to any object.

* Padstacks:
The ordinary drawing objects and an attribute to tell which layer(s) each drawing object belong to. Wildcard is needed for at least inner layers if padstack is a hole or for other reason like extra copper on layers below for heat dissipation, copper cut out for antenna. It would be useful to store padstacks in a "library" or sub folders for each package type: lqfp, qfn, SO, DIP. Then using a padstack in a footrpint a local copy is stored and reference is kept so that update is possible. It would be possible with a local change and if only one of several pins is changed a copy could be made for this pin but reference is kept so update is possible.

* Blind and buried vias: Also ordinary vias
Same data structure could be used as for padstacks but method to add them is different. I guess only difference between ordinary via is which layers they span. Add by layer change might useful?

* Repeated sub-layouts (picture a 16 channel audio mixer)
Either each sub layout need a reference to the objects which may be impractical or eacho object need an attribute to tell which sub-layout it belong to if any. This is also useful for single channel objects so they could be selected even though they have irregular shape.

* Internal cutouts
An attribute to tell which layer(s) the cut out belong to or other method to place the cut out on layers. Maybe ordinary drawing objects possible with some limitations could be used with an attribute to tell it is a cut out. It might also be useful to represent solder mask as a cut out but in such case of course the necessary drawing objects must be available as cut outs if there is a need restrict drawing objects used for cut out.

* Ability to remove solder mask from arbitrary traces and areas
A cut out placed on solder mask layer.


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