Re: [PEDA] Autorouter Stability Problems
On 10:13 AM 19/01/2002 -0800, Brian Sherer said: 1) Protel doesn't flag buffer overruns at all, in any server. It can occur when for instance multiple Polygon Pours are used instead of Split Planes on a multilayer design. 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. In a failure to initialize or crash situation, this is often related to item 2. Brian, Can you explain more about this please? I have never heard of buffer overruns used in this context. Yes, as others have said, large polygons do cause the PCB file size to increase. But in my experience this has been a linear increase reflecting the number of tracks in the polygon. In the past there has been discussion on methods of reducing the sizes of polygons. Again, I have not come across the concept of buffer overruns in the context of a file format such as Protels. The Access database format (DDB) is only used to store proprietary BLOB data, and from memory the capacity of Access (for blobs) is 2 GB. Since 32-bit handles are used throughout the servers (as far as I can see from the SDK anyway) this would imply roughly 4 billion entities per file. Now it is possible that Protel chokes on larger files due to bugs or memory handling problems. And I know that there are certain actions using select and move selections that can cause groups of entities to become sort-of invisible. But this is not related to file size and I can see how this could be described as a buffer overrun. I would like certainly like to know more about the buffer overruns you describe - especially in regard to the interaction with the autorouter. Thanks, Ian Wilson * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Autorouter Stability Problems
Hi Brian Thank you so much. Yes, I have seen 'phantom primitives' (could select it, but couldn't see it or delete it) and I have gotten polygon plane counts of 8 when it should have been 7. This design has been heavily edited, as you suspected. I will review your answer in detail follow the steps. Have you heard about the upcoming Protel Release - 'Phoenix'? Will this improve upon the autorouter? Another Member of your forum asked me to send him the database in Specctra format to see what happens. I did. It'll be interesting! Thanks again John -Original Message- From: Brian Sherer [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 19, 2002 12:13 PM To: Protel EDA Forum Subject: [PEDA] Autorouter Stability Problems Hi, John- In my experience, the two likeliest possibilities are 1) database buffer overrun, and 2) phantom primitives that no longer exist but are being treated as real. 1) Protel doesn't flag buffer overruns at all, in any server. It can occur when for instance multiple Polygon Pours are used instead of Split Planes on a multilayer design. 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. In a failure to initialize or crash situation, this is often related to item 2. 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. This is very hard to find, as Protel only sees the topmost or most recent object if you try to double-click an area to query existing entities. The phantom objects are not directly editable, apparently because they have been officially deleted/modified, even though they still exist wherever Protel keeps track of electrical connectivity at each physical point of the board. There are two ways to deal with removal of duplicates. First, inspect the design and determine where the real planes/polygons should exist. Next, run Board Info and check that all such objects are accounted for. If there are extra objects, you'll have to delete them, by A) export to Spread / Delete offending objects / Import from Spread. Usually, the Spreadsheet server will also overflow. Don't panic. Go back to the original file and do a Select All. Now select Edit /Move and double click on each Polygon and Plane to cause the Select Object list box to appear. Inspect the list for duplicate objects. If a duplicate is found, choose one of the duplicates and move it to a neutral area well outside the active board area. Deselect Outside the area of the moved object, then Edit/Clear to permanently delete it. Deselect All, then repeat the process until all duplicate Polygons and Duplicate Planes are removed. There must be a 1:1 correspondence between the Number of Polygons in Board Info, and the actual Polygoncount by inspection. The autorouter will _not_ flag the extras, however, if it is able to successfully route, the DRC _will_ show the extra polygon as a clearance errors at each point of the polygon. This is the only way I have found to remove Phantom objects regardless of their size/complexity, and is useful for designs where repeated polygon edits have trashed the database. Brian Sherer Foothill Services LLC [EMAIL PROTECTED] At 09:32 AM 1/19/02 -0600, you wrote: Hi guys I have been trying to get a board autorouted (I have done more complicated boards than this one, although this is an odd shape) and am having lockups 2minutes into the routing process, etc. I have 2 workstations that I ve tried running this on, and both have the same result: (running 99SE with Service Pack 6, #6.6.7) Unable to initialize unless I select all the components, pre-routes, and track, copy them to a new file, then Update PCB from connected copper . This is an extreme pain, as I have to redo my layer stackup and design rules. Lockups after a couple of minutes into the autorouting process; Never goes to 100% completion, although once it went to 97%. Previously I routed a Pentium III board with very few problems, but this board is somewhat less complex (10 layers, 3274 pads) this has been an absolute nightmare! I have burned up 6 days trying to get this to run. Any ideas? Will I be forced to export to Specctra send it out to a design bureau (very undesirable) Any assistance will be greatly appreciated!!! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Autorouter Stability Problems
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 areas. 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! [EMAIL PROTECTED] Abdulrahman Lomax Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Autorouter Stability Problems
At 12:16 PM 1/19/2002 -0600, John Whittaker wrote: Have you heard about the upcoming Protel Release - 'Phoenix'? Will this improve upon the autorouter? It is a near certainty. As a completely rewritten router, we expect, it may have some bugs, but I also suspect that we will be very glad to see it. There is no sign, however, that the router or any other aspect of Phoenix is in Beta test. This is a matter of concern. Since Protel now has a formal Beta program with NDA, it is possible that some Beta testing is going on, but it seems quite unlikely that wide-scope Beta testing, needed to give the program a serious workout to find subtle bugs and shortcomings, has begun. If there are only a few testers, it is not really Beta. http://www.protel.com/media/mr02_situs.htm [EMAIL PROTECTED] Abdulrahman Lomax Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
