kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

----- Original Message -----

> From: Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
> To: kicad-developers@xxxxxxxxxxxxxxxxxxx
> Cc: 
> Sent: Thursday, June 5, 2014 5:35 AM
> Subject: Re: [Kicad-developers] CERN work package 4 (Extend number of layers)
> 
[snip]
> 
> 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:
> 
>   (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)
>   )
> 
> From the discussion, it sounds like we would need to add an F.KeepOut
> and B.KeepOut for courtyard areas.  Maybe add F.KeepOutZ and B.KeepOutZ
> for vertical keep out areas to prevent pick & place machine plunger
> crashes on tall components.  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.
> 


I think a good start would be to ask people what technical layers they
want and go from there. Offhand I'd vote for the F/B.KeepoutZ since
that's actually useful when working with MCAD people to replace existing
boards or when the board design is constrained by other mechanical
factors. In IDF (it has many deficiencies, but it's the only ECAD/MCAD
collaboration tool we have at the moment) a Keepout can have a height of
'0' which means you can't place any components at all. *If* we have these
keepouts, we also need to provide height information for components.
Fortunately that facility already exists with the introduction of the
IDF code.

I can think of a number of reasons people want extra layers:
1. to support the scheme detailed in IPC-7351
2. to support design constraints stated by a manufacturer for a
   specific product (usually routing keepouts)
3. to support ECAD/MCAD collaboration

In the case of ECAD/MCAD support, and this is probably true of additional
technical layers in general, a lot of the layers only need to display
various outlines to guide the person doing the board layout; KiCad cannot
be expected to enforce any rules.

Anyway, the short story: we should detail what layers people want and why,
and how those layers are intended to be used. Then we can think of how
things can be implemented in small steps.
Initially these layers can be implemented and maybe all can be implemented
by accepting nothing more than graphical lines and text. Even layers which
should ultimately have some effect on KiCad's behavior can initially be
implemented and display something even though they are non-functional until
someone has time to put in the additional code.

One other thing: any further progress hinges on extending KiCad's layers.
I think it's good to have some idea how we want to progress with the new
nonexistent layers, but we also have to keep in mind that nothing further
can be done until someone has the time to come up with a good scheme for
extending the number of layers.

- Cirilo