kicad-developers team mailing list archive

["gharlandau" <gharlandau@...>]

--- Dick Hollenbeck wrote:
>
> Alain Mouette wrote:
> > If you are modifying layers, I would like to add something:
> >
> > Something that is missing in kicad and is very anoying is a
> > keepout layer. I believe that al least 3 should exist: top,
> > bottom and all.
> >
> > I miss this very much. Sometimes I have a metal part touching the
> > board (like a cristal or an RJ45) and Freeroute makes a mess...
> 
> 
> A keepout layer? Why not a keepout zone? If you wanted to keep
> someone out of a particular room in a multi-floor office building,
> you would lock the door, you would not build a new floor.
> 
> 
> Dick

In my assessment, it would be highly desirable for any region (which has been defined by the use of one or more "Keepout" objects) to have the capability to either be specified as:

- a "no-go" region for *just one* layer,
or
- a "no-go" region for *every* layer,
or
- a "no-go" region for (just) *some* layers (i.e. for more than one layer -- but not all of the layers).

And while I am open to suggestions of an alternative nature, it is my belief that the best way of supporting all of those options would be to implement at least one new type of object of a "Keepout" nature -- and for each such type of object to incorporate a "Layer Set" property.

Pads (as already/currently implemented) could be thought of as incorporating such a property (as users can specify which particular layers that each pad resides on), so a similar arrangement could also be used for any newly provided type of "Keepout" object.

Implementing that suggestion would arguably be superior, overall, to alternatively providing any new ("Keepout") layer(s) (as users would always be able to specify exactly which layers would be "off limits" within any specified region), or to otherwise alternatively implementing a (Boolean) "Keepout" property for existing types of objects residing on single layers (as suchobjects would need to be implemented on multiple layers whenever a region needed to be "off limits" on multiple layers).

My suggestion in this regard is based on my experiences with using Altium'sAD (Altium Designer) and (earlier) Protel applications. Those applicationshave long incorporated a Keepout layer, and any objects placed on that layer implement "no go" regions for *all* of the "signal" layers (i.e. copper layers of a "positive" nature). And while that's OK whenever you want a particular region to be "no go" for *all* of the (signal) layers, it's definitely not OK whenever you otherwise want a particular region to be "no go" for just one/some of those layers.

Starting from Protel 99 SE, certain types of objects on *any* layer can have a (true) "Keepout" property assigned to them, and any such object implements a "no go" region for *just* the particular layer that each such object resides on (or at least whenever the layer concerned is one of the "signal"layers). And that's OK whenever you want a particular region to be "no go"for *just one* of the (signal) layers, but it's definitely not so good whenever you otherwise want a particular region to be "no go" for more than just one layer.

Hence my assessment of implementing new types of "Keepout" objects which don't reside on any particular layer, and which incorporate a "Layer Set" (rather than a "Layer") property. (Pads and vias can similarly be thought of as also not residing on any particular layer, and (at least in the case of pads) of incorporating a "Layer Set" property.)


> > Another thing that I miss, is one or two "assembly" layers. this
> > is very usefull. I used it very much in Tango. These layers are
> > just ignored by autoroute and DRC and so can be used for drawing
> > other things...
> >
> > Thanks
> > Alain


I also think that that suggestion has a lot to be said for it. I have long thought that it would be desirable to have a greater number of layers of a "mechanical"/"general use" nature, so providing a pair of "Assembly" layerswould also accomplish that outcome (while the "paired" nature of those layers could be regarded as yet another bonus).

Some types of CAD applications incorporate a "fixed" set of layers, with KiCad being one such example. However there are other types of CAD applications, such as P-CAD and AutoCad, which incorporate "user-defined" sets of layers instead. Increasing the total number of layers supported by KiCad beyond 32 would involve significant changes to the source code, and regardless of whether it subsequently retained a "fixed" set of layers or changed to a "user-defined" set of layers. So I would suggest that which option should be selected in the future is something which should still be given some thought at some stage, as there are pros and cons for each option, and which option is selected would have significant implications for the nature and contents of the source code.


> > Isaac escreveu:
> > 
> > > Greetings,
> > > 
> > > As Dick already said, I have some ideas about the layers user
> > > interface. I will try to explain and would like to know the
> > > other's opinions.
> > > 
> > > 
> > > Pcbnew has a total of 29 layers, 16 copper and 13 non-copper.
> > > 
> > > Today it is possible to configure the number of used copper
> > > layers, and the unused layer names don't appear in the current
> > > layer selection widget, but they do in the layer color and
> > > visibility dialog.
> > > 
> > > The non-copper layers names always appear in every related
> > > widget/dialog, irrespective if they are used or not.
> > >
> > > What I'm sugesting is that we add a bit-mask member to the
> > > class BOARD (suggestion: int m_EnabledLayers) which will
> > > control what layers names will be shown in the dialogs/widgets.
> > > 
> > > Question: Is it possible to add this member to the class BOARD
> > > without breaking file format compatibility?
> > > 
> > > It would be nice if older versions of Pcbnew just ignore this
> > > extra field and new versions just assume all layers enabled if > > > the field is not present.
> > > 
> > > 
> > > Please note that this "Enabled Layers" is different
> > > than "Visible Layers". Today it appears that the concept of
> > > enabled/disabled is indeed visible/invisible. If layers in
> > > Pcbnew were objects that could be created/destroyed, then there
> > > would be no need for such distinction, but as the layers are
> > > always there then we need two different concepts.


