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
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.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *