Anyone have Problems with Pro/Creo and or Creo locking up and getting a continued (Not Responding) error? I have been having this issue for some time now. It seem when you need to work the processor hard this error appears. The xtop.exe file is tying up 50% of the CPU memory.
try to install FLEXnet 10.8 available on ProE WF5 (Creo Elements/Pro 5.0) on your license server. Do not use FLEXnet 11.x available on Creo 1.0/Creo 2.0.
Yes we are running the Creo 1.0 FlEXnet in anticipation of upgrading to creo 1.0. But I have ran into the same problem with Creo 1.0 Parametric in regards to getting the Non-Responding error. Any thoughts?
my suggestion is:
1.] install FLEXnet 10.8 available on ProE WF5 (Creo Elements/Pro 5.0) on your license server
2.] install Creo 1.0 Parametric on user workstations
The above mentioned combination is supported.
NOTE: I am not sure if it will solve your problem.
Thank you on the fast response.
. One last question will I have to get another license pack to install the FLEXnet 10.8 available on ProE WF5 (Creo Elements/Pro 5.0)? The last License pack I received was for Creo 1.0.
This issue has been driving me nuts on Creo 2 F001! I get this error almost everytime after creating a really mean (small) mesh with AutoGEM. What I'm finding is that my computer just doesn't have the power to process quickly enough. Many times, I'll just walk away - grab lunch or something, and when I come back, it's back online and running smoothly. Sometimes though - it fully crashes.
I've got a single quad core with 24GB RAM - same quadro 4000. I'll get the "Not Responding" error with as little as 154K elements... But, it eventually "wakes up".
I'm hoping I can use this as leverage to get a more powerful computer (buwahahaha).
Hello, my guess is something on your config pro options or paths in config.pro.
My first opinion is to run those tests in a session with no config.pro and see if the results are the same, then adding a config.pro 1 by 1 variable to test wich one is making the error.
I don't expect you will ever get a worthwhile answer to this issue. I have been running Pro since rev 5 and a private consultant for 19 years. Ever since pro was ported to windows this issue has existed for reasons that no one can explain. Multiple Pro versions on multiple types of workstations with all types of graphics boards. I will say that experimenting with your graphics drivers can reduce, but will not eliminate this issue, it seems to rear its ugly head when ever it wants, sometimes during heavy computational features sometimes on simple. My guess is that this is an inherant problem with windows that can not be remedied, so PTC ignores it or is blaming Microsoft, Nvidia or whomever. It's hear to stay, so save often.
If it happens consistantly on a specific feature either change the graphics driver or you can also try changing the parts accuracy, sometimes this will get you through it.
BTW, the reason I chose to answer this is because my computer is at xtop.exe 50% and thought that maybe just maybe some one had a solution to this finally. So good luck, I will quit Pro now and hope I saved in the last hour or so.
I have been on Pro|E for a long time and now I am on Creo. My old Windows NT workstation use to simply quit and do a cold-crash of Pro|E. It had the simple approved FireGL graphics card and enough memory. At that time I found that it is easy to "confuse" the processor. If you -overclick- and get ahead of the processor, it just crashed. This is a holdover from the Unix days when serial processing was the only game in town and all storage media was treated the same.
Windows tried to break that serial processing by allowing certain tasks to multi-process almost from day one. Memeory, cache, and hard-drive data was one of those areas that was always multitasking. Anything ported directly from Unix tended to crash. Since the kernel of Pro|E is all unix, still, you will have these issues. It is simply our responsibility to make the process as serial as possible. I can lock up Creo in a heartbeat. At least these days, it will recover at some point 90% of the time and improving with each datecode release.
Funny thing is, if you ever worked on SolidWorks, it too has a bad habit of cold-crashing. You can even repeat it with high accuracy after the 1st time. I think it is just the name of the game with high end software and the billions of transistors that have to work in unison where you know that a tiny percentage of these switches are not "prefect".
Welcome to the forum Matthew. After all these yearof being a member, I hope you can share your insights with us on a regular basis.