I have had this happen 

i don't think it said 'analying' but it hung for a long time

this was even on very very simple boards with no tracks and no pours
when selecting inside an area

i tracked it down to having a mech layer current and using select inside
when there was a busy logo component on the top layer

the primitives of the component were all top overlay fills, about one
bazillion of them

task manager said protel not responding but if you drink enough coffee
for a long enough time it comes back

it doesn't always do this though, just sometimes

if i delete the logo i have never seen this behavioir

Dennis Saputelli

JaMi Smith wrote:
> Terry.
> Welcome to the world of Protel.
> If you are only waiting 6 seconds for each "Analyzing GND" session, consider
> yourself extremely lucky. I have done boards that would take several minutes
> each time it would go "south for the winter" on an "Analyzing" session.
> This is my all time favorite Protel "tie the computer in a knot" trick.
> This is where I have even gone into the "Task Manager", only to have it tell
> me that Protel is "not responding", and then have Protel reemerge fine and
> still operatring properly after I walked away and took a very long coffee
> break.
> According to the Protel people that I talked to a little over a year ago,
> there is absolutely nothing that you can do about this one, except get up,
> and take a walk around the building each time it happens.
> I have had people make the suggestion to rename all of the nets, and I think
> that I may have even tried to do that, all to no avail.
> I have also had people tell me to turn off all "on line" DRC checking, but
> if I remember correctly, that didn't work either (or possibly it did, but
> left me to make such mistakes that I gave up on it).
> This is the one real time consuming bummer that I could never get around,
> and the one place where my systems would be most prone to crashing.
> The only answer that I have ever found was to delete all of the Polygon
> Planes, and always make them the last thing I do (although I do not think
> that that would not be the answer in your case with your 35 plane segments).
> I often wondered whether or not transferring all of the plane segments to  a
> mechanical layer (or possibly just any "different" or "unused" layer) while
> working would allow me to skirt the problem, although every time I got to
> the point in the project where this became a problem, I never had the time
> to experiment with it.
> I have also wondered whether or not changing the resolution of the internal
> "segments" of the plane would have any effect, since it seems to go thru all
> of the small line segments of the plane and check them all, which I think is
> why it may take so long. This would in itself take alot of time with 35
> plane segments.
> A faster machine is the closest I ever came to solving the problem, but even
> on a 2 GHz P4 with a 400 MHz bus, the problem is still there, although not
> as bad.
> This is one of those things that has even been brought up several times not
> only here (PEDA), but if I remember correctly, also in the DXP forums, all
> to no avail (Again, if I remember correctly, this is one of those posts that
> never gets answered by the boys down south in Oz).
> I know that Protel / Altium is aware of the problem in both P99 and PDXP,
> and I am pretty sure that they are trying to find a work-around or some
> other kind of fix for this in PDXP.
> Respecting a "fix" for PDXP, I would suggest that they somehow "tag" or
> otherwise "identify" all of the internal "fill" type "segments" of a plane
> on the first pass thru DRC, and then only if the plane changes (is
> "repoured") do they have to "recheck" or "reanalyze" the whole of the
> "segments" of the internal plane. This would mean that they only have to DRC
> the outline of the plane against any other traces, which should be much
> faster (they may be doing this already).
> Another possible fix for PDXP would be to have a DRC mode that would go in
> and somehow "tag" or otherwise "identify" everything in the board that has
> already passed DRC, so that it would not be rechecked. Possibly the inverse
> of this would be more practical, in which any "new" additions or changes
> since the last DRC check would be somehow "tagged" or "identified", and then
> a DRC could be run on just those items alone, so as to not recheck the
> entire board, which appears to be what is happening now.
> Yes, I still want my Service Pack 7 for Protel 99 SE, but even if they gave
> it to me, I don't think that there would be any improvement in this area.
> Respecting PDXP, I think that there should be at least some minor fixes or
> improvements in this area in the real SP3, if it ever gets here. Protel /
> Altium have taken enough time with working on the Pre-Release of SP3 and
> Pre-Release SP3.5 to completely rewrite the whole program from the ground
> up, so it will be interesting to see whether or not this works any better.
> It seems that whenever I or someone else really "bad mouths" some issue in
> PDXP, that it gives the people in Oz a little extra "incentive" to fix the
> problem. Maybe this will have some effect on future releases.
> Anyway, by the time you have read this, you will probably have completed the
> board, so this won't be a problem anymore, at least until the next time.
> JaMi
> ----- Original Message -----
> From: "Terry Creer" <[EMAIL PROTECTED]>
> To: "'Protel EDA Forum'" <[EMAIL PROTECTED]>
> Sent: Tuesday, July 29, 2003 4:09 PM
> Subject: [PEDA] Analysing...
> > Hi all,
> > I've just been handed a rather large board with quite a few
> > individual GND polygons on it (35 to be exact). I've been asked to clean
> it
> > up so we can have a prototype made. Every time I make a change to the
> board,
> > (ie, move track, delete fill etc..etc..), after the edit, it sits there
> for
> > about 6 seconds with " Analysing GND" in the status bar at the bottom, and
> > then all is well until the next edit.
> > I've turned off all online DRC checks, and anything else I could
> > think of, to no avail. I'm pulling my hair out trying to get this done
> (and
> > there's a lot to do...).
> >
> > Any ideas?
> >
> > Thanks!
> >
> > TC
> >

Dennis Saputelli

  ========= send only plain text please! - no HTML ==========
Integrated Controls, Inc.           www.integratedcontrolsinc.com  
2851 21st Street                    tel: 415-647-0480
San Francisco, CA 94110             fax: 415-647-3003

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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/[EMAIL PROTECTED]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to