On 06/04/2014 06:30 PM, Cirilo Bernardo wrote: > ----- Original Message ----- > >> From: Wayne Stambaugh <[email protected]> >> To: [email protected] >> 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. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