Something I did a few years back, to provide enhanced functionality for Protel 99 SE, was to implement my own dialog box for displaying and changing which layers were visible. That dialog box displayed checkboxes for *only* those copper and mechanical layers which were currently enabled (as Protel 99 SE (and succeeding versions) permitted each of those layers to be enabledor disabled as required (for a particular PCB file)) -- and the color of the text string identifying each of those layers also specified the "usage status" of the corresponding layer.

When such a string was black (the default color), that indicated that the associated layer was currently "totally"/"unconditionally" unused.

When such a string was blue, that indicated that the associated layer currently had nothing on it that would appear in any Gerber file or printout created from that layer, but that layer was still "used" in a "concealed" manner, such as when components' Designator and Comment (text) strings on that layer were all currently "hidden", or (in the case of a solder mask or paste mask layer) all of the surface mount pads on the same side of the PCB as the layer concerned were totally "masked" on that layer.

When such a string was fuchsia, that indicated that any Gerber file or printout created from the associated layer would not be "empty", but there werestill no objects within the PCB file that were currently "fully native" tothe layer concerned. Examples were solder mask and/or paste mask layers which were "occupied" as a consequence of pads and/or vias residing on yet other layers.

When such a string was red, that indicated that the associated layer was currently "genuinely used", and that any Gerber file or printout created fromthe associated layer would not be "empty".

Changing the color of those strings, as just described, is not fully compliant with "standard practice" for implementing dialog boxes -- but I still think that there is a lot to be said for the idea of providing users with a clear visual indication of the current "usage" status of each layer. (I recall that whenever I did not have access to that customised functionality, and thus had to resort to using the "standard" dialog boxes for displaying and controlling the visibility of layers, I felt as though I was "flying blind", and even to some extent, of appearing in public naked - because havinga clear display of the usage of each layer provided distinctly more information about the current state of the PCB file than otherwise.)

One possible way of providing information about the current usage of each layer which would fully comply with "standard practice" (for implementing dialog boxes) could be to implement some type of (software) "LED" (Light Emitting Diode) for each layer, with the color displayed by each such LED indicating the current usage status of the associated layer. (Conceptually, I could probably have done that myself when I provided the additional functionality for Protel 99 SE, but doing so would have required yet more development time, and the nature and complexity of the customised dialog box was suchthat significant time was required implementing just the functionality that actually was provided.)

I have raised this matter about providing a visual display of the current usage of each layer because it is my genuine belief that providing that additional information is very very useful. I am well aware that implementing such functionality in KiCad would not be a trivial undertaking, but I still think that providing it would be a very useful enhancement -- and regardless of whether your suggestion of displaying controls for only currently enabled layers is implemented or otherwise. In the event that controls were provided for all of the layers (rather than just those layers which are currently enabled), the usage status displayed for each layer would still provideusers with an indication of which layers are currently totally unused, andI think that providing that information really would help users "keep on top" of which layers they are currently used.

In my assessment, it is not necessarily out of the question that layers could be "disabled" in KiCad (and that controls for only those layers which are currently enabled would be displayed in most of the dialog boxes associated with layers). Speaking personally though, I would still place more valueon displaying the usage of each layer (and remember that some of the dialog boxes *already* display controls for only those copper layers which are currently enabled). (In saying that, I am still well aware that my thoughts on this matter don't necessarily count for anything unless I "roll up my sleeves" and write some code myself, but I am still providing feedback with the intention of being helpful.)


> > > In another post I will explain my ideas for layer setup and
> > > control dialogs, and also the concept of "layer sets" (in my
> > > opinion a great time-saver when designing/routing boards).
> > > 
> > > Best regards,
> > >
> > > Isaac


When it comes to the concept of "layer sets", you're definitely "preaching to the choir" as far as I'm concerned. The dialog box which I referred to before (for use with Protel 99 SE) also incorporated a number of additional pushbuttons for selecting different sets of layers, but a more "general" feature (of such a nature) would permit users to define and name their own layer sets, then subsequently "recall" them, and if desired, also edit the name and contents of each (already-defined) layer set. And even though such functionality could be regarded as being of a "non-core" nature, I still think that having it provided would be very beneficial from a practical point of view...

Regards,
Geoff.