Hi Mike,
I have no problem with posting the reply I received from Altium to the group. I don't know why this is being made personal, anyway, it's helpful. Maybe Abd's comment gives the reason for it. But, as I learnt from this mail, there are some articles in the knowledge base I did not check before. Altium support, quote: In general you can find the reason that the Autorouter will not initialize in our Knowledge Base article #1694 (see below). If you have followed these guidelines and are still experiencing problems getting the Autorouter to start please email a copy of your file to us at [EMAIL PROTECTED] *********************************************** Item - 1694 Logged: 30-Mar-1998 Revised:12-Oct-2001 Item categories: Autorouting Products affected: Protel 98 (All Versions);99 (All Versions);99 SE (All Versions); Operating systems affected: Windows 95;98;NT; ---------------------------------------------------------------------------- ---- Query: Why won't my board autoroute? Details: Sometimes when attempting to route a PCB file in Advanced Route, it can remain in the Initializing shape based route pass, or stop after Initializing. Answer: Use the following points to help identify why the board will not route; 1. Check that the PCB outline has been placed on the Keep Out Layer and not a Mechanical Layer. (For example, make sure that the Keep Out Layer is used instead of Mechanical Layer 1 as these 2 layers are the same color). 2. Insure that there is some outline on the Keep Out Layer. It has been found that the outline need not be completely closed, i.e. the corners do not need to touch. Arcs are not supported in board outline on the Keepout Layer. They are ignored. This is the reason why a board outline defined by a full arc will not initialize and start routing. In the case where tracks and arcs make up the board outline, the arcs get ignored and in effect a straight line is used to close up the gap of where the arc was placed. Generally, in place of the arc there is a straight line assumed from and to the nearby tracks on the Keep out layer. 3. Enable all the layers that are needed for routing the PCB in the Design Rule � Routing Layers setup. When setting up the routing layers you will need to keep in mind that the present autorouter requires either the top or bottom layer to be enabled in the Routing Layers setup. Otherwise you will receive the error message "Design Rule Error: no pads defined on any layers". Pressing OK will close down this error and it will appear to want to start autorouting by prompting you to change the routing grid to 0mil. The end result is that the autorouter will be unable to initialize. 4. Avoid using net names with hyphens, spaces; characters other than the alphabet and numbers. 5. Maintain net names less than 10 characters (pre P99SE only). 6. Maintain pad designator names to 4 characters or less (pre P99SE only). 7. In Route 98, the router requires all parts of the board to be within a 32x32 inch region from the absolute workspace origin (not the set-able current origin). Note that the coordinates on the Status bar display the distance from the set-able current origin, so if you are not sure reset the origin. To reset the origin select Edit � Origin � Reset from the menus. In Protel 99/99SE, the autorouter workspace is the same as the PCB workspace of 100x100 inch. 8. Avoid placing any polygons prior to routing. This includes split planes. 9. Polygons that are placed on the top or bottom overlay, or mechanical layers can prevent the autorouter from initializing and routing the PCB. This includes polygons that have been included in a footprint. You will need to edit the footprint and remove the polygon. 10. Locate and remove polygons that are not visible. See Item 2434 for more details. 11. Avoid placing components on a grid smaller than 1mil. It is recommended that components be aligned to a 5mil grid. On high density PCBs, too many components, tracks and other primitives placed on fractional grids (that is less than 1mil grid) can cause the autorouter to find too many contentions. A message similar to "One or too many contentions have been found.." The only remedy to this situation is to place components and any routed tracks on at least 1mil grid. 12. Avoid placing tracks, arcs, etc on the multilayer. The router fails to start when it finds primitives other than pads/vias on the multilayer. 13. Check the PCB against the maximum capabilities of the autorouter listed in Item 665. This includes the number of components, pins, etc. ************************************* You can access our Knowledge Base at http://www.protel.com/kb/default.asp. There are a number of articles that focus on the Protel Autorouter and its use. End quote. Regards, Gisbert Auge N.A.T. GmbH "Mike Ingle" <mikei@ancore An: "Protel EDA Forum" <[EMAIL PROTECTED]> .com> Kopie: Thema: [PEDA] router settings 26.11.2001 16:15 Bitte antworten an "Protel EDA Forum" Unless there is some reason not to can the reply be posted so the rest of us might benefit from the recommended router settings? My other question here, is why wouldn't the reply have been posted here in the first place? Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, November 26, 2001 12:27 AM To: Protel EDA Forum Subject: Re: [PEDA] Antwort: Reply1 MS versus Linux I can back that statement, Abd ul-Rahman. Last week I received a mail directed only to me from Protel support concerning the setup of the router. I had not turned to them directly; they had been reading my postings on this thread. Regards, Gisbert Auge N.A.T. GmbH "Abd ul-Rahman An: "Protel EDA Forum" <[EMAIL PROTECTED]> Lomax" Kopie: <marjan@noho. Thema: Re: [PEDA] Reply1 MS versus Linux com> 23.11.2001 21:49 Bitte antworten an "Protel EDA Forum" At 10:24 AM 11/23/01 -0500, Fred A Rupinski wrote: > > Has anyone seen Protel reply directly to this forum? > >Yes, on 11/20/01, from Samual Sattel, regarding "Protel usage" I did not find that post in my archive. I suspect that Mr. Sattel may have written directly to Mr. Rupinski in response to a Rupinski post on this list. That is not uncommon. Protel, I was informed perhaps two years ago, has a policy that employees do not post to this list except for "Protelcsc," Protel Customer Service Center, which occasionally pops in when they can easily clear up some mystery that we have not handled for ourselves within a reasonable time. Exceptions are quite rare. We are pretty sure that very many employees do read this list, though perhaps fewer than was the case at one time, and perhaps once in a while an employee gets carried away and responds directly. I have been asked by an employee on occasion to convey some information to the list, a way around the restriction. At one time Protel and the users had a fairly serious adversarial stance toward each other; I think that the rule originated at that time. It was far too easy for flame wars to start. There would be other reasons as well; it can take a lot of time to write thoughtfully and it is perhaps not the best usage of employee time. I know that Mr. Foley of Accel wrote on the Accel user support list with a serious anti-time-wasting message directed at the users as well as, perhaps, at employees. But we know what happened to him, I don't think he is in the CAD business any more. I can say that there were many Accel customers who, while they were insecure about the future of the product when Protel took over, nevertheless were not sorry to see Mr. Foley go. Obviously, it is up to the users and their companies what is a "waste" and what is not. However, I *would* recommend a certain level of participation by certain kinds of Protel employee. Imagine how we would feel if a development engineer were actively asking us questions and reflecting on the answers. Relations have improved to the point that serious rudeness from a few users would be pretty strongly damped by the user community. Rules for employee participation could be developed, such as, for example, that employees would not respond to flames, that employees would need to be authorized by Protel to participate here, and limits might be placed on what the employees could reveal. I do think, however, that the value of secrecy is vastly overblown. Some matters properly remain secret, but secrecy clearly hampers communication (well, duh!), and good communication between the developers and users could greatly increase the pace of program improvement. On the other hand, there are also other ways that communication could be improved. A user panel is one possibility that has been mentioned; these users would be under NDA so the secrecy issues would not be such a problem; but they would be allowed to let the user community know that they were in communication with Protel and could serve as a conduit for surveys, etc. [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/[email protected] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
