On 6/4/2014 4:48 PM, Tomasz Wlostowski wrote:
On 04.06.2014 21:35, Wayne Stambaugh wrote:
On 6/4/2014 2:33 PM, Lorenzo Marcantonio wrote:
On Wed, Jun 04, 2014 at 02:20:12PM -0400, Wayne Stambaugh wrote:
user confusion. Where would you save them in the old kicad_pcb file
format after you made changes? If Pcbnew where a read only
application,
then this would be less of an issue.
That's why I questioned if it would be desiderable...
The only thing I think would be possible to keep *backward*
compatibility is using optional forms, so if you don't use that feature
the file remain compatible (no strange layers and the file still loads).
I changed the quotation rules for the sexp in a backward compatible way
and now they are both LISP and kicad compatible.
Backwards compatibility is not optional. We should always be able read
older board and footprint file formats. That was one of the things that
drove the design of the current layer parsing of legacy boards and the
design of the new layer sexpr format.
Hi Wayne.
I understood Jean-Pierre's statement as "old version must be able to
read files written by a newer version". Given that the current parser
drops errors on unrecognized entities, it gives little space for file
format enhancement...
Only for users running old versions of Pcbnew. There is a version
number in the kicad_pcb file header that can be used to tell the user
that the version of Pcbnew they are using is too old. I don't see this
as being a big issue as this has always been the case, even with the
legacy file format.
I think we should steer the discussion towards defining what
improvements we need to make to the board and footprint file formats to
support the changes we have been discussing. Once that is defined, we
can discuss the code changes required to handle the new layer
definitions. Everything else depends on getting this correct. Here is
a sample layer definition:
Sure.
(layers
(15 F.Cu signal)
(0 B.Cu signal)
(16 B.Adhes user)
(17 F.Adhes user)
(18 B.Paste user)
(19 F.Paste user)
(20 B.SilkS user)
(21 F.SilkS user)
(22 B.Mask user)
(23 F.Mask user)
(24 Dwgs.User user)
(25 Cmts.User user)
(26 Eco1.User user)
(27 Eco2.User user)
(28 Edge.Cuts user)
)
If we assume layer IDs are subject to change, my suggestion would be:
(layers
( define-layer
# F.Cu, B.Cu, etc. Engraved in stone. Canonical names are the only
allowed way to refer to a layer in a s-expr file.
canonical-name
# name displayed in the UI (and nowhere else)
(display-name name)
# new type: split plane
(type signal/mixed/power/jumper/split/user)
# generic attribute list (type-length-value). May be used to pass
permittivity/dielectric thickness parameters
(attributes ( ... ))
# defines the layers paired with us. User layers can be also paired.
(pairs-with canonical-name)
)
The original layer definition ordering should be preserved so where []
== optional:
(LAYER_NUM CANONICAL_NAME TYPE
[(display_name NAME)]
[(pairs_with CANONICAL_NAME)]
[(attributes ATTR1 ATTR2 ... ATTRN)])
#layer group definitions
(layer-groups
(group assembly-drawing-top
(layers F.Cu Edge.Cuts F.Courtyard)
)
Since this would be in the layer definition we could shorten it without
loss of readability to:
(groups
(GROUP_NAME CANONICAL_NAME1, CANONICAL_NAME2 ... CANONICAL_NAME_N)
)
New canonical names are:
F.Courtyard
B.Courtyard
F.CourtyardZ
B.CourtyardZ
F.Keepout
B.Keepout
If inner layer keep outs are desired, add:
Inner#.Courtyard
for vertical keep out areas to prevent pick & place machine plunger
crashes on tall components.
How about defining a height attribute for each component? In the future
it could be used by DRC to define pick&place thresholds.
The footprint definition would be the appropriate place to add it with
something like:
(front_courtyard_z ENCLOSED_AREA_GEOMETRY_LIST (height HEIGHT_IN_MM))
