kicad-developers team mailing list archive

[Jean-Paul Louis <louijp@xxxxxxxxx>]

Thanks Wayne for the info.

Edge.Cut was not an obvious candidate for me, but I can live with that name, but I think it should one of the mandatory layers, not a user defined one. Every PCB will need an outline, and circles and arcs would be nice if allowed in outlines.

About the height of the parts, I agree with Tom that this should be a field in the Footprint itself, as that’s where the physical info (dimensions) of the part (pads, holes) is/can be stored. Height of the part is very important for placement machines, and is used to define the sequence of parts, i.e. the tallest parts are placed last. Usually not an issue with chip shooters, but down the line, it is critical for the IC and Odd Shape placer/inserter.

Jean-Paul
AC9GH

On Jun 4, 2014, at 4:48 PM, Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx> 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...
> 
> 
>> 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
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp