Dick Hollenbeck a écrit :
jean-pierre. charras@gipsa- lab.inpg. fr
<mailto:jean-pierre.charras%40gipsa-lab.inpg.fr> wrote:
Dick Hollenbeck a écrit :
I meant to say specctra syntax, not specctra format. There is no
specctra format that can fully describe a board. Briefly, there is the
DSN format and the SES format. The DSN describes the copper layers
only, no technical layers. No text. The SES format describes a subset
of the copper layers and has less information in it.
I did not understood that.
So, I do not see any problem to use the Specctra syntax.
One or more sample board files should be created then before any coding
is done IMO, using a text editor and a brain.
Ok. I have already a text editor.
I think this process is easiest to create the sample(s):
1) load a DSN file from the specctra_export into a text editor or have
it as a hardcopy printout nearby for reference.
2) load an existing board file, one with multiple layers, components,
tracks, vias, drawings, and multiple zones.
3) copy the board file to a new window, and convert it to the new
syntax, but incorporate some new concepts. This is an object
conversion, not so much a line by line conversion.
New concepts in the file:
** Special layer names. Any technical layers, plus front and back
copper, should get fixed names rather than layer numbers
** Layer sets as discussed.
** unit_res see this in the specctra spec, it allows different regions
in the file to to have different units. each unit_res has a limited
scope of applicability.
** use concise element names, pay attention to frequency of use. no
element should have a lot of unnamed parameters, but instead use nested
elements to make the file self documenting.
** the first copper layer is number 0 but has a special name 'front', in
addition to any name the user gives it.
We also can use keywords instead of numbers like in Gencad format (see
export_gencad.cpp)
layer identification use TOP, BOTTOM, INNER1, INNER2, SOLDERPASTE_TOP ...
and no numbers.
Questions to be answered:
** which coordinates should coordinates be relative to the origin of
their containing object, and which should be relative to the board?
Perhaps all should be relative to their containing object.
All should be relative to their containing object.
Generally speaking, data in files must give properties and never the
internal coding used in Kicad
(like internal units, internal angles units, Y axis orientation ... )
Also in a perfect world (well, or file format) the usual Y axis
orientation must be used, instead of the reverse Y screen orientation
(like now).
** Do you introduce a (transform ...) element, so objects can be
presented in a uniform un-transformed way on the front layer? Here the
specctra spec will be helpful.
Gencad format also use transform elements ( keywords like ROTATE
<angle>, FLIP, MIRROR) and give always the un-transformed description of
footprints.
Seems a good idea.
Jean-Pierre, do you want to do a board like this? Do you want me to do
one? Or should we both do one and combine the concepts later?
Dick
I'll start this work asap.
But i am thinking 2 brains are better than one, and combine the concepts
later is a good idea.
So feel free to also create such a board.
