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
guidelines and are still experiencing problems getting the Autorouter to
start please email a copy of your file to us at
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
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,
can remain in the Initializing shape based route pass, or stop after

Answer: Use the following points to help identify why the board will not

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

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
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
to edit the footprint and remove the polygon.

10. Locate and remove polygons that are not visible. See Item 2434 for more

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

End quote.


Gisbert Auge
N.A.T. GmbH

                    "Mike Ingle"                                                       
                    <mikei@ancore        An:     "Protel EDA Forum" 
<[EMAIL PROTECTED]>          
                    .com>                Kopie:                                        
                                         Thema:  [PEDA] router settings                
                    antworten an                                                       
                    "Protel EDA                                                        

Unless there is some reason not to can the reply be posted so the rest of
might benefit from the recommended router settings?  My other question
is why wouldn't the reply have been posted here in the first place?


-----Original Message-----
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.


Gisbert Auge
N.A.T. GmbH

                    ul-Rahman            An:     "Protel EDA Forum"
                    Lomax"               Kopie:
                    <marjan@noho.        Thema:  Re: [PEDA] Reply1 MS

                    antworten an
                    "Protel EDA

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

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.

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