kicad-developers team mailing list archive

["Isaac" <isaacbavaresco@...>]

This post grew unusually long, so I will top post to ease the reading.

1) I'm not much concerned by now with keep-outs, but I would say that a keep-out object placed in each layer where it is needed is better than a keep-out layer.

2) More layers: There are already two general purpose layers (eco1 and eco2), perhaps they could be used as assembly layers. Also, presently there is room for three more layers, without needing extensive changes to the program.

3) The original subject of my post: Layer enabling/disabling and visibility

It appears that Geoff agrees with me but he is more interested in a way to show if a layer is "empty" or not. Interesting idea, perhaps somebody coulddevelop it.


4) Layer sets: This concept I borrowed from P-CAD, they are logical groups of layers that can be "recalled" by keyboard shortcuts.

When recalling a layer set, all the layers in the set become visible, and all layers not in the set are hidden. One of the layers in the set (defined when creating the set) is defined as current.


I personally like to see only the layers I'm working on plus any layer thatmay interfere with it, all other layers are just distraction. The present mechanism for showing/hiding layers is not very efficient.

The layer sets make easy to change from one view to another (just one keypress for instance).


Best regards,

Isaac


--- In kicad-devel@xxxxxxxxxxxxxxx, "gharlandau" <gharlandau@...> wrote:
>
> --- 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 eachpad resides on), so a similar arrangement could also be used for any newlyprovided 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 such objects 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's AD (Altium Designer) and (earlier) Protel applications. Those applications have 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 ofas also not residing on any particular layer, and (at least in the case ofpads) 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" layers would 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 regardlessof 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 shouldbe 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 changingwhich layers were visible. That dialog box displayed checkboxes for *only*those copper and mechanical layers which were currently enabled (as Protel99 SE (and succeeding versions) permitted each of those layers to be enabled or disabled as required (for a particular PCB file)) -- and the color ofthe text string identifying each of those layers also specified the "usagestatus" of the corresponding layer.
> 
> When such a string was black (the default color), that indicated that theassociated 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 were still no objects within the PCB file that were currently "fully native" to the 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 from the 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 stillthink 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 displayingand controlling the visibility of layers, I felt as though I was "flying blind", and even to some extent, of appearing in public naked - because having a 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 eachlayer 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 such that significant time was required implementing just the functionality that actually was provided.)
> 
> I have raised this matter about providing a visual display of the currentusage of each layer because it is my genuine belief that providing that additional information is very very useful. I am well aware that implementingsuch 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 provide users with an indication of which layers are currently totally unused, and I think that providing that information really would help users "keep ontop" 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 value on displaying the usage of each layer (and remember that some of the dialog boxes *already* display controls for only those copper layers which arecurrently 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 withthe 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 tobefore (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 suchfunctionality 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.
>