kicad-developers team mailing list archive

[Jean-Paul Louis <louijp@xxxxxxxxx>]

I am no Software expert, but I have seen quite a few different CAD Tools during my work life and they all have their pros and cons.
I am just an user, so I have a few questions relating to usability for the experts.

1 - Is there a reason besides legacy to limit the number of layers?
	What I mean is that a PBA (Printed Board Assembly) is a collection of objects.
	The PCB in itself is the most complex object in the collection because of its highly variable
	multilayer structure (Design related).
	So it could be described as a collection of layers that have different properties such as
	Board Blank (Mechanical/Edges Layer, Ground Plane Layers, Signal layers, Solder Mask Layers,
	Solder Paste Layers, Markings (Silk Screen) Layers, Revision (ECO) Layers, Component Layers
	(SMT and TH) and anything that does not come to my mind now.
	Using a collection for layers will allow easy backward compatibility.

	Tom’s description seems to be exhaustive enough to cover most of the entities that I have only
	two comments.
	1 - The jumper layer to me is redundant with the component layer as a jumper can be
	described as a component, a socketed IC, a heat-sinked device or a multipart connector can be
	treated as a compound component (module).
	2 - To me, the courtyard concept is part of the footprint, so it doesn’t need a layer. 
	It is only used for placement purpose (design rules) to carry manufacturing assembly
	constraints (its shape should be arbitrary).

3 - Is the fact that the Layer ID goes from 0 to 16 or whatever so important that it cannot be changed?
	I mean the sequential aspect of the ID number.
	If so, why not use 0 to 127 for the copper layers, and 128 to 255 for the other layers?
	That would still fit in one byte if byte is the limit, and I have yet to see a board with more
	than 128 layers.

I do not mean to criticize or offend anyone, I am just brain-storming with things that I have seen or missed in all the tools I have used from venerable DOS Orcad on a PC to modern tools like Cadence Allegro, Mentor PCADS or Altium Designer (including Protel), and hobbyist tools like Eagle or the PCB123 alike tools.

<Rant mode OFF>

Jean-Paul
AC9GH






On Jun 5, 2014, at 10:58 AM, Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx> wrote:

> On 05.06.2014 15:50, Wayne Stambaugh wrote:
>> 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)
>>   )
>> 
> Hi Wayne,
> 
> You and Dick are the experts of the s-expr file format, my proposal only outlined what sort of entities we would like to add to get the features we need.
> 
>> 
>> 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))
> I wouldn't reserve a special entity for the courtyards, IMHO the layer may contain graphic shapes just like other user layers. Height could be an attribute of the component (like a value), the DRC should take these two into account when checking component clearances.
> 
> BTW. Is there a way of defining a list of 3D models for a footprint in the sexpr footprint format?
> 
> 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