Not the shortest of posts; read if interested, otherwise save for a rainy
day or discard.

> Suggestion: I have had use for a Negative Object. That is one that when
> placed on a PCB or within a footprint causes the opposite effect for that
> layer. A negative object on a normal layer would take away a chunk of
> copper and on a negative layer would add back a chunk of whatever (mask,
> plane, paste mask). I would be nice if this was a attribute of an entity
> and so any entity could be a negative object.  I know this may be
> non-trivial to implement and I know it may make DRC very much harder but
> in the past Protel have quite a reasonable record of taking our
> suggestions and filtering them into something workable for them and
> useable for us.  One use for this object would be to prevent isolation of
> small plane sections by a ring of nearby plane blowouts intersecting.
> Any one else got a use for something like this?
> (Some of you may be wondering why I am adding the suggestion stuff to the
> subject.  Rob Malos is compiling a list of desired improvements.  In order
> to make his life easy I am marking the subject accordingly and making the
> suggestion(s) clear.)
> Ian Wilson

In your above example, one way of dealing with this (without the need for
negative objects) is to "fine-tune" the parameters for the thermal relief
patterns for the pads concerned, i.e. the distance between a pad's hole and
the inside edge of its thermal relief arcs, the thickness of its thermal
relief arcs, and the thickness of the gaps separating these adjacent arcs.
(Each of those distances has an associated name assigned to it, but I can't
recall the designations concerned off-hand.)

If manufacturing and/or other requirements prevent you from selecting
parameters which would totally eliminate the associated problems, another
possibility is to set a Design Rule which sets pads (as required) to be
*direct* connected to the Power Plane layers. You then add your own thermal
relief patterns to each Power Plane layer as required; typically, you would
place an assortment of arc primitives, each of which would have its
properties set to appropriate values in order to create, in composite,
thermal relief patterns of a satisfactory nature.

I would fully concur that there is, to some extent, a "Mickey Mouse" aspect
to what I have just advocated. But I speak with some experience in this
matter. In a previous job, I had created a "multiple device" footprint to
permit a radial electrolytic capacitor to be fitted, regardless of whether
the pitch of its pins was 0.2", 0.3", or 0.4". As such, pins 1 and 1A were
separated by just 0.1", as were pins 2 and 2B. When I used this footprint in
a PCB which used Power Plane layers, the thermal relief patterns were less
than satisfactory (because the close proximity of these pins resulted in
"interference" between their relief patterns). So I set all of those pads to
be direct connected to the Power Plane layers, and then placed arcs on the
Power Plane layers in order to end up with thermal relief patterns of a
nature that were satisfactory.

