kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

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


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

#layer group definitions

  (layer-groups
     (group assembly-drawing-top
	(layers F.Cu Edge.Cuts F.Courtyard)
     )
  )

)


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

  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