At 01:03 PM 11/19/01 +0000, Jason Morgan wrote:
>First lets get something straight, I take offence at your questioning my
>competence with Protel, I've been using it for a very long time and am
>familiar with all of its usual weird behaviours (even though they are still

I reread Michael's post and it did not make any personal criticism of Mr. 
Morgan's competence. Michael did note that, in his experience, many 
designers who have problems with Protel don't know how to use it, 
apparently Mr. Morgan took this personally.

My comment on this is that all of us have ways in which we can learn more 
about how to effectively use the program. Sometimes we have tolerated 
irritations for years without realizing that there was a simple way around 
them. This can include crashes.

When I was first running Protel, I had crashes all the time. They are now 
quite rare. What is different? Well, service packs, a Matrox Millenium G200 
card with acceleration turned off, and I run a resource meter and don't allow
Windows 98 to run out of resources, probably the number one cause of 
crashes on W98 systems. That's a W98 problem, really, but Protel 
particularly exercises the operating system. This, however, should not be a 
problem with Mr. Morgan's Windows 2000 machine, which does not have the 
severe resource limitations of Windows 98.

>The only reason we are using it at all, and not the latest Orcad (which we
>also have and use) is down to my experience with Protel.
>Protel crashes, its protel's fault (even you admit that).

I see a Protel crash once every few months. There seems to be some problem 
with the spreadsheet server or its interrelation with the other tools. 
Aside from that, crashes are very rare. Of course, Mr. Morgan may be 
exercising parts of the program that I'm not.

>   As for not using
>the bits that crash, I find the inability to print, save or load a file a
>bit of an inconvenience.

To be sure. But that is not the experience of the vast majority of us. 
There are a number of possibilities: (1) something is trashed in Mr. 
Morgan's Protel installation, (2) something is awry with his system, or 
with the interaction of Protel and his system, or (3) he is using the 
program in a non-standard way, which will cause defects in the less-tested 
aspects of the system to be exposed. The fourth possibility, that Protel is 
intrinsically buggy, we can rule out because it is working so well for most 
of us.

>   And as for missing and misplaced entities on
>plots, well
>that's to be expected these days.... nothings perfect.

It is not to be expected. Missing entities on *photoplots* should be *very* 

Each one of these items deserves to be studied in detail. If a file 
consistently produces an error, it is extremely valuable information for 
Protel, and there are those of us on the user group who are ready and 
willing to receive files and test them on our systems to confirm a bug or 
to lead us to suspect that it is a system-related problem.

>Ok, yes I admit its got much better (so far as features go) since P98, but
>at the expense of repeatable stability.

For Mr. Morgan, not for most of us. Protel 98 crashed more frequently for me.

>---------(A bit of background - you don't need to read this bit)
>Our first dedicated cad machine was a 1GHz P4 with 1G RAM, it *ONLY* runs
>Protel and win2K.
>We bought this as protel was pausing for more than 30 seconds per pin as a
>result of an edit of through hole components, it was also crashing many
>times a day.  EDA UK confirmed both these bugs and passed our design to
>Protel for investigation.

Which could mean that it went into a black hole. Obviously, we can hope 
otherwise, but the reality is that Protel has a limited staff and when a 
problem appears that is difficult to reproduce, it may get set aside in 
favor of more satisfying problems. One may say that this should not happen, 
but as long as we have human beings in charge, it will happen from time to 
time. For this reason, I do recommend communicating regarding suspected 
bugs with the user group. If others confirm it, then we know we have a bug 
and we can bring it to Protel's notice with our collective weight.

If we cannot confirm it, then we may put more effort into identifying 
system problems.

Often one of us will take a file that produces a crash and reduce it in 
size by cutting out primitives, each time saving it and testing it for 
continued manifestation of the problem. Sometimes this process, just by 
itself, identifies the problem. A bad file can feed Protel data that is 
outside the expectations of the programmers, and it is impossible to test 
all the possible configurations of data that can take place in the real world.

>It seems that the crashing is usually down to known problems when you have a
>very large design >1000 components, many polys (these are the killer) and
>many tracks on a mixed through hole / smt design.  The other problem is down
>to a bug with the on-line poly repour it seems to take ages when you have a
>large number of polys.

Well, this would vary greatly with the polygon settings. Polygons typically 
create a huge number of primitives, severely straining the resources of any 
system. It has been suggested by me that Protel go to a positive/negative 
merge system of creating pours, which would not involve all those 
primitives. But Protel is right with the bulk of the industry in terms of 
how it handles polygon pours.

I generally recommend not setting polygons to fill until the design is 
complete. A dummy track contacting, within the polygon area, all pads which 
require polygon continuity for connection (it is enough to contact the 
thermal ties), will eliminate the broken net errors. Then the polygons can 
be edited to fill them. Filling polygons with as large a track as practical 
given the needs of the design, and setting the pour grid to 0, will 
minimize the number of primitives created, as will setting the pour as a 
single pour instead of a cross-hatched one. With proper settings, this will 
produce a satisfactory pour.

>All we do know is that an 1 hours lost work of one of our engineers costs
>more than an extra gig of ram.

Definitely. And the CAD software costs much more than the cost of a machine 
in which to run it.

>A newer machine was bought for a 2nd engineer. This is a dual processor
>1.7GHz P4 with 1.5G RAM (at the time the fastest we could sensibly afford)

That should be quite a bit more than necessary.

>Initially on the new machine all printing activity from within Protel would
>cause a crash, from experience we know that protel is very sensitive to
>graphics cards (surely not the fault of protel), so changing it sorted some
>of the crashes (its now the same as the first machine)

It is suggested that graphics acceleration be turned off, at least as an 

>Protel still crashes, so what's going on?   Probably a fault of the IT guy
>who (despite my advice) wants lots of patches installed under windows, even
>if there is no visible problem, anyway that's his problem.....
>So where am I going?
>Ah yes, Michael, as you machine seems to be so stable, perhaps you could
>everyone its build as its seems you've got it right.

What might be interesting would be a survey in which we describe what we 
have in our systems, in terms of hardware and configuration, plus our 
experience with crashes. It might be possible to analyze such data to 
identify graphics cards, for example, that work, and those that don't. 
Right now, pretty much all that is collected, as data, is what systems have 
problems, not what systems do *not* have problems. Without the controls, it 
is hard to analyze the problems, one might be led down many blind alleys.

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