kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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)
  )

>   )
> 
> )
> 
> 
> and use single format for saving layer sets, that is simply a list of
> canonical names:
> 
> (layerset F.Cu B.Cu F.Mask B.Mask)
> 
> Layer set entities could be automatically serialized from a flags object
> (if we decide to go for one instead of int/int64).
> 
> 
>>
>>  From the discussion, it sounds like we would need to add an F.KeepOut
>> and B.KeepOut for courtyard areas.
> I wouldn't call them "Keep Out" - courtyard defines the perimeter of a
> component, while a keep out layer in most proprietary software defines
> an empty area (no traces, no components).
> 
>  Maybe add F.KeepOutZ and B.KeepOutZ

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))

where ENCLOSED_AREA_GEOMETRY_LIST is a list of drawing elements that
defined an enclosed area.

Am I missing anything else that was part of the discussion?

> 
>   It also sounds like folks are interested in
>> naming layers so we can optionally add a (name "My Layer Name") element
>> to the layer.  This would allow users to define their own names for
>> display purposes.  The only thing I'm not sure of is layer pairing that
>> was being discussed.I would need a example of how that could be used.
>> So that would give us something like:
>>
>>    (layers
>>      (15 F.Cu signal (name "Front copper layer"))
>>      (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 (name "I put my comments here!"))
>>      (26 Eco1.User user)
>>      (27 Eco2.User user)
>>      (28 Edge.Cuts user)
>>      (33 F.KeepOut user)   # This could be any number > 32
>>      (34 B.KeepOut user)   # This could be any number > 32
>>      (35 F.KeepOutZ user)  # This could be any number > 32
>>      (36 B.KeepOutZ user)  # This could be any number > 32
>>    )
>>
>> You could use *.KeepOut and *.KeepOutZ for any module drawing element
>> (lines, arcs, circles, etc.) that are defined on both sides of a board.
>>
>> This should be a good start to get the discussion moving in the right
>> direction.
> Fully agree.
> 
> Regards,
> Tom
>