At 04:29 PM 11/19/01 +0000, Jason Morgan wrote:
>The files in question were returned to Protel under NDA, they confirmed the
>problems as reported and indicated that at present there was no fix.

(1) They have said that before when there was an easy fix. Not always, of 
course, but it is highly unlikely that there is no workaround for a 
problem. Maybe I have seen that once.

(2) Obviously we do not expect proprietary data to be transmitted "to the 
public." In fact, we don't want attached files to go to the list. Speaking 
for myself, I'll sign an NDA; but it should really not be necessary. A 
printed circuit design with no comment fields, even if everything else is 
there, is completely inadequate to reproduce a design. Further, it is 
likely that some of the rest of the data could be eliminated and still the 
file would display the problem. But just the comments and a PCB file with 
no schematic is little more than a pile of primitives, I cannot conceive of 
how it would be used except possibly by someone who already had a lot of 
inside information.

>I can say that there are about:-
>1100 components spread across two sides
>1000 nets
>10000 track segments (last time I talked to the guy doing the layout)
>2450 vias
>450 holes
>6 layers
>Several silk and mech keepout layers etc.
>5000 SMT pads
>15 Polys on two layers

That's a large number of components, but not terribly unusual. The rest is 
not even truly large.

The Board Information Report includes polygon fill track in its report so 
perhaps those polygons were not filled for the report.

I just looked at a moderately large design that I did a year ago, it had
568 components
961 nets
91,168 tracks
2398 vias
9431 pads (mostly SMT)
10 polygons.

The track count includes the pour track.

This design had no problems.

>.DDB runs at about 20-70Mb and lives on the same HDD as the program.

That is a huge ddb. If it has not been done, I suggest emptying the recycle 
bin and compacting the file. The file I described had a 6.1 MB ddb file. I 
have automatic compact on exit set. If I were getting crashes all the time, 
I might be nervous about that.

>All in a 10" x 8" board area
>In any case, Protel works on at least one machine here (if with some
>deficiencies) without crashing (too often). That eliminates user error and
>bad files (incidentally neither of which should EVER affect a well written
>program, I know, as well a hardware engineer I'm also a programmer).

Sure. Now, to real life. A program like Protel is *inordinately* complex, 
and the market is relatively small and market pressure high, so beta 
testing is limited in what will practically be tested. We are still 
discovering, occasionally, bugs that apparently escaped the notice of all 
of us for two years. Obviously, these bugs do not affect routine 
operations, or they would have been much more easily identified.

Sure, every bit of data should be checked for integrity, but there is also 
another constraint: many Protel operations must be completed quickly. As I 
am sure is obvious, complex checking can greatly lengthen the time it takes 
to process data. If you have to draw 100,000 tracks, how much checking are 
you going to do? Or are you going to trust that what was written with error 
checking remains good?

>So far as the poly problem goes, the fix in that case it to set 'Auto
>Repour' to 'Never' and then use my 'Repour All Poly' server, available on
>the yahoo group, failing to do this results in some long waits!!

And there are other workarounds. The problem here is truly one of a massive 
amount of data. Perhaps Protel could be much more efficient in processing 
the data, perhaps not, I really don't know. I do know that it is much 
faster than other CAD programs I have used, perhaps it is slower than 

>Explain why a fresh re-install of 2000 + sp2, then Protel +sp6 crashes on
>several operations, even on first run.

I'd ask "what operations and using what data?" But given that this is *not* 
general experience, there remain not too many possibilities.

First of all, uninstall and reinstall does not remove all initialization 
files, and these files can sometimes cause crashes. It is necessary to 
remove those files. They live, as I recall, in Windows\system and have 
obvious Protel names with 99SE in them.

Explain why printing on one machine with exactly the same graphics card,
>graphics drivers, print drivers etc. works fine. On the new one it does not,
>if it prints at all, many entities are missing, especially outline boxes.
>(Note I've seen the latter on several past Protel installs with certain
>graphics cards, notably ATI)
>So we've got the same files on the same everything, what's left?  Protel is
>sensitive to PC hardware, surely not......

I think the answer is pretty obvious. There are, quite likely, some 
hardware problems on that new system. There might also be system settings 
that would affect this, such as video acceleration.

The bottom line is that most of us find Protel 99SE quite stable and 
reliable. Even if there is some weird system interaction, the problem 
*must* be something related to the individuality of the system and its 
user. Or else many more of us would see it.

We all get the same CD from Protel. While a bad file on the CD is a 
potential problem, usually I think that would show up on install. But maybe 
not. So getting another CD from Protel would be a possibility. (I'm sure 
they will give you another if the CD integrity is suspected.)

Quite a few possibilities have been suggested here. It is possible that Mr. 
Morgan has been, already, aware of them, and that the problem lies 
elsewhere. For one thing, there is likely more than one problem here, 
something might be user-related, something might be system-related, 
something might be file-specific, something might be a bug in the software.

At this point, however, my money would be on the fast system having some 
hardware problems, explaining much of its behavior. These problems could be 
such that they do not show up with any other program being used. Related to 
this would be unique ways in which that system is configured, compared with 
the one which works better. But this will not be the whole story....

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