cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X

Sorry to post this here....but I had no choice.

DeanLong
10-Marble

Sorry to post this here....but I had no choice.

It's a good thing I live in an area where there are no tall buildings.

10 REPLIES 10
msteffke
13-Aquamarine
(To:DeanLong)

Don't feel bad about the post. It is useful information to someone else
that may be crashing frequently.




Something is wrong with either your computer, or your Creo configuration. This is not normal.

See the list in the attached pdf, it's from my Creo Admin 102 talk in June.

Also go to File, Help, System Information.
Scroll down to the section titled "Configuration Information"
That will show you what config files have been loaded into session and where from.
You'll want to check those files.

Also look for a std.out file in the startup dir. That will list any obsolete config options.

You really want to go through all your old mapkeys, and recreate them for Creo.

Old config files can cause problems in Creo.

Also if you use the config editor inside of Creo, it's really easy to duplicate your entire config when you save. Thousands of lines in the config from such a duplication can cause problems.

If you are on any release of Creo before m060, you should update the software. The current release is m080, just released last week.
The oldest release you should be on is m060.

David Haigh

David,

With all due respect to your work on tracking where the issues come
from: You are pushing the blame towards the users, and that is wrong.

If the software crashes because there are old configuration files
present, then the software is just poorly written.

Graphics driver versions... they can make an impact on performance but
should *not* crash the software. (Did you ever hear of a game crashing
b/c of a certain graphics driver version? I think not. And games use
much more extensive graphics than CAD these days.)

"just update" ... Usually an entire company is on a certain version,
and "just updating" is not that simple.

My experience with Creo2 (M030, so what? They released it so it should
work) is also that it crashes too often. Sometimes after i've had it
open for a long time. Sometimes on really simple tasks like a Measure
operation. There is no excuse for it.

That is my opinion anyway.

Best regards,
Patrick Asselman


Patrick



I would have to agree with you...obviously not enough testing going on before a build is released.



We just recently moved from WF4 m220 to Creo 2.0 m050 and we are having problems with performance when working in our large assemblies...very slow to zoom in/out of the model...delays in response time when carrying out a simple measurement...very frustrating for the users. It’s a noticeable backward step when compared to WF4.



On top of that we constantly are getting the attached error and it never comes up in a consistent fashion...might be when just starting Creo, creating a view in a drawing etc.



[cid:image002.jpg@01CECFFF.966ED8A0]



Regards,



Neal Hanratty

Engineering Systems and Standards Manager

Terex Materials Processing Group



T +44 (0)28 8241 8769

F +44 (0)28 8225 2740

M +44 (0)75 3495 2739

E neal.hanratty@terex.com


Now boys, let's play nice. 🐵 My post was not start a flame, merely to express my frustration. Tight time schedule with a looming deadline has the atmosphere a little tense.


Neil and Patrick, you both expressed my thoughts perfectly. However, being a PTC Kool-Aid drinker going on 25 years now, it's very, very old news that the software has been shaky and unpredictable it's entire life. It has always been a product revised and released too much, too fast within each rev. That is simply the pond we find ourselves swimming in.


David, you bring up some great points. If it were as simple as taking time out of the week to chase down all the "possible" reasons why 2 hangs, I may not ever get my job done. Navigating the PTC site is cumbersome enough. Downloading, uninstalling, re-installing, debugging, loading new configs (if it was the old ones causing the issues) is not always a simple task. It was mentioned that by the others that the software should work, period. Yes, sadly I know the MCAD business unit of PTC is now only a small portion of the iceberg that is visible. PTC is, IMO, spread toooooooo thin and is trying to be all things to all companies. Itwasn't always that way. But now the need to do all things "Data Life Cycle"has left us with a Data Management software instead of a Design software. Sorry.....I got started....I will quit that folly.


To the point, some answers Iknow straight away.


I do not use mapkeys...never have. I have always used Pro straight out of box. I have alwas had the thougth they were counter-productive for me in the way I use Pro. I have done a ton of training and mentoring in the past and it made sense to stay true to the original flavor when training. It's a habit/style that has remained.


I created new configs when I loaded and launched2 for the first time. If fact, I was sick of seeing the editor every day because I was nauseous with the color scheme of Creo. Whomever was responsible for the complete overhaul of the colors should be taken out behind the wood shed. I wish it were as simple as "gooing back" to the Pre-Creo but EVERYTHING has changed. At times, I wonder why I didn't just buy SolidWorks because it seems the programmers tried very much to copy the look of the other software company in town. Many forget the reason SW looks the way it does is because they wanted to look "different" that Pro. Now we just look silly that we have copied them. And....who thinks dull gray parts on a bright white background it good for ones eyes anyway? The world has gone mad.


