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

We are happy to announce the new Windchill Customization board! Learn more.

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

hwientjes
1-Newbie

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

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 21

Here is a solution PTC provides:

“Suggested Techniques for Increasing Performance when Working with Large
Assembly Drawings” at:

Thanks Zack,
But these techniques are already implemented and not changed when we went from WF4 to CREO2. Now in CREO2 actions take much longer compared to WF4 when dealing with large assemblies/drawings (in combination with Windchill).
We could work with WF4 on large assemblies/drawings but in CREO2 it takes too long...
Best regards,
Han
lholmberg
4-Participant
(To:hwientjes)

Is it me or do those suggested techniques seem like a bunch of garbage? Does PTC even use their own sofware? They propose some "great" ideas such as:


Set the line display of all views to Wireframe. Regeneration time will be faster than if the view display is set to Hidden or No Hidden


- That just plain seems idiotic. All it takes is forgetting to set the views back when saving, plotting or checking in.....


Erase views that are not being used when detailing the drawing


- Why would they be there in the first place?


Move completed views to separate sheets of the drawing. The views can be moved back to the original sheet prior to plotting


- Ah more work...there is a reason we purchased a plotter to make C, D and E sized plots.


Use File > Properties > Drawing Models > Add Model to add subassemblies to the drawing. Create views of the subassemblies instead of creating views of simplified representations of the master assembly.


- Why did I bother tyring to save myself work and create a clean easy to use drawing in the first place? Simplified reps are great (especially in a Windchill enviroment where I don't what to check out 10 things to change one) And why would I detail a subassembly in an upper level assemby? That assembly should have it's own drawing. Nevermind the nightmare of trying to create a bill of materails from this.


Create separate drawings whenever possible, as this will prevent Pro/ENGINEER from retrieving unnecessary models into memory.


- But you just recomended to me to use more sheets and add sub assemblies for differant views in an upper level assembly.....?


Use Pro/BATCH so all plotting can be performed outside of Pro/ENGINEER


- How screwed up is your software that you need a seperate program to do printing? If proBatch works so well why don't you build it into Proe and finally make a good drawing tool for your software.


Use the Drawing Representation Tool to remove unnecessary views and to prevent Pro/ENGINEER from retrieving unnecessary models into session


- Again why would I have views in my drawing that I did not want to use?


My recomendation (from a Wildfire perspective..we don't use Creo in our company...yet) is to use Z cliping, and when possible and to make sure that your views do not overlap. Also try turning off your drawing selection tool from


RANT


This is the kind of crap that makes me so frustrated with PTC. They spend all of this time making a new GUI (Ribbons...why?) and they don't bother to fix the one thing I think has been broken with the sofware since I started using it in 2003....Their drawing tools are terrible. They should dedicate a new product release just to fixing that. It needs to be 10 times more user and admin friendly.


Now this is just my opinion but they could learn a thing or two from AutoDesk when it comes to this. Now I am not saying that AutoCAD is perfect but when it comes to setting up standard drawing templates, printing standards and just gerneral printing they are light years ahead of PTC. I should not have to create complex mapkeys so users can print and create files to play with margins and colors/penmaps every time I move to a new version of your software or change a printer/plotter.


END OF RANT



In Reply to Zachary Alexander:


Here is a solution PTC provides:

"Suggested Techniques for Increasing Performance when Working with Large
Assembly Drawings" at:
http://www.ptc.com/cs/cs_25/howto/vew1046/vew1046.htm


Zachary D. Alexander
Systems Manager
ProductSpace Solutions Inc.
Phone: 630-495-2999 Ex. 8104
Cell: 630-460-4905

Logan,
I have to agree with you that the suggestions PTC gives are for the most part pretty ridiculous. No one I know, works like that. Do the techniques work? Yes, but the pain involved typically isn't worth it.

In PTC's defense, I did work at one company that made sheet metal telecom cabinets. Think of the SUV size cabinets you see in the neighborhood. They did that as a single drawing. 20, 30, even more sheets. Every part was detailed on the single drawing. Every component was a dash number of the drawing number. Some of the techniques PTC gives are really more applicable to this type of drawing. However I don't believe this is a widespread practice. Most companies I've seen have a drawing for each part and assembly.

Only making a single drawing for each component you ship out the door, instead of a drawing for each piece part you have to make to assemble that component, was not driven by engineering, it was driven by the document control folks, simply because it made their life easier.

David Haigh

My question, also, is that it seems like some to many questions are related to WC and Pro/E. These are valid (if, at time, ludicrous) suggestions. Where I think a big swath of unanswered questions lies and where a performance throttle is seen is in the interaction side of things. Even if we put all objects of a large assembly in the workspace, Pro/E performance suffers. It appears to be chatty with the server (which, imho should be an absolute "no" for the cad-side of things. Only talk to the server for non-cad work. There should be a cad-only mode. Don't bother me with the constant checking for changes and such while designing in the tool.). When we disconnect the server, Pro/E runs along fairly smoothly.

I know that PTC Inc. was addressing this and put a person in charge of breaking down the "throw it over the wall" mentality between Pro/E groups and Windchill groups. Doesn't appear that they're there just yet.

Personally, I like the tabs and ribbons. I think there are some nice benefits (and Creo2 fixes some/most of the pretty bad implementation of tabs in WF5). I think it's pretty well laid out. That said, I do agree that changes sometimes seem like they're making the deck chairs look really pretty while some of the inner workings look like the Carnival Triumph below deck.

And, to tack onto David's thoughts, when working with questions and issues, the TS method appears to be try this now this now this now this now this now this now this now this now this........... Then, when working with WC, it's collect these 8 logs. Now collect these 2 others.....all added on top of change this now this now this now this now this now this.

And, to be fair, it's a huge system. Folks often use it in ways that don't make sense or are way out of the intended function. And there are some good, smart folks working on it. But too often I feel like I'm paying to beta test software (one of the benefits listed for us paying for tech support was that we had "X" calls answered. So, in essence, a benefit for me is that I paid you for me to identify a bug in your software that you then fixed. It didn't work right to begin with and that's a benefit to me that I should continue to pay for it. Um. OK.). And just because it's big or PTC Inc. didn't think through scenarios isn't an excuse, either. Or, rather, not a good one. Just sayin'.

BK
jessh
5-Regular Member
(To:hwientjes)

On 2/27/2013 10:16 AM, Brian Krieger wrote:
>
> And, to tack onto David's thoughts, when working with questions and
> issues, the TS method appears to be try this now this now this now
> this now this now this now this now this now this........... Then,
> when working with WC, it's collect these 8 logs. Now collect these 2
> others.....all added on top of change this now this now this now this
> now this now this.
>
> And, to be fair, it's a huge system. Folks often use it in ways that
> don't make sense or are way out of the intended function. And there
> are some good, smart folks working on it. But too often I feel like
> I'm paying to beta test software (one of the benefits listed for us
> paying for tech support was that we had "X" calls answered. So, in
> essence, a benefit for me is that I paid you for me to identify a bug
> in your software that you then fixed. It didn't work right to begin
> with and that's a benefit to me that I should continue to pay for it.
> Um. OK.). And just because it's big or PTC Inc. didn't think through
> scenarios isn't an excuse, either. Or, rather, not a good one. Just
> sayin'.
>
One way to avoid some of this is to keep moving to the latest Windchill
MORs as they become available.

If you don't, then you're opting into all the known problems, big and
small, that have already been fixed by a more recent MOR. Yes,
unfortunately, some of these are found by customers. Some are found
internally as well, e.g. upon code inspection when doing work on the
next release. In either case by staying on an old MOR, you're choosing
to suffer from issues that you could easily avoid ever seeing -- and
choosing not to benefit from all the bug fix work that went into the
newer MORs.

When a customer stays on an old MOR, it makes things much harder on TS
and R&D when troubleshooting, as they have to consider all known
problems that have long since been fixed -- and do so with old versions
of the software, old source code, etc, that's less familiar to them than
the latest MOR. This slows down the whole troubleshooting and diagnosis
process.

--
Jess Holle

[As usual, speaking only for myself, not my employer.]

I appreciate that it is better for TS and R&D if customers are on the latest MOR. But this view implies that new MORs only reduce bugs, not introduce new ones.
WC 10.1 M030, for example, introduced 55 high or top severity SPRs. These were not addressed in the subsequent M040 release and the majority of the SPRs have an undetermined resolution release, so as an admin, just moving to the latest MOR isn't always the best advice.

John Frankovich
jessh
5-Regular Member
(To:hwientjes)

It introduced 55 new SPRs? I'm extraordinarily disheartened if this
statistic is accurate -- in which case these should be the source of
some deep root cause analysis as to what's gone awry in our MOR
process. It is impossible to /entirely /rule out any possibility of
harm when making a software change of any substantial complexity, but we
should do a lot better than that. Changes in MORs should be done on an
"above all do no harm" basis -- and not done at all if one cannot reduce
the possibility of harm to insignificance.

All that said, I'm /very /curious how this statistic was arrived at. I
know I often see SPRs filed against a given release level as being "new"
and then my investigation finds that the issue is /much /older.

--
Jess Holle

Are you really sure the new release "introduced" these spr's. Or is this merely the case that the SPR were reported against the new release?

My guess is for the most part the SPR's were there in the earlier release and just reported in the latest release.

I know for a fact that's not always the case. However, I think the SPR numbers you are looking at include both new, and old... newly reported issues. That artificially inflates the number.

With ProE, I've almost never regretted moving to the latest release, despite it looking in the update advisor like there are a huge number of issues. I expect the same is true of Windchill PDMLink.

David Haigh
BenLoosli
23-Emerald II
(To:hwientjes)

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.

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.

We don't live in a dedicated minimal data no production environment. Maybe you PTC guys can do upgrades as soon as a new MOR comes out, but for us it takes coordinated planning.


Thank you,

Ben H. Loosli
USEC, INC.

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

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

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
jessh
5-Regular Member
(To:hwientjes)

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

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
jessh
5-Regular Member
(To:hwientjes)

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).

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.

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>>

BenLoosli
23-Emerald II
(To:hwientjes)

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.
jessh
5-Regular Member
(To:hwientjes)

There were a lot of fixes in 10.0 M040, so if you're moving to 10.0 now,
I'd strongly suggest M040.

I second that. We just went from 10.0 M030 to 10.1 M020 though (with similar fixes). So far 10.1 is a mixed bag though.
Top Tags