kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Wed, Jun 04, 2014 at 12:13:42PM +0200, Tomasz Wlostowski wrote:
> - board outline

PCB Edges, check.

> - mounting/mechanical assembly holes

Drawings? check

> - mechanical component assembly outlines

Do you mean the enclosure? another drawing layer

> - one or more dedicated layers for mechanical dimensions

Drawings? 

> - PCB corners for manual cutout

No idea of this. I presume yet another drawing layer.

> - peel-off masks for wave soldering of THT components (2x)

Missing, could be useful but often is prepared by the fabricator.

> - panelization drawing

Panelization issue, CAM people problem :D

> - component courtyards (x2)

Missing, *could* have behaviour attached (DRC)

> - component body drawing (2x, for hand/semi-automatic assembly)

Fabrication? missing (adhesive seem to be repurposed for that). Also
special behaviour for refdes (plotted always on origin).

> ... 12 in total.

I'd say that would be two coupled pairs with behavious (fabrication and
courtyard) and, let say, about 6 general-purpose drawing layers. If we
design some kind of rule for pairing (something like 8 general purpose
layers and 16 general purpose *paired* layers) dispensing and other
things don't need to be catered for explicitly.

> I thought adhesive layers are for SMD glue dispenser machine. The person
> doing manual assembly may need another technical layer (and silkscreen is
> often useless for densely packed components).

Glue programming (when needed) is usually done by the fabricator while
programming the pick and place, it's more of a CAM issue. You need to
know exactly the kind of adhesive and stuff... then you could define
'pads' on that layer to define the dispensing. AFAIK that was the
original meaning of that layer.

> IMHO drawing the courtyard using standard graphics primitives on a dedicated
> layer is the least disruptive way of achieving above.

Agree with that. Ideally courtyard would be zone-based, but at the
moment we don't have zone support in modules, so lines are a good
compromise. And of course DRC code for this need to be written (however
even only eyeballing the layer catches a lot of placement errors in my
experience).

> What would be the issue to add them to the sexpr file formats, that are
> meant to be extensible?

Ask Dick. Bring asbestos suit :D

> - write a type safe flag container (based on std::bitset, I guess),

More or less ready, I have a pervasive enum for that (I'm working with
64 bits); should be replaceable with something more 'heavy' without big
problems. Except for literals, these are a problem (unless we dare to
use the new C++ literal facility). And IIRC there were
some ideas about efficiency concerns passing such an object around.
Remember however that 90% of the layer bitset use is only for pads, it's
less pervasive than expected (most things are only one layer or a range).

> - refactor the current layer set to use it,

Do you mean the LAYER_NUM type and machinery?

> - add a possibility to rename any layer (without changing its purpose),

Talking about these things is treacherous, be warned. Thicken asbestos
suit and look in the mailing list archives.

Also: problems with mismatching names/number between board and libraries
and so on (Altium says: decide once and then it becomes a system global
definition; could not be the best design choice...)

> - add new layers,
> - add show/hide options and layer grouping in the layer manager.

In short the UI for layer management; grouping could be seen as a bonus
IMHO is not so essential (gimp survived a long without that)

-- 
Lorenzo Marcantonio
Logos Srl