I have been trying to noticea patternwhen my system hangs. It seemed to be when spinning/panning/zooming the model. However, yesterday's final straw was I moved the cursor within the screenafter the model sat idle while I was on the phone. It locked and required a restart of the whole machine.


Eventually, I will have a break in my schedule to allow for the update. Until then...Save (more) Often (than usual).

What you are saying, Patrick, is basically right. Nevertheless, I appreciate the input from David, since we have to be able to keep on working, and the excuse '... the software is just poorly written ...' will not justify to go home and wait for a better build.

So, keeping the pressure on PTC to release a better product is one thing, being able to continue working is another.

Regards, Hugo.

I agree up to a point. With regards to graphics controller software, the OS manufacturers have taken it upon themselves for some time to have this software attached to the kernel of the OS to improve performance. Good idea for speed, bad idea for security, crashes, etc...

Other than that, blaming the users for software that crashes just means that the users RE trying to use the software in ways that ptc haven't thought of or tested for. The more these issues come up, the less likely users are to 'update' the software.

My personal opinion is that PTC has way too many configurations of options, extensions, etc... and should simplify the software to basic, intermediate, and EVERYTHING (and move the users up to the next level of software if their licenses fall in between). They should be able to generate metrics based on the licenses they sold so far. This should simplify their tech support somewhat.

Next, how about the same for configurations. Have some 'recommended' setups for most users, with 'advanced' options to set each config option individually.


Christopher F. Gosnell

FPD Company
124 Hidden Valley Road
McMurray, PA 15317

It is Friday, isn't it?
Surely on poets day, there is no place for posts such as this one, brimming with common sense and good ideas?

Come on, Chris, ...

🐵

John


Let me weigh back into this conversation.

My intention was not to assign blame but to provide solutions.



But since, I guess, it came across as blame, I'll own that, and say it comes out of real world experience.

Ultimately the blame goes to the software and PTC, as many of you have said.



But in the end, assigning blame, doesn't fix the problem. It might make you feel good, but your still left with the problem.



We went live with Creo 2.0 in March with rev m030. This was after I'd been working on the configuration and installation issues for about 10 months.

Let me also say that it wasn’t just our group, we when live on m030 across most of the DOE/NNSA Laboratories. So it was a large number of users.



For most folks it went relatively smoothly, but we had a number of users that had graphics problems.

We had to update graphics drivers on those machines, there were two machines where we just decided to update the graphics cards because they were so old.

This is not unique to Creo. I remember having to update the graphics drivers often when Wildfire came out. Finally after 6 months the vendor had a driver that was stable.



The thing is, m030 was slow and we had a lot of problems with the interface to PDMLink. I updated everyone to m040 as quickly as possible.

That was an improvement, but there were still issues and it was still slow. M050 provided some performance increase, m060 was a significant improvement.

Both m050 and m060 were far more stable than anything preceding them. Currently I'm running m070, and plan to get m080 ready to roll out next week.



That takes care of graphics drivers and maintenance builds. Let's now look at my experience with config files and users



I'm sure you have users that have created their own config files, because they want a different work environment.

Perhaps they work on large assemblies and want different default behavior because of that. That's the beauty of the software, each user can customize their environment.

What I found after going live with m030 was that the users that were crashing a lot, had copied their old personal config from Wildfire 4 to use in Creo.



The thing you need to realize is there are config options that get obsoleted with every revision of the software. And with Creo, some options changed spellings and meanings.

For each of these users we went through their personal config, removed all the old mapkeys, and removed anything that was a duplicate of our default loadpoint configs.

We would then start up the software and look for a std.out file that would warn of any problem config options. Then we fixed those.



One user had a config file in their %HOME% directory that we didn't realize was getting loaded. Looking at System information showed us that file.

Turns out it was about 4 years old. We just eliminated the file and his problems went away.



The other issue is the config editor. In the early versions of Creo it was seriously broken. If you saved, it copied the entire session config into your personal config file.

Even in current revs, if you don't know how it works now, you will do the same thing. It doesn't work like it used to, shame on PTC, because it was great in WF4.

I had users that had added one option to their personal config, and ended up with a complete duplication of the config.sup, load point config.pro and any other configs that had been loaded in session.

And sometimes not just one copy of those, multiple copies. Ever seen a config with over 10k lines? It causes problems.



