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
