creo 2.0 search path

[TECNICO]

Good evening,
as reported in the presentation section, after several years of wf2 we went to creo 2.0 (a nice jump I would say:biggrin.
we tested creo 2.0 and it seems to be okay except for the excessive slowness (even with the wf2 it gave us boredom) even only to open a new file takes us 55 ''; Since we leave with a new version I ask for advice to the community.
I did some tests on the config.pro and excluding the search path works very fast (of course they fail all assemblies).
I make some premises:
-config and search path are shared folders on the network
- search path has 400 lines
- we cleaned the search path from unused lines
- we "published" every single folder
- we cleaned the trail files
- we have axioms with family table very long both columns and rows (30mb each save)
-We use pcs with 2gb ram and 32bit
-curiousness: I left only 4 lines in the search path (travels of the heavier axieme with equally heavy subaxis) with little results to open a table takes 2'30'' for a new 8'' file.

I was wondering if other forums have the same problem (search path heavy) and if a pdm completely solve these problems.
I hope I've been clear.
Thank you.

 

[Prof.]

the search path of 400 lines is really excessive, I dare say a madness, should only be used for library components used and usable in multiple assemblies related to different orders.
folders must be purged at the end of the project for safety.
trail files are periodically cleaned.
the configuration should be optimized for creo 2 finding the right balance, for example, between graphics quality and performance.
pc with 2gb of ram and 32bit are now obsolete.
pdm definitely helps but not only serves to improve performance. still requires hardware, software and startup investment.
Bye.

 

[TECNICO]

Thank you for the answer.
we have difficulty in decreasing the lines because we have a tide of components that go under various axiemi (along with very long family table).
we tested with a 64 bit and 8gb pc but it hasn't changed virtually anything.
what advice can you give me regarding graphic quality and performance?
last thing: how can we manage heavy family tables that slow regeneration a lot?
Thank you.

 

[nicksoft]

Thank you for the answer.
we have difficulty in decreasing the lines because we have a tide of components that go under various axiemi (along with very long family table).
we tested with a 64 bit and 8gb pc but it hasn't changed virtually anything.
what advice can you give me regarding graphic quality and performance?
last thing: how can we manage heavy family tables that slow regeneration a lot?
Thank you.

another thing that can slow down I create until it blocks is the presence of an uncertified graphics card, check on the ptc site. but if you kept the pcs you had with the wf2 it will probably not be supported. . .

 

[Parametric_Ozzy]

another thing that can slow down I create until it blocks is the presence of an uncertified graphics card, check on the ptc site. but if you kept the pcs you had with the wf2 it will probably not be supported. . .

I agree, indeed more than I would probably certainly say. :wink:

 

[Parametric_Ozzy]

last thing: how can we manage heavy family tables that slow regeneration a lot?
Thank you.

there are the accelerators of variants, something gains but depends on how well these axioms are built and how heavy they are.
a question: if you have so many axioms with family table, probably because you have a management of various configurations right?
greetings

 

[TECNICO]

thanks for the suggestions.
check immediately if the graphics cards are certified.
we have already used the accelerators variants without great success.

a question: if you have so many axioms with family table, probably because you have a management of various configurations right?

we have hundreds

I will explain briefly the structure of our product (the slowest to regenerate): we have a generic set (currently weighs 30mg and will always grow weekly) with about 500 variants, it is composed of other generic assemblies and also by generic parts (all with family table with 200-300 variants) and many components (muply prt) suppressed.
Unfortunately the structure has many gaps having been made again with proe 2001 and we found it already composed so.
what worries me is that we will increase the size of all these files that still make the system very slow to regenerate and open table harvests.
if you have other ideas regarding regeneration or search path structure are welcome:finger:.
Thank you.

 

[Parametric_Ozzy]

I imagined that the accelerators of variants didn't change much considering your structure.
Have you ever heard of option modeler? a new creo extension for product configuration?

 

[TECNICO]

No, I've never heard of this extension.
Now I'll tell you about it.
Can you explain to me briefly what this is about? I guess it's a package to buy.
Thank you.

 

[Parametric_Ozzy]

No, I've never heard of this extension.
Now I'll tell you about it.
Can you explain to me briefly what this is about? I guess it's a package to buy.
Thank you.

yes is a new extension born with creo 2.0.
basically enables you to design modular products:
It was created specifically to try to create configurations of complex assemblies without the help of infinite family table, you create a master set where you have all the possible variants of the product and through graphic options, you create the sub modules also configurable (which can be both parts and assemblings) but with the great advantage not to generate file variants and regenerate them every time, only when you create the desired variant configuration the system validates and recreates the correct
if you also have a pdm under which the distinction passes to the erp then it becomes even more powerful.:finger:

watch this video:
http://www.parametricdesign.com/creo-options-modeler-video/

 

[flyman10]

windchill 10.1 will make you the difference as between the tecnigraph and I create 2.....