kicad-developers team mailing list archive

[Jean-Paul Louis <louijp@xxxxxxxxx>]

All,

I do not see a Board Outline Layer (or Mechanical Layer) in any of the discussions.
Where are defined the boundaries of the PCB?
With other CAD tools, I have used a mechanical layer that was storing the Board Outline, and Any cut-outs and any non plated holes used for securing the board.
That layer was easily imported from either a dwg or dxf drawing called the Board Blank.

Jean-Paul
AC9GH


On Jun 4, 2014, at 3:35 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:

> On 6/4/2014 2:33 PM, Lorenzo Marcantonio wrote:
>> On Wed, Jun 04, 2014 at 02:20:12PM -0400, Wayne Stambaugh wrote:
>>> user confusion.  Where would you save them in the old kicad_pcb file
>>> format after you made changes?  If Pcbnew where a read only application,
>>> then this would be less of an issue.
>> 
>> That's why I questioned if it would be desiderable...
>> 
>> The only thing I think would be possible to keep *backward*
>> compatibility is using optional forms, so if you don't use that feature
>> the file remain compatible (no strange layers and the file still loads).
>> I changed the quotation rules for the sexp in a backward compatible way
>> and now they are both LISP and kicad compatible.
> 
> Backwards compatibility is not optional.  We should always be able read
> older board and footprint file formats.  That was one of the things that
> drove the design of the current layer parsing of legacy boards and the
> design of the new layer sexpr format.
> 
>> 
>> PDF works in this way (unknown features are simply ignored), but it's
>> designed to be an 'append only' format. And obviously javascript doesn't
>> work in xpdf. However a PDF editor changing the rest of the file would
>> probably break the javascript stuff (at most it could preserve the script
>> object, but all the anchors could be broken...)
>> 
> 
> 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.
> 
> Wayne
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp