On 10:25 PM 8/11/2001 -0500, Abd ul-Rahman Lomax said:
>>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:
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to