> no no, i was not at all suggesting that support for split planes be
> removed
> only that their contribution to the overall goal of quiet boards
> efficiently designed should not be over estimated or utilized as a cure
> all when they in fact may be a significant source of loop area antenna
> effects
>
> Geoff, I (and I think we all) appreciate your careful and thoughtful
> comments on these matters which can be difficult to explain as
> explicitly as you do, thanks
>
> Dennis Saputelli
I didn't really think that you were advocating that Protel withdraw support
for the split plane feature on Power Plane layers, but I wanted to minimise
the probability (however small) that Protel might interpret your previous
posting as being a reason for not sustaining support for this.
If/as time permits, I hope to write more about Power Plane layers and
polygons on signal layers. But in a nutshell, I think that would be highly
desirable to enhance the existing Design Rule implementation so that users
would have the ability to control how each pad (and vias) connects to *each*
Power Plane layer (Direct Connection, Thermal Relief Connection (assuming
that the net assigned to the pad matches the net of the Power Plane layer in
the same location), or No Connection), and similarly, how each pad (and
vias) connects to polygons on *each* signal layer (same options again).
It is currently possible to control what *clearance* is required between
each pad (and vias) and polygons on *each* signal layer, and it would not be
devoid of merit to similarly also be able to control what clearance is
required between (the hole of) each pad (and vias) and *each* Power Plane
layer.
I make these suggestions because it is frequently desirable to be able to
control how/where current flows, with RF/other high frequency circuits being
one such example, and other examples being switched mode PSUs and even
linear mode PSUs. If a pad (or via) is within the regions occupied by
polygons on more than one signal layer and/or is in regions assigned to the
same net (as that assigned to the pad (or via)) on more than one Power Plane
layer, then it is often desirable to be able to specify that the pad (or
via) connects to polygons on particular layers but not others, and/or that
it connects to particular Power Plane layers but not others.
In the case of Power Plane layers, this would represent an enhanced form of
the "Padstacks" feature for pads (and vias), but in a form that is
implemented by Design Rules. (There is also some case for similarly
enhancing the Design Rules so that users can stipulate *separate* Soldermask
expansion values for MultiLayer pads and (through-hole) vias for *each* side
of the PCB.)
Vias have long had the property of always being on the MultiLayer layer,
together with "LowLayer" and "HighLayer" properties that stipulate "how
many"/which copper layers each of these occupy. In some situations, I could
see merit in *either*:
- being able to assign a name/designator to Via objects, to provide an
identity to vias (on an as-needed basis), *or* (as an alternative to being
able to do that)
- being able to assign "LowLayer" and "HighLayer" properties to (MultiLayer)
*Pad* objects (in situations where it is desirable for a pad to occupy more
than one copper layer, but not *all* copper layers).
My gut-feeling is that Pad objects are already complicated enough, and as
such, adding a name/designator variable to Via objects instead would involve
less hassle. For those who ask why this could possibly be useful, Design
Rules currently apply to *all* vias, but if each via could have a name
assigned to it, then it would then be possible for Design Rules to apply to
Vias on a *selective* basis, with the qualifying criterion being of course
the name assigned to each via.
Design Rules, Pad objects, (Via objects, ) and the "Padstacks" feature are
collectively a big can of worms. Although I was one of those who previously
suggested that Solder Mask expansion values and Paste Mask expansion values
should be settable from the "Pad" dialog box, I am not convinced that the
(consequent) current implementation is as good as this could be. My vision
was that such properties would be defined within Pcb *Library* files, and
would be used for pads such as fiducials or gold-plated "edge" contacts
(examples where the pads should be masked on the Paste Mask layer). However,
it is possible to "loose" settings originally defined within Pcb Library
files, which I regard as a shortcoming, even if this shortcoming is more
theoretical/potential than practical/common in nature. (If the CheckBox for
a customised setting is unchecked, the expansion value that is depicted is
determined by the current Design Rules if/when the dialog box is re-invoked,
but at that time, the previous customised value is *not* restored if this
Checkbox is then checked again.)
To *some* extent, I am now wondering whether a better implementation would
have been to have continued to use Design Rules *exclusively* to set such
properties, but with a "Pad" (/ "Via") dialog box provided with which the
user could *view* (but not *change*) these (and Power Plane layer)
properties; to facilitate customised settings (for the Pad/Via currently
being examined), the "Pad" (/ "Via") dialog box could incorporate
PushButtons, each of which would invoke a "Design Rule" dialog box of an
appropriate type. That way, users could define a Design Rule of an
appropriate nature (either exclusively for that pad, or for a Pad Class, or
for some other type of set of pads, or all/some vias), and then view the
results of their handiwork in the "Pad" (/ "Via") dialog box, whose contents
would be updated as required following the closure of the previously invoked
"Design Rule" dialog box.
Such an implementation would have catered for those accustomed to the
"AdvPcb 2.8 way" of setting such properties (Soldermask Expansion, Paste
Mask Expansion, Power Plane properties including PowerPlane (/Clearance)
Expansion, PowerPlane Connection Style, etc), in that these properties would
be *displayed* in the pad's (or via's) dialog box, and while these could not
be changed *directly* from this dialog box, they still could be changed,
indirectly, via "Design Rule" dialog boxes. At the same time, such
properties would have continued to have been set *solely* through Design
Rules, but with the difference that Design Rule dialog boxes could now
*also* be invoked directly from "Pad" and "Via" dialog boxes.
The possibility can not be discounted that there would be legacy issues in
changing to such a method (or at least for SolderMask and PasteMask
properties, if not for PowerPlane properties) in a new major version, and
this method does not, as just described, cater for users who might want to
set such properties within Pcb Library files. So I will continue to give
this matter some thought... And if anyone else wants to contribute to this
thread, then please do so. (If I can find the time, I will try and add more
flesh to my suggestions, and/or answer queries that anyone may have as a
consequence of reading my postings.)
Regards,
Geoff Harland.
-----------------------------
E-Mail Disclaimer
The Information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
e-mail by anyone else is unauthorised. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. Any opinions or advice contained in this e-mail are
confidential and not for public display.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/subscrib.html
* - or email -
* mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Browse or Search previous postings:
* http://www.mail-archive.com/[email protected]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
