Mail Archives: geda-user/2015/12/22/16:04:59
On 22 December 2015 at 20:01, Britton Kerin (britton DOT kerin AT gmail DOT com)
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
>
>>> FWIW, My "branch" with the later OpenGl stuff, and 3D support is way
>>> more like a fork now, than I'd ever intended it to become. The
>>> intention is to merge it, but the blocking problems regarding
>>> data-structure and file-format additions have still not been resolved,
>>> and my free time has (in complete generality) been reduced a lot.
>
> What problems are these exactly? I have honest plans to work on the file
> format, first simply by separating the parser from the innards of pcb (there
> will be a new data structure that corresponds one-to-one with file format).
> If there are modest incremental changes that would be useful I'm interested
> in hearing about them.
So - 3D export (even with the scary and dreaded STEP), is actually
pretty easy. What we are lacking is two simple pieces of data...
1. Outline shape of the board.
I do not want to merge the demo code I have, which (crudely) tries to
guess at the board outline - much like a fabricator does, by piecing
together objects on the magic "outline" layer. This goes firmly
against my intentions to produce more "semantic" data in PCB, and less
"magic named layer, geometry interpreting heuristics".
By all means - we can merge the heuristics, but it needs to be
user-activated process that generates the formally defined
board-outline based on the data handed to it - not an auto-run process
like I currently have in my branch.
If it were to auto run to produce the 3D data, we could get to the
point where we can _never_ change the heuristic without risking
breaking people's output. At least if the user must manually run the
heuristic, I can care a little less about whether it _always_ produces
the same result from version to version. (The user can decide if they
keep the answer or not).
2. Board thickness.
So simple solution - define some data-format addition, and/or
known-named attribute to specify 2., and add a syntax to throw a
polygon definition into the board file for 1.
Sadly - I don't like simple :(... and failed to take the easy route on
that. Simple doesn't account for flex-rigid stack-ups (different
shapes and thicknesses with each stratum), more than 2x outer-layers,
I felt that PCB's format is a mess, and that tacking on more advanced
concepts without sitting down and having a good think about wider
needs / use-cases was not the way to go.
AP210 (sorry!) has a layer shape / stratum model which could be
sub-set (admittedly it is fairly complex).
I guess what I'm saying - is we need to add physical stack-up and
outline information to PCB. Get it right, and we solve:
a) The physical DRC aspects of blind / buried vias
b) Specifying, in a machine-parsable way, the construction of a flex-rigid board
c) Specifying in a machine-parsable way, the construction of a
conventional PCB board.
(Note on c), I believe STEP AP210 actually has a set of entities which
can fully define a board stratum set / stackup... and there is a non
FOSS, but freely available tool called IDAStep that can view / parse
these).
I already did some work on extending the polygon representation to
include circular arcs (often present in PCB outlines) - we just need
some data-structures to tie a PCB "POLYGON" as a stratum outline,
define its thickness, and somehow reconcile the physical strata with
PCB's "layer stack". (The fact we can have multiple layers which
combine to give one physical layer is not a design feature I like, but
we're stuck with it).
Some of the stratum (core / prepeg etc..) layers will probably need to
be auto-generated (assumed geometry), since we don't define their
shape in PCB - or perhaps we need to have an "inherit from master
board-outline" button somewhere.
I'll not be far from being able to generate a _complete_ 3D model of
the board (if that level of detail is desired). This is not warranted
for simple mechanical / electrical co-design, but (I'm told), would be
quite useful for high frequency design / finite element modelling
etc..
Peter
> Britton
- Raw text -