In a fairly large top assembly, nicely structured into a dozen sub asseblies and totalling almost 10.000 components, we have successfully built an ESR only showing two of these sub assemblies. The general process of creating that simplified representation goes smoothly. However, when we try to save that ESR, it takes Creo about one hour to save the file that turns out to be only 126 kB. The original top assembly file is 12,8 MB.
We have tries the principles of ESR's on really small assemblies to figure out how things worked and were very eager to try it on our large assemblies. The time it takes to save the ESR is similar to working with the originel assembly and doesn't help us forward for this issue. It does allow us to make reps of the top assembly without check-out etc., but it's too slow to be helpful...
Any ideas what is the cause of this ?
By the way, opening that same ESR doesn't seem to be that fast either !
I don't have direct experience with the saving algorithm of an ESR but I will put this forward to see if this is a simple graphics issue.
We have found that saving files with wireframe is a whole lot more efficient than shaded or shaded with LODs. We have also figured out that the graphics settings in your display quality has a lot to do with the size of the saved file. So I am positing that somehow the save process is going through and regenerating the graphics based on your current settings and the config.pro option: save_model_display shaded* (wireframe recommended).
The display quality settings I am refering to are the ones in Options: Model Display and Entity display. These typically only affect the shaded modes when they are saved with the part (which is also default).
Of course, the very use of ESR's may have prompted the default shaded setting. If so, this means you will have longer load times when opening the ESR.
I am very interested in what you find as a solution. Of course, you can also open a case with tech support to see if they can get to the bottom of this faster with a great explanation of what is happening in the background.
I agree that this should be investigated by TS!
And although I also agree that graphics can contribute to a lot of time and disk space being used, the fact that the final file has only 126 kB does not indicate that there should have been much time spent on graphics.
Have you checked, whether the final file is actually working when you retrieve it?
This would exclude the possibility that it is clipped/corrupted and hence the file size is not reflecting the actual amount of work spent on processing the data.
We found that when defining an External Simplified Representation, we aren't supposed to click 'Define' when selecting an initial representation of the assembly we're opening. This caused all submodels to modify, check-out, etc... and probably caused the long waiting times.
We've been familiarizing ourselves a little bit more with ESR's and actually start to get it on track.