At 10:13 AM 1/19/2002 -0800, Brian Sherer wrote:

>It seems that Polygons are handled as a multiplicity of primitives, while
>Split Planes are handled as
>single entities. Database size seems to grow exponentially if Polygon
>Pours are used.

This is not just an appearance? Pours, by definition, consist of a pile of 
tracks and arcs filling an area. The size of the pour depends on the pour 
parameters, but, inherently, a pour involves many more primitives than a 
negative plane. This is the reason I have recommended so many times that 
Protel move away from pours and toward positive/negative merges for filling 

The only reason for using pours is that the copper is explicit, making 
checking possible without any additional special programming. But this 
leaves negative planes without explicit checking, which is an undesireable 
situation by itself. In other words, the negative plane checking problem 
should be solved, and if it is solved, it then becomes practical to use 
negative merges to accomplish what pours now accomplish, with the benefits 
of reduction of database size, elimination of pour anomalies -- which can 
be quite a nuisance --, and, to boot, substantial reduction of plot sizes.

But I want to emphasize that this problem is not a special Protel problem. 
Most CAD systems don't check negative planes, it is not a trivial problem. 
But it is soluble, and I presume that Protel's programmers know how to 
solve it, since they haven't asked me! :-)

>2) For a design that has been heavily edited, there may be Polygons or Split
>Planes that exist in the database but are not displayed, or that duplicate
>existing objects.

Some methods were given for locating and eliminating such objects. A 
generic technique for dealing with suspected persistent database corruption 
is to chop the file into pieces and find out if the problem exists in all 
the pieces. The spreadsheet might be useful for keeping pieces distinct.... 
This technique can be useful when all else fails....

The current Protel router, while quite serviceable for many applications, 
is not considered state-of-the-art. It will be *very* interesting to see 
what we get in the next few months!

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