At 01:03 PM 11/19/01 +0000, Jason Morgan wrote: [...] >Michael, > >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 >unacceptable)
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* rare. 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 experiment. >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 >tell >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. [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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
