Please see below,


----- Original Message -----
From: "Abd ul-Rahman Lomax" <[EMAIL PROTECTED]>
To: "Protel EDA Forum" <[EMAIL PROTECTED]>
Sent: Monday, January 20, 2003 3:13 PM
Subject: Re: [PEDA] Polygon Filled Planes

> At 03:31 PM 1/20/2003, JaMi Smith wrote:
> >Respecting your having one larger Polygon Plane over several smaller
ones, I
> >am assuming that you are speaking of the case where the smaller ones are
> >a different net.
> >
> >If this is the case, you would then be relying on Protel to not flood
> >the smaller Polygon Planes simply be virtue of the net being different.
> >While this may in fact work, I myself would not rely on it, and would not
> >trust Protel to handle it properly in all cases, and would try to work
> >around the problem in a different manner.
> The method is reliable. Remember, if Protel were to pour incorrectly, it
> would create error reports. Polygon pours are checked as if they were what
> they are: a pile of individual lines.

I am not quite sure that I want to buy into the "reliability" just yet.

Protel has been known to do some pretty strange things at some pretty
strange times, and for me, "reliability" must be demonstrated.

And speaking of Protel "reliability", I am not quite sure what exactly Bob
ment in his earlier post respecting "an exception error about a .dll with
respect to pcb" which he thought was related to the Polygon Plane, and which
apparently no one has really addressed, and just where that plugs into the
who issue of Polygon Planes and "reliability".

I use large Polygons as fills on signal layers on most of the high speed
things that I do (usually connected to ground or a supply), and aside from
them bringing Protel to its knees "speed-wise", "reliability-wise" they seem
to be responsible for a large number of the crashes that I have had with
Protel, and hence I am very careful with them, and take my time placing

I find that if I take my time here, that I do not have to come back and
change them or redo them.

> >What I have been successful in doing in the past, and more importantly
> >I feel comfortable and confident about doing, is simply this:
> [...]
> >While it takes a little more work to do it this way, I never have to rely
> >Protel to understand what I really want it to do, and there is no chance
> >error.
> The method which Mr. Smith describes seems to me to be a *lot* more work.
> The previously given method I will repeat:
> (1) place the inner pours and fill them.
> (2) place the outer pour and fill it.

Yes they do take more time this way, but we are only talking a few minutes
more for each large Polygon, and if you can't spend a few extra minutes on
doing something carefully, then you must not put too much care into your

One of the benefits that I forgot to mention about doing it this way, is
that you have complete control over your "gaps" in between Polygon Plane
segments, which allows you do handle different areas differently if you so

> >This method also prevents minor catastrophes which might happen if I
> >accidently deleted or renamed an inner Polygon Plane segment and then
> >"repoured" an outer Polygon Plane Segment.
> The "catastrophe" is truly minor. If one is truly concerned about a pour
> being accidentally changed (remember, DRC will still detect shorts and
> opens), one can simply reduce the pour to primitives.

And fixing it can take more time than it would have taken to do it the other
way to begin with.

So how much time did you really save or lose?

Isn't the time issue really minor here anyway?

What if that catastrophe happens to the next guy who works on the board, and
he doesn't understand it?

> >In short,  you can draw larger Polygon Planes in smaller overlapping
> >segments, providing that they have the same net, and it is actually
> >preferable to have some overlap to prevent a "gap" in the gerbers, but it
> >not advisable to overlap Polygon Planes which are not intended to be the
> >same net.
> Well, it doesn't hurt for there to be an overlap, certainly, but if one is
> designing on-grid using consistent units such that round-off doesn't bite
> you, it isn't necessary. (i.e., if one uses, say, a 1 mil grid for
> primitive placements and uses imperial units for gerber generation and the
> line widths are in mils, no overlap is necessary, the films will fill
> completely with zero gap; in fact, we recommend setting grid to "0" for
> polygon pours, which informs the pour routines to place track at zero
> clearance.

Is this the "Lomax Virtual Short" now applied to Polygons?

I overlap simply because I have had Protel "bite me" on this one in the
past, and have actually had a very narrow little gap of about 0.010 and
about 0.200" long, show up between two adjoining segments in a small
finished board, which fortunately was not related to functionality, although
it looked like s***. I tried to find a reason for it in the Protel database
and in the gerbers, all of which said it shouldn't have happened, but rather
I should have had the two segments abutting each other with no gap, just as
you have described and explained above. If I still had the database
available, I would go back and look at again just to prove the point, but it
is not available.

All other things considered, when the board shop examines the gerbers in a
gerber editor, this is just the kind of thing that makes them ask questions
(if you are lucky), or the type of thing that they might change by
themselves since they think they know how to fix it the way you want it.

Respecting "designing on-grid using consistent units such that round-off
doesn't bite you, . . .  (i.e., if one uses, say, a 1 mil grid for primitive
placements . . .  ", isn't this really cutting things a little close and
taking unnecessary risks, and by the way, doesn't working with such a small
grid actually take you much more time and wouldn't it be, as you say, " a
*lot* more work ".

Actually, it is very quick and easy to overlap, and really very cheap

> Mr. Smith's method works, to be sure; and if it is simple to break up the
> outer pour, it could also be practical, but there is no more danger in
> using pour sequence to control nested pours, mistakes will stand out like
> sore thumb. One caveat: if you move the planes involved, the automatic
> repour may not produce the desired results. But this is very likely to
> result in open circuits. If one will need to move a selection including
> nested pours, it might be a good idea to reduce the inner pours to free
> primitives first. Note that free primitives do *not* increase the database
> size since they are already there as part of the pours.

One final question here, is whether the next guy who works on the design is
going to know about or understand "using pour sequence to control nested
pours", or is the whole thing going to blow up in his face when he tries to
do a mod right in the middle of the whole thing.

Database integrity, standardization, and simplicity is very important to me.
By that, I mean that when I do a design, I do not want have all kinds of
non-standard rules, procedures, set-ups, or other kinds of "time bombs" in
it, or "virtual" tricks or gimmicks that the next guy will not understand or
be able to work with.

Among other things, my credibility and reputation are on the line when I do
a design, and then later move on to another project or company, and have
some new designer come in behind me and try to work on my old design only to
have him not understand the tricks I had to play, and screw up the design
and then blame me as a consequence. This is one of the reasons I get so
upset when Protel won't let me do something right that it should, and I have
to get out my trusty old "Mickey Mouse Ears", put them on, and "kludge"

Yes, I will go the extra mile, just to keep the design simple, and to insure
that the next guy who has to work on it, whether it be the board shop,
another designer, my boss, or whoever, won't ever have to ask "what was he
trying to do here", or "why did he do that", or "what's wrong with this", or
worse yet, make a change or mod, and not catch an error that occurred until
after a large production run of boards, simply because of some "rule" being
changed from standard, or turned off, or getting bit by "that round-off", as
you put it.

> "One caveat:" you say?

Actually, no caveats please.

Many ways to do the job, thanks for your input,


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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