Skip to main content
H
hwientjes1-Visitor
1-Visitor
February 26, 2013
Question

Performance problems with large assembly/drawing in Creo2/Windchill 10

  • February 26, 2013
  • 21 replies
  • 4409 views
Hi all,
We are working with large assemblies/drawings in Creo 2 m040 and Windchil 10.0 m030.
We have big performance problems compared to the WF4-Windchill 10.0 which we had.
Anyone having the same problems? Any solutions?

Anyone using "light weight graphics"? How do you work with already authorised" models which are stored in earlier releases of Pro/E which don't have light weight graphics available?
Thanks,
Han

21 replies

Show previous replies
S
SteveVinyard1-Visitor
1-Visitor
February 28, 2013
I think when you do these fairly often they are also a lot easier on the server side of things. Your statement about the users and client machines is really where the work comes in. Clearing caches, updating CAD Clients, ensuring everything is compatible, Java update, Desktop Integration, Workgroup Managers (must be installed manually to register with Admin privs), Creo View update etc etc. It's a significant amount of effort to plan for all of this, especially in large environments. IT doesn't want to constantly keep directing project resources to continually redeploy the client software and support it.



[cid:image001.gif@01CE1587.2637C340]

Steve Vinyard
Application Engineer
S
ScottPearson1-Visitor
1-Visitor
February 28, 2013
AMEN!



Ben has hit the nail squarely on the head!



Sure, keeping up-to-date with releases is the optimal software
configuration (ignoring the "bleeding edge" issues, of course) but we
out here in the Real World don't have unlimited money, time, and
manpower to devote to never-ending software updates.



After adding up pre-deployment planning, training ,and testing..., plus
actual deployment efforts..., plus post-deployment troubleshooting, the
software release cycle will have gone full circle and the next release
of either ProE/WF/Creo or WC has been released. Rinse and repeat!



Such is the beast but it has indeed become a very costly beast to feed.



Historical Side Note: Remember the old days? Before annual
"maintenance" programs? Companies only bought new releases only after
showing technical or financial justification. And tech support was
purchased separately from software maintenance.



Enrollment in annual software maintenance was, at first, marketed as a
great way to avoid the upgrade budget battles when new releases hit the
street. "Make software upgrades an expected annual budget item," was the
pitch. (AKA: mailbox money for software vendor.)



Then enrollment in a maintenance program became a requirement in order
to receive technical support. (Shades of Mafia tactics.)



But since all the software vendors moved to similar policies, we all had
to go along with the "offer we couldn't refuse".



Well, that brings us to where we are today. When a company is paying for
an ANNUAL maintenance program, a company expects to get an upgrade no
less than ANNUALLY. Thus between the CAD program and the CAD File Mgmt
program, we expect to receive major upgrades to TWO mission-critical
software packages every year. It's no wonder we feel like we are
constantly planning, deploying, or recovering from an upgrade! (Not to
mention seeing half-baked software being released simply to satisfy
maintenance program target dates.)



So did we do it ourselves? Or was it done to us? Perhaps it's a chicken
and the egg thing.



But since how to deal with a 24/7/365 upgrade cycle (from financial,
operational, and technical viewpoints) has become as a big as a
nightmare as fighting upgrade budget battles ever was, I'm not so sure
that today's CAD software business model is benefiting the customer.



Scott Pearson
Senior Designer

CAD System Administrator

S O U T H W E S T R E S E A R C H I N S T I T U T E(r)
Space Science and Engineering Division
Department of Space Systems
6220 Culebra Road, San Antonio, TX 78238
D
davehaigh13-Aquamarine
13-Aquamarine
February 28, 2013
While it might be nice to just stick with the same software for a long period of time, in today's environment that is becoming impossible.

Because of hacking and nation state cyber attacks, you have to continually upgrade various software on your systems which has a great potential to disrupt Windchill.

David Haigh
J
jessh12-Amethyst
12-Amethyst
February 28, 2013
On 2/28/2013 9:22 AM, Loosli, Ben H wrote:
>
> The problem with moving Windchill to the latest MOR is that it takes
> too much planning and testing to do an upgrade every 3-5 months.
>
> The reliability of PTC's update tools means that I have 3 sets of
> servers. One is used to develop the upgrade procedure. It is an OOTB,
> minimal data environment. Once that works, then I move to a clone of
> my production system. Does the procedure work? Usually not and I spend
> more time with TS. When that is done, I then need to schedule time
> when the system can be offline for a day for the production upgrade.
>

If you take all of these steps, then, yes, it's really involved to move
to a new Windchill MOR of the same Windchill release.

Is there any evidence that taking all of these steps is justified for
recent Windchill MORs?

> Maybe if we were given more robust tools to work with and better
> diagnostic tools, we might be willing to upgrade more frequently.
>
> I just did an upgrade on Monday from 9.0m050 to 9.1m060 that I started
> testing from the rehost of production last August. Rehost failures,
> 2-3 days between calls from TS, WinDU failures, again 2-3 days between
> emails. The list repeats. What failed on one set of servers did not
> fail on the other, but different tests failed. It repeats on and on. I
> now have to do an upgrade to 10.0m030. Why am I doing that version,
> because WF4m210 that we are running is not supported on WC10.1. So I
> have stair step my upgrades. After 10.0, we will look at Creo2 and
> plan for its upgrade. And then add training for the 10.0 and the Creo
> upgrades. With luck, I may get to 10.1 early next year. Oh, but 10.2
> will be out!!! There were also budgets to consider as 10.0 required
> all new hardware. Training also takes budget money that has to be
> planned for.
>

Doing a rehost and/or upgrading between major Windchill versions is a
whole different world of risk and complexity than moving between MORs on
the same release stream.

I'm not suggesting anyone can just jump between Windchill versions at
the drop of a hat. I wish it were that simple but fully realize its
not. Moving to a more recent MOR within the same Windchill release is a
far lower risk, lower complexity affair, however, and should require far
less testing and no [re]training.

Overall, I believe system reliability and performance easily justify
taking the time to move to the latest MOR on a timely basis, as long as
does not over complicate (e.g. over test) this move.

--
Jess Holle

J
jfrankovich12-Amethyst
12-Amethyst
February 28, 2013
The source for that number was simply the reported issues tab of the upgrade advisor. And I fully realize that many of these 55 "new" SPRs may well have just been reported at that particular release but may have been introduced much earlier. I would hope that is true. I would further hope that PTC TS might back check High and Top Severity issues to earlier MORs, but that may be asking too much. The point, however, is that without vetting this out and determining which if any of these "new" issues might affect our environment, we can't move the new MOR into production.

John
J
jessh12-Amethyst
12-Amethyst
February 28, 2013
From my own experience the issue count has much more to do with how
many customers actively used the given MOR than which MOR the issue
first occurred in.

In the typical case where it is found that the issue existed prior to
the MOR (or release) in which it was reported, I'm not sure one can
change the "reported in" information on the SPR and I don't know of
another way to reflect such information (apart from in the SPR's notes,
which obviously doesn't help in terms of broad queries and statistics).

D
DanielReid12-Amethyst
12-Amethyst
February 28, 2013
All this comes back to the perception, true or not, that we the customer cannot trust that PTC's quality controls are sufficient to even apply an MOR update within the same release without some level of testing. Let's see, in recent memory there was that MOR with the family table degrees/radians glitch. Ouch. That would have been horrible in our environment.

The amount of testing required to get to a comfort level is what holds us back. True, if we could take the time and money to better formalize and streamline out test processes, and keep resources handy for performing those tests, we could probably make the process less arduous. However, as we are seeing with an upgrade we are about to make, sometimes problems just are not caught until you hit the right use-case. A company our size has LOTS of use-cases of varying levels of frequency. Unfortunately, sometimes that rarely used use-case can stop production just as surely as the most frequently used one.

I know PTC is making changes and trying to make improvements but not only do those have to be successful, they have to be successful long enough for the user community to gain confidence. Until that happens, we admins owe it to our customers and business to be cautious.
H
HugoHermans12-Amethyst
12-Amethyst
February 28, 2013

We had a slightly different approach, until now. When our VAR said it's safe to go, we went. Indeed, there is some planning, some testing, but not to the extend of a major release. Of course, when we absolutly needed the upgrade, and our VAR hadn't enough experience, we were a little more cautious.
bottom line, that's where the reseller adds his value. He did the upgrade over and over again, for several of his customers, built up experience, so, who am I to think to will do a better job by doing it myself?


Regards, Hugo.


<< ProE WF5 M170 - PDMLink 9.1 M060>>

B
BenLoosli23-Emerald III
23-Emerald III
March 6, 2013
I did not reply to this and I should have when it comes to MORs.

I have a set of test servers that I use for OOTB installs on of a new release to see what it looks like. I did an initial install of 10.0m020 early last year. A few months later I did the upgrade to 10.0m030 and I will admit I was surprised at how easy that went. PTC has worked to make that process run better. Thank you.

However, the reality of it is that we will seldom be doing an upgrade with the same 10.x range. The timing of new 10.x releases and the coordination of Creo builds to match is more along our upgrade path. I suppose if we found a major problem and there was a MOR that fixed it for our 10.x version then an upgrade would be considered.

As you can tell I am behind in upgrades. I installed 9.1m060 the end of February on our production system which had been on 9.0m050 for almost 4 years. I am now trying to get to 10.0m030 as quickly as possible. That is my stopping point because of Wildfire. Then we will look at Creo 2 and after that 10.1 or maybe jump to 10.2. Along the way we want to add Change Management to our PDMLink 10 system.

Thank you,

Ben H. Loosli
USEC, INC.
J
jessh12-Amethyst
12-Amethyst
March 6, 2013
There were a lot of fixes in 10.0 M040, so if you're moving to 10.0 now,
I'd strongly suggest M040.

Show more replies
Terms & ConditionsAccessibility statement