But how can what I have just described be improved upon? Providing a greater
capability in specifying details of thermal relief patterns (e.g. support
for a different number of arcs other than two or four, being able to fine
tune the start and end angles of each arc used, etc)? Being able to append
"roll-your-own" thermal relief patterns to the associated pin (or associated
pin's associated component)? To some extent, this does spill over to the
issue of enhancing the padstacks feature - no small can of worms in itself.

And as another potential feature, I haven't used Autocad for a while now,
but my recollection of one aspect of this is that a collection of items can
be encapsulated into one "parent" object (and that this can be reversed by
"exploding" such objects), and that such "parent" objects in turn can be
encapsulated into yet another "parent" object, and so on, ad infinitum...
Although Autocad was primarily designed for civil/mechanical/general
engineering purposes, I have often thought that this ability to create
"parent" objects (I can't recall the exact Autocad terminology for what I am
describing) would often be useful in Protel. In the circumstances in
discussion, being able to "merge" these arcs with their associated pads (or
the associated component?) could be useful, especially if the possibilty
existed that you might want to move the pad/component again at some later

Protel 99 SE currently partially supports this concept, in that users can
declare unions of components, and primitive objects can be added to or
purged from components. Polygons, co-ordinates, dimensions, and components
are of course all examples of "composite" objects; what I am thinking of is
taking this concept still further, in the form of also supporting a "user
(defined) composite" type of object. That would be useful for items such as
company logos; I currently implement this using a component, and then
conceal the associated Designator and Comment strings. This gets the job
done, but the logo is not a component in the sense that other components
are, as it is intrinsic to the PCB, rather than being a location and
footprint to which a component is then added (during the PCB assembly
stage). (So the presense of any logo components in BOM and Pick'n'Place
files is unwanted, and such components need to be manually purged from such

Would there be a case for also supporting one or more "user objects" being
incorporated into yet another "user object" (, and so on)?

But to discuss further the concept of negative objects. I think that it is
an interesting idea. Off-hand, I can't think of any other situations where
negative objects would be genuinely useful; that said, I certainly would not
dismiss the possibility that such situations could well exist, and that I
might even think of some if I spent some time doing so.

But the provision of such a feature would indisputably complicate the
software, and as such, a case could be made for debating whether the
benefits gained from acquiring this feature could justify the additional
effort that Protel would have to put in to implement it.

It could be argued that it is presently possible to create a Gerber file
from any layer that contains whatever you want this to contain, and as such,
there is no absolute need for negative objects.

While it is not something I am an expert on, my understanding is that some
programming languages and/or microprocessor instruction sets
provide/implement an "orthogonal" set of instructions, which apparently
means that there is only one way of performing at least some tasks. (In the
purest form of all, would this mean implementing a Turing machine, even if
this was one of a very high speed nature? :) )

To a large extent, Protel's software is *not* "orthogonal" in this sense.
Many of us can think of examples of questions asked on this forum which have
received answers of a varied nature, e.g. how to find all pads with a hole
diameter smaller than a given value. While there might be some benefits to
be derived from "orthogonal" software, software which is not orthogonal (or
which only partially complies with the principles of this) can also be
easier to use and more "user-friendly" in nature; when there is more than
one way to "do something", there will often be times when one of the
available methods is more appropriate (for whatever reason or reasons) to

As such, if there are compelling reasons for supporting negative objects,
then the fact that they might not be absolutely required should not be
grounds for not providing such a feature (even if implementing it would not
be straight forward); if their provision would make Protel more
user-friendly/significantly enhance its capabilites/etc, then it is
something that users should go in to bat for.

But while providing enhanced capabilities is not, in itself, a bad thing,
the larger picture suggests that enhancements can be difficult to implement
and/or can conflict (even if in part) with the "Protel way". Negative
objects would not necessarily be problematic in this regard, but for all
that, they potentially could be. So even though I am not opposed to Protel
being enhanced, we should be wary about strongly advocating enhancements
which Protel might have difficulty implementing, and which users could be
unhappy with, either due to a less-than-flawless implementation, and/or the
enhancement being in conflict with the "Protel way".

As one example, I am thinking of how to set Solder Mask and Paste Mask
expansion values. In AdvPcb 2.8, users set these on a pad-by-pad basis
(though the global editing feature made it easier to set (and/or check)
these properties on a multiple-pad basis). With Protel 3, 98, and 99
(original version), these values were set by Design Rules. With Protel 99
SE, it is now possible to set these values either by a pad-by-pad basis
(like in AdvPcb 2.8) *or* by the use of Design Rules (like in intermediate

Personally, I think this is a commendable enhancement, and I was actually
one of those who requested this. That said, there are times when I wonder if
the current implementation is as good as it could be. I can't help thinking
that if a user changes one (or both) of these values from a "Pad" dialog
box, then perhaps that change should also result in the creation (or
modification) of a Design Rule which (co-)records/logs/documents the user
changing that setting in this manner. When a user places a Room (object) in
a PCB file, that results in a corresponding Design Rule being created; I
envisage something similar for Solder Mask and Paste Mask expansion
settings. In other words, there would be two-way synchronisation between
Design Rules and settings changed on a pad-by-pad basis.

By all means object if you think that what I am saying there is a load of
c***. But the point I am trying to make is that Protel's efforts to
accommodate users' requests can sometimes result in them having to cope with
conflicting aspects and/or concepts.

Enough for the time being. There is a fair bit of material here for anyone
who wants to run with it...

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 join or leave this list visit:
*                      - or email -
* mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum
* Contact the list manager:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to