On 10:25 PM 8/11/2001 -0500, Abd ul-Rahman Lomax said: ><..snip..> >>Abd ul-Rahman Lomax has also recently mentioned that "blind" and "buried" >>vias are sometimes inappropriately displayed. > >Actually, they are *always* inappropriately displayed. Either you have >multilayer turned off, in which case no vias are displayed at all, or you >have it turned on, in which case vias are displayed unconditionally, >whether or not they exist on the enabled layers. This is really a major >shortcoming at the point, actually one of the worst of which I know. > >> I concur that this could be >>regarded as a bug, but apart from that, I personally don't regard the >>MultiLayer layer as being "bad" in nature. It is a "special" layer, like the >>Drill Draw, Drill Guide and Keep Out layers, but PCB applications differ >>from general purpose CAD applications (such as Autocad) in that there is a >>good case for "special" layers to be provided. > >I have not heard, yet, any good argument for the maintenance of this layer >as a "layer." It is a "concept" more than it is a layer. A button that, in >Display setup, turns on all copper layers would be useful. But a via is a >via, it does not need a special layer!
This email is a little long - don't bother reading it if you are not interested in discussing future features. Here is a tip vaguely realted to some of the discussion below: Tip: On a PCB that does not use any mid signal layers, you can display the padstack of a multilayer pad correctly if you make the MID layer size 0,0. No on to the discussion: I have no problem with the "special" layers that Geoff discusses. We are not using a generic CAD package. But, I think the multi-layer layer as currently implemented is no longer a useful concept, apart from that dreaded curse, backwards compatibility. As I see it there is one basic issue, that is, ** entities on multi-layer do not also belong on the signal layers **. Even though they do in reality. This breaks a number of useful constructs in the design rule system and has left a legacy of display artefacts. For example, if multi-layer pads and vias *also* existed on the bottom layer then we could apply different solder mask expansion top and bottom in a sensible fashion. Both major issues could be fixed by special case programming, but I think there may be a better method... I have a concept for layer groupings that could integrate nicely with the desired layer pairings that we have discussed and been after for some time. If we were able to create named layer groups, consisting of one or more of the "base" layers, we could easily have facilities like: 1) Enabling/disabling of groups of layers in single "layer" mode. So single layer mode may cause more than one "base" layer to be displayed if the current layer was actually a layer group. This would integrate directly into the existing behavior of the '+' & '-' keys, no change required. A corollary would be that an item on a named layer would show just that particular layer, and no other, correctly in single layer mode. 2) Design rules could be scoped by named layer groups 3) The entities in the named layer still exist on all the relevant base layers and so the base layer-scoped design rules apply to them in the usual manner. This is what I want mostly. 4) It should make a ready fix for many of the display artefacts and problems we have observed with blind and buried vias, and at other times. Multi-layer would simply be a (pre) defined collection of all signal layers. As a new layer is added by the stack manager signal layers are added to the pre-defined multi-layer group automatically. *see note 5) It ought to be able to integrate into our desires for better padstacks. 6) Shouldn't cause any issue with flexible layer pairings feature that a number of us have been asking for (where the user can set up the layer pairing used when a component is flipped from the bottom to the top of the board and visa-versa. 7) In a fashion it can be used to create multi-coloured mech layers. I can see some issues, mainly what to do when a library component is carrying a named group layer and there is already a named goup layer with different base layer members in the PCB. Warn the user? Create a new unique name? Offer to merge the two layer groups into the union of the sets? This situation may arise if we get elaborate padstacks as a number of us have been requesting, and the component pads were placed on a named group layer. An alternative solution would be to prevent library components from carrying named group layers, and implement padstacks using the database entity association techniques already used for things like polygons and, in fact, PCB components themselves (so a component becomes a hierarchy of associated entities rather than the current one-layer of association. In this manner complex pads could be built up from surface pads on a number of layers, along with a new object, a hole, and associated as the same pad.) A base layer could exist in more than one layer group of course. Objects can be placed on a named group layer and would then exist on all of the included base layers. *Note: Other multi-layer display artefacts that I know are, a multi-layer pad which uses the Padstack option, so it has different top, bottom and/or mid layers sizes displays, will display top layer features even when only the bottom layer should be visible - since the mutlilayer objects are *fully* displayed whenever a copper layer is active (in single layer mode). Also, a multi-layer pad, with the padstack feature enabled displays a shape and size, as given by the MID layer size, in the multi-layer colour - even if no mid-layer is included in the layer stackup. And there are a number of other display anomalies. These would be fixed if multi-layer was not a real layer - that is, it had no colour but was just a logical collection of other layers - which it really is conceptually. But I am not being paid to design or implement the solution, so in this case I can toss around the words and let others think of the difficulties. I am sure that AL and GH will comment (hopefully), but it would be nice to get some other viewpoints on this, and other, forward looking feature planning stuff. Altium has been known to look at these discussions and implement what they see as the consensus. For an example look at the changes in P99SE, compare those to the discussions and polls around at the time. If we don't let them know what we want then they will add features they think we want - not always one and the same. So lets thrash some of these ideas around. You may say that the above is a crock of ..., totally stupid. That's fine by me, as long as you make some attempt to justify. Ian Wilson * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
