File Size?

[dtharrett]

We are running NX 7.5 with TC 8.0

I have a large assembly consisting of many sub-assemblies, that seems to be running really slow. I suspect one of the sub-assemblies might be causing the issue.

Assuming file size is a good measure of sub-assembly workability, is there a way to view the file size of each sub-assembly or part in either NX or TC?

Are there any other good measures of file worability ie when a file reaches X unit or an assembly reaches X units it is considered "large"?

Thanks

 

[looslib]

File size itself will not dictate performance. Both hardware and file have an impact.
Graphics card performance issues are ususally manifested when rotating your assembly with the mouse or spaceball.
File issues will manifest when loading the file into memory. Also, the types of surfaces and their complexity will show up performance issues.

You didn't say what your hardware is and that may help with determining a solution. Graphics card, memory, OS all play a factor. With any Wintel computer, I recommend a daily reboot.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[dtharrett]

looslib,
Here is what I am running:
Dell Precision M4500
Intel i7 CPU
8GB memory (32bit)
Quarto FX8800M Grafics Card
I currently have the 3GB switch enabled

I am told we are a long way off from going to 64bit.

The problem I have with this particular assembly at the moment is actually loading it into memory. I can load structure only with no problems and then "turn on" certain sub-assemblies. Any one sub-assembly gives me no issues so the problem seems to be cummlative.

If I could see what which sub-assemblies where the heavy hitters, perhapse I could drill down and modify some parts to make things more manageable.

For what it's worth, we use very little surfacing, lots of constraints and some arrangements. At the moment, it is unclear to me what effect lots of constrains & arragements have on assembly size/workability etc.

 

[MickyV007]

Try loading no structure and use the lightweight representation for every subassy and see of it makes any difference if you turn them on one by one.

Best regards,

Michaël.

NX7.5.4.4 + TC Unified 8.3

 

[looslib]

Michael's suggestion is a way to start.
If you don't have or plan on going to 64-bit, you wasted money on 4GB of memory. From what you said, 64-bit, either XP or Win7, would help.
Use Task Manager to monitor the memory as you load your sub-assemblies.
Turn off hardware items that may be in your assemblies until you need to show them for placement or drafting. Either isolate them by layer or arrangement(s). (Reference sets in older days)


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[MickyV007]

Something else came across my mind, how about your network? I read in your first post you are working with TC. Do you have a good network connection, is your workstation connected to a hub/switch where also other users are claiming bandwidth. Where is your TC server located, on site or maybe in a service-center far far away. This could really mess up the loading and saving times due to latency.

Best regards,

Michaël.

NX7.5.4.4 + TC Unified 8.3

 

[dtharrett]

Our TC server is located on site, according to windows I am rnning at 1Gbps. The company plan is to move to 64bit eventually (hence the extra memory) but the move will be slow.

What is odd here is that I have been successfull working on other seemingly large assemblies. I am just trying to quantify how large this assembly is comapred to others hense the original question regarding file size or some other measure.

Loading lighweight did not seem to make a difference but I did not see an option for "no structure" as suggested above so maybe I did something wrong.

 

[JohnRBaker]

Also make sure that 'Partial Loading' is set in Load Options.

John R. Baker, P.E.
Product 'Evangelist'
Product Design Solutions
Siemens PLM Software Inc.
Industry Sector
Cypress, CA

http://www.siemens.com/plm

http://www.plmworld.com/museum/

To an Engineer, the glass is twice as big as it needs to be.

 

[Toost]

Do you have the 3Gb switch set ?
It is "vital" when running 32bit and large assemblies.
It allows the NX process to become/ use 3Gb RAM instead of the default 2Gb.
you can check in the NX logfile under Help - NX logfile
If it reads "Machine supports 3G address space", some 15 lines from the start then it is set.
Else, You should set it, but i cannot advice on how.

 

[dtharrett]

Yes, partial loading and the 3GB switch both set. So is file size a poor indicator or is it impossible to view?

 

[Toost]

I guess that file size is one of the major keys, it is directly correlated to model complexity but when running under Teamcenter it is "tricky" to see, one can ( to my knowledge) only read the size of one part at a time, and you are working a large assembly...
If you select the NX "dataset" in teamcenter navigator - RMB - Named References a dialog will open where the actual part is listed along with a number of other related files. It will also list the file size, but as said only for the selected one. ( The assembly part should normally be very small if no geometry exists in it.)
You could look at the windows process "ugraf.exe" and see how much memory it uses in Windows Task manager, but that also is a crude tool, NX historywise has been bad at "returning memory", - which i hope is fixed in current releases. In say NX2 the ugraf.exe kept growing in size no matter if all parts was closed, and the only solution was to restart the NX session.
"No Structure" mentioned by Micky is probably a typo , I guess that he means "Structure only".

 

[looslib]

Not quite right on the /3GB switch. In theory that is what you are telling the system to allow. In practice, a 4GB system without the /3Gb switch set will crash the ugraf process when it hits about 1.43GB of memory. With the switch, ugraf won't crash until about 1.87GB of memory. On a 32-bit system one application can never address more than 2GB of memory.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[DaSalo]

This from the Microsoft website:

The /3GB switch allocates 3 GB of virtual address space to an application that uses IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header. This switch allows applications to address 1 GB of additional virtual address space above 2 GB.

looslib: I'm not sure if this contradicts what you are saying or not. Are you talking about two different things? I.e. there is now a total of 3gb available to ALL running applications but no ONE application can actually use all of it?

 

[looslib]

Right, I have NEVER seen any application use 2GB of memeory in the task manager before crashing and I tried to see what the limits were a number if times. One application is limited to 2GB of memory and crashes at about the points I listed.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli