kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/04/2014 06:30 PM, Cirilo Bernardo wrote:
> ----- 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.


I think we should stick with Wayne's lead.

Wayne said design the files first, talk about coding later.

Please stick with his lead.