kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

On 04.06.2014 13:59, Lorenzo Marcantonio wrote:
> On Wed, Jun 04, 2014 at 12:13:42PM +0200, Tomasz Wlostowski wrote:
> > - board outline
>
> PCB Edges, check.
>
> > - mounting/mechanical assembly holes
>
> Drawings? check (...)
> > ... 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.
Lorenzo,

I fully agree, these are mostly general purpose layers. But we don't 
have enough of them.

> > 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.
I want to reinforce our point here: we are not the ones to tell how the 
general purpose layers are to going be used. If somebody prefers to 
define glue placement right in the PCB application, (s)he should be able 
to do so.


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

Sure. With the new geometry library, checking courtyard clearances will 
be peanuts ;)

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

Could you share your code? I'm not concerned very much about 
performance. My experiments with wrapping each flag in a static object 
showed that in assembly it's a difference between:

and,or,xor [variable], mask

and

mov eax, [mask_from_class]
and,or,xor [variable], eax

> > - refactor the current layer set to use it,
>
> Do you mean the LAYER_NUM type and machinery?
Yes.

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

Layer IDs and predefined purposes are not changeable in Altium. In fact, 
it stores layer sets as 64-bit hex numbers. By layer name I mean what is 
shown on the screen. We would be completely satisfied with the 
possibility to change the general purpose (Eco1, Eco2, Dwgs, Cmts, 
F.Adhes, B.Adhes) and copper layer names.

Also a possibility to display shortened names in the selector widget 
would be nice, it takes a bit too much space.

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

Photoshop 5.0 from 1998 was richer in features than gimp is in 2014. I 
don't think saying that "gimp survived without something for so long" is 
a valid argument here.

Cheers,
Tom