Finally about the issue that upgrading a lot of users is a pain in the neck, or even lower down. There are ways around that.

My talk at the conference in June was on how to do that. If you want a copy of that talk, send me an email and I'll send you the PDF.

People at the conference liked the talk well enough that I received the best overall presenter award for it.



David Haigh

On 2013-10-25 17:26, Haigh, David A. wrote:
> Let me weigh back into this conversation.
>
> My intention was not to assign blame but to provide solutions.
>
> But since, I guess, it came across as blame, I'll own that, and say
> it comes out of real world experience.
>
> Ultimately the blame goes to the software and PTC, as many of you
> have said.
>
> But in the end, assigning blame, doesn't fix the problem. It might
> make you feel good, but your still left with the problem.

True, but accepting problems and not telling anyone about them is
definately not going to fix anything.

Think of using Pro/E as going to your favorite restaurant. If the food
is not up to standard, you have to tell the waitress about it, otherwise
the chef will never know. Not telling the waitress for fear of hurting
her feelings or thinking "she can't help it" will only help the demise
of your favorite restaurant. You need to speak up.

> I'm sure you have users that have created their own config files,
> because they want a different work environment.
>
> Perhaps they work on large assemblies and want different default
> behavior because of that. That's the beauty of the software, each
> user
> can customize their environment.
>
> What I found after going live with m030 was that the users that were
> crashing a lot, had copied their old personal config from Wildfire 4
> to use in Creo.
>
> The thing you need to realize is there are config options that get
> obsoleted with every revision of the software. And with Creo, some
> options changed spellings and meanings.
>
> For each of these users we went through their personal config,
> removed all the old mapkeys, and removed anything that was a
> duplicate
> of our default loadpoint configs.
>
> We would then start up the software and look for a std.out file that
> would warn of any problem config options. Then we fixed those.
>
> One user had a config file in their %HOME% directory that we didn't
> realize was getting loaded. Looking at System information showed us
> that file.
>
> Turns out it was about 4 years old. We just eliminated the file and
> his problems went away.

I would like to see software that simply ignored old config options,
maybe warns about them, but I definately don't want the software to
crash on them. I think somebody else already proposed that PTC have a
good look at their options and simplify them, and I think that is a very
good idea. If each option causes a possible instability in the software,
you had better minimise the number of options (and maximise testing on
the use of those options).

Making the users do all that work of figuring out which options are
obsolete, which have changed spelling, and which cause instability,
should be something of the past. Nowadays a CAD system, even the big
ones, should just work. I know that in the past many companies,
especially the big ones, had a dedicated person to maintain the CAD
system, but these days that is not normal anymore. The economic crisis
has probably trimmed away such luxuries in most companies, and the local
IT guy is expected to install the CAD software.

> The other issue is the config editor. In the early versions of Creo
> it was seriously broken. If you saved, it copied the entire session
> config into your personal config file.
>
> Even in current revs, if you don't know how it works now, you will do
> the same thing. It doesn't work like it used to, shame on PTC,
> because
> it was great in WF4.
>
> I had users that had added one option to their personal config, and
> ended up with a complete duplication of the config.sup, load point
> config.pro and any other configs that had been loaded in session.
>
> And sometimes not just one copy of those, multiple copies. Ever seen
> a config with over 10k lines? It causes problems.
>
> Finally about the issue that upgrading a lot of users is a pain in
> the neck, or even lower down. There are ways around that.

Of course there are, but remember that the CAD admin is probably just
an engineer doing it on the side in between deadlines, the IT guy
doesn't know much about the CAD software, and the other office - far
away in a different country - doesn't want your local plant to be on a
different build code.

> My talk at the conference in June was on how to do that. If you want
> a copy of that talk, send me an email and I'll send you the PDF.
>
> People at the conference liked the talk well enough that I received
> the best overall presenter award for it.

Not to dismiss your presenting skills, but maybe that shows how
important and painful this problem is to all the attendees?

In any case, thank you very much for sharing all this extremely useful
information, and let's hope that PTC is listening and learns from this
discussion, so that they won't be embarrassed again on the next
conference by someone winning best presentation on another "how to
prevent crashing" presentation. 😉


> David Haigh
>
> Phone: 925-424-3931
>
> Fax: 925-423-7496
>
> Lawrence Livermore National Lab
>
> 7000 East Ave, L-362
>
> Livermore, CA 94550
>


Cheers,
Patrick
Announcements
NEW Creo+ Topics: PTC Control Center and Creo+ Portal


Top Tags