www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2015/12/22/10:17:34

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=googlemail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=xF6Fg2bdVInqB4Nz2LWk8Q2UYflU8Lq8IJOnu4ki6FU=;
b=fYwD7zhyExczEO/AzJYr9jo7ZD6/LjHIcPrstp4/TfSzWtmANr/FGb2RUslzRMvme4
y+l2mQjV/1e4x/ifSY3/HLaPlwt6SJkB9TsxgPhLMAETrpjzJ8X8GmHoTfUVKIf2hDgz
TcMQY/LsuG5o+5jfMr7PxUs4UZPbi/a8QthXgBPZgDYh9+o62hBBiVShl+XGKdGJ6LWz
jk8TnmMcK5B9DHWmL0jA+8dGGkI02Rq8gtHeBuzcM7b075a9oJYbgNGNZmZL4v3SiMqc
8t7savofPPbFTzJdQoWomg4pkR38GImsayRaxQj6I+Cut2RMDZC9K3EB9poZ/oTUmIWS
cWjQ==
MIME-Version: 1.0
X-Received: by 10.182.24.9 with SMTP id q9mr10847494obf.73.1450797446447; Tue,
22 Dec 2015 07:17:26 -0800 (PST)
In-Reply-To: <20151222154327.228d6470b6b550ac9180e27b@gmail.com>
References: <CAJXU7q9ToaWE+wVJcF76yqHhjYZc5j95VL64cXPey-x4s_j9OA AT mail DOT gmail DOT com>
<20151222140345 DOT 07f48e9256784e9bf0718efa AT gmail DOT com>
<CAJXU7q-OZPu9ebYuaymbqVLbWQpSt0q=ntjihS5rK6Hs=N2-Og AT mail DOT gmail DOT com>
<20151222154327 DOT 228d6470b6b550ac9180e27b AT gmail DOT com>
Date: Tue, 22 Dec 2015 15:17:26 +0000
Message-ID: <CAJXU7q9xZrALJnjQ6pfNTfcCvxdKm2SuqP4niSz1yTQMLeBp4Q@mail.gmail.com>
Subject: Re: [geda-user] Cross project collaboration on data models
From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA User Mailing List <geda-user AT delorie DOT com>
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id tBMFHUbL030288
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

Hi Nicklas,

I started a new thread to avoid hijacking your which was discussing
data-structures.... Can we keep this one on the topic of cross project
collaboration please? (Way to early to be diving into the design).

I presume from your thoughts on this, you're considering doing some
development work on gEDA or PCB? If that is so, please let me take
this chance to welcome you.

Best wishes,

Peter Clifton

On 22 December 2015 at 14:43, Nicklas Karlsson
(nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]
<geda-user AT delorie DOT com> wrote:
> No time to edit or read it now, but I wrote this yesterday:
>
> There is a basic problem then grouping objects:
>   1. Each object could have an attribute to tell which group/parent it belong to: layer, sub-layout, footprint, padstack, ...
>   2. Objects could be embedded in group/parent 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 at the same time because of need for overlap.
>   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.
>
> 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 Tue, 22 Dec 2015 13:30:15 +0000
> "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> wrote:
>
>> Hi Nicklas,
>>
>> What you appreciate about gEDA is one of its fundamental early design
>> choices (way back before my involvement in the project), and one of
>> the strongest aspects which makes gEDA what it is. I am not trying to
>> change this - and it would be an aspect of any cross-tool open EDA
>> data-model we would have to ensure was represented in order to fit
>> gEDA's needs.
>>
>> I'm perhaps focusing a more on the PCB side (where our existing
>> data-models and file format most often causes problems),
>>
>> PCB often bumps into limitations with its file-format not expressing
>> certain design aspects / concepts, and often needs to be extended in
>> an ad-hoc way. One key aspect I need to get in at some point - is that
>> of a mechanical outline.. which is one of the key missing pieces
>> holding back my 3D board export code from moving upstream. (My
>> test-code takes a guess based on some heuristics, after looking at the
>> outline layer, but this non-semantic data is a "bad idea", and not one
>> I'm prepared to push upstream).
>>
>>
>> One distinction to draw, is that data-model and file-format are two
>> distinct topics. They are very much related, but - for example, one
>> could have multiple file format which all represented information
>> according to a common model. In the case of my mechanical outline,
>> this is very easily modelled by the software (as a polygon
>> representing the board shape), but no file-format to load/save it
>> exists yet.
>>
>> A more complete treatment of board shape might require a more complex
>> models.. take for example a flex circuit - where the board can have
>> different shapes per layer. There are a lot of situations to handle
>> correctly - and ideally, in a forward compatible way (or get it right
>> first time!).
>>
>>
>> To take another PCB example - lets say pad-stacks. Some CAD systems
>> define these explicitly, and reference those from the board design,
>> footprints etc.. gEDA/PCB does not, it stores (rather limited)
>> information about pad geometry in-situ, for each pad instance, for
>> each component instance in the design. Our data-model has no concept
>> of a referenced pad-stack, which means it is not convenient to make
>> mass changes to all instances of a particular type of pin/pad/... on
>> the board. (Software would need to pattern-match / guess which pads
>> are supposed to be the same - no semantic information exists).
>>
>>
>> Peter
>>
>>
>>
>> On 22 December 2015 at 13:03, Nicklas Karlsson
>> (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]
>> <geda-user AT delorie DOT com> wrote:
>> >> I think this is of critical importance to allowing a (currently) smaller
>> >> player like gEDA to survive amongst more successful / active projects.
>> >
>> > Only reason I used gEDA is because of thin bindings which allow to start with a simple sketch without all details and fill in more information then needed. Start of a new circuit is usually a simple sketch or block diagram altough some components only have one order number others like capacitors,resistor have diferrent values,sizes and order number may be the last step or may even change after board have been delivered.
>> >
>> > If it is possible to use fileformat from other software I however think it is a good idea. To copy some other software I think is rather pointless because in such I would be better of start using it directly.
>>

- Raw text -


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