At 10:10 AM 9/20/01 +1000, Saddle wrote:
>The problem I seem to have alot is knowing where the edges
>(boundaries) of an existing polygon are when laying down the next one beside
>it. This may sound strange, say just lay one over the other, but sometimes
>protel wants to redraw/recreate the polygons and it may not draw them in the
>correct order again.

Right, as will be expected if one considers how the polygon pour works. For 
this reason, one should not overlap polygon pours belonging to different 
nets; the resulting copper is likely to vary depending on the sequence in 
which the polygons are poured.

If one must place a polygon pour within the territory of another polygon 
pour, reroute the outside edge of the larger polgyon so that it wraps 
around the inner polygon area. (I.e., do not allow a donut but instead make 
a C shape with the C closed so that when it is poured without obstructions 
it will look like a donut.)

A polygon with sufficiently fine pour track will normally have an outline 
which is reasonably visible. However, if one wants to see the actual 
outline, one can position the cursor over the polygon and press the left 
mouse button, which will display the outline. Unless one is on a coarse 
grid and can tell that one has not moved the polygon -- which will be 
floating on the cursor at this point -- it would be best to use ESC to 
terminate the move before letting go of the left-mouse button, so that the 
polygon will remain in its original place.

Drawing a reference outline on a mechanical layer is not a bad idea, but 
some care in placing polygons in the first place may avoid the necessity. 
If one has many differing polygons within one large polygon, using a mech 
layer as a reference to leave documentation in the file as to the desired 
pour sequence seems a good idea to me. Obviously, one would want to pour 
the inner polygons first.

Protel could have the intelligence to recognise that one polygon contained 
within another should be poured first, but it doesn't. With overlapping 
polygons, however, there is no easy way for the program to tell which one 
should be poured first, so the existing behavior is probably the best 
compromise, i.e., the designer can control it. Perhaps a more advanced 
program will have some device for directly controlling pour priority, but 
do we want the increased program complexity?

Inner planes, however, have no way to control "pour" sequence (i.e, to what 
polygon an overlapping region is to be assigned), and here we could really 
use an improvement.

Included polygons should clearly take priority; where polygons overlap, 
they should either automatically split when created, with the user being 
queried as to how to assign the overlap. (In other words, if a polygon is 
placed overlapping another -- on the same layer, of course --, then the two 
polygons will become three, two of which will have clear assignments and 
one of which is ambiguous, hence the query.)

Abdulrahman Lomax
Easthampton, Massachusetts USA

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to