1-Visitor

Question

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

Forum|Forum|13 years ago
February 26, 2013
21 replies
4403 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

Other

ZacharyAlexande

1-Visitor

Here is a solution PTC provides:

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

hwientjes

Author

1-Visitor

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

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

davehaigh

13-Aquamarine

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

BrianKrieger

10-Marble

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

12-Amethyst

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

jfrankovich

12-Amethyst

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

12-Amethyst

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

davehaigh

13-Aquamarine

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 III

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.

Show more replies

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.