Long load times in SW2006

Start by trying Tops suggestions in the thread labled "Tip of the day....."

I found that having incorrect File Locations (under System Options) caused slow loads, also if you have multiple locations selected, it seems to pull from the bottom of the list first. My VAR also said to uncheck "Search file locations for external referencs", seemed to help.

R> Hey

Sounds like your VAR doesn't understand the implications of that switch.

What are you File References set to? There is a long explanation of this in help. Get a cup of coffee and a quiet place and study it.

Ronni:

1. With 20-25 people you should be using a PDM so that you can work locally and control your files. We (10 users) tried working off the network for a while, but found that no matter how you tweak the settings opening over the network always causes a performance hit. At the time we were working with similar sized assemblies with a 1Gbit network. We also found that working locally significantly improved stability and reduced random file/model errors.

1. The difference between load times with the network cable plugged/ unplugged can be explained by your SWKS system settings. If you set your system options to "Search file locations for external references" and then in file locations add your local directory to the "Referenced Documents" list, Solidworks will look for files on the local drive before it checks the network drive. If you turn this off or do not have a local drive listed, Solidworks will look at the internal file references which will probably be the network drive.

Not sure what you mean, the File References point where they should, unchecking that option seemed to make no difference, it always finds the files in assemblies, etc which are scattered throughout the Eng directory...

Reading the Help file makes it sound like it won't know where to look, or even bother to look... but it always loads... I could be ignorant though.

T> Sounds like your VAR doesn't understand the implications of that > switch.

Every assembly has an internal list (references) of all the files it contains and where they are located. By default when you open an assembly it will use this internal list to locate and open any files it contains. If you turn on the search file locations, and specify a referenced documents location, you can override the internal list. For example when we worked off of the network we had the search file locations turned off and all the files opened from the network since that is where all our files were located and all the internal references pointed to the network. When we switched to working locally, we turned on search file locations and specified a folder in our local drive as the referenced documents location. Now whenever an assembly is opened, it looks first in the local folder for the file even though the internal list of references may still be pointing to the network.

The paths given in Tools/Options/File Locations/References take precedence over paths stored in the assembly. For example, if you create a file called P1.sldprt in c:\somedirectory\P1.sldprt and both the check external reference option is checked and Tools/Options/File Locations/References is set to d:\someotherdirectory\ and there is a file called P1.sldprt there, any SW file that is opened that references P1.sldprt will find it in c:\somedirectory\ even if the file was saved to d:\someotherdirectory\ while the assembly was open.

If you have two identical directory structures, one on C:\ and another on D:\ you can control which files an assembly will reference by changing the order of the entries in Tools/Options/File Locations/ References . The first path in the list is searched first. For example the following directory structures exist:

C:\vault\path1 D:\vault\path1

Tools/Options/File Locations/References is set to

C:\ D:\

If an assembly is created at D:\vault\path1 and all the parts are located there SW will still search C:\ on opening the assembly in D: \vault\path1. In fact it will search the whole tree on C:\ before beginning to look in D:\ for the references. This of course can slow things down because SW won't look in the last place the files were saved to till the very end of the search.

You can use a utility like Filemon to watch SW search for files. This may give you some clue as to your problems.

Have tried loading your assemblies light weight? This should reduce your load times. Also, what are your settings for large assemblies? The default is 500 but if it has been changed so it is a number larger than that you may want to try the default setting again.

Hey again, thx for answers.

I have tried all the things you have been suggesting besides using PDM to make it a local load.

I also tried the tip of the day with turning off the QoS.

Loading in lightweight should not be nessesary on such a small assembly, we do use the lightweight on bigger assemblies in order to load them at all (/3gb switch). I am not looking at a solution just to have the assembly on the screen, I need to be able to work on it. Loading in lightweight is jjust postponing my wait-time.

About the reference patchs, it dosnt seem to have any effect if I have the "check external reference" option on or not, or if I set any of the network drives/folders in the list.

Our seller-support said it might have something to do with "mapped drives" - but I tried disconnecting them all and loading it from the source, which also showed no improvement.

I think a good set of IT tools with suitable network & packet tests used to monitor exactly what is happening should be able to track down what it happening which cause this.

I am not involved with networked computers as an "IT guy", but I do listen to what some of these guys talk about, and they can get really detailed on what they track and measure, particularly in today's world of viruses, trojans, worms, and stealth software trying to occasionally send out information.

Bo

The next question is what virus checker is on the server and your workstation and how is it set up?

According to our "IT guy" the virus scan is set not to scan the .sldZZZ files on either the individual computer nor the server.

We are using McAfee.

sld* files are not the only ones you don't want to scan.

Don't scan the files SW created in your Local Settings folder. Don't scan the journal file. Don't scan a bunch of other files SW frequently refers to.

And BTW, in case nobody mentioned it, make sure your journal is being saved locally.

The journal is saved locally.

And the virus-scanner is not excluding special file-types from its scans, its the traffic from the network-drive (where our SW files are) to the computer that is excluded from the scan.

Besides the *.sld* exclusion you will also need to exclude the .dll files from the SW install directory as well as the sld*.exe. Then there are files like swxJRNL.swj file, *.*dot, *.*drt, *.mdb (in the SW install path), *.*lfp, *.ske, *.*tbt and a whole bunch of others.

I'll have to ask if you have used filemon to see which files SW is using and whether your virus checker is looking at them? I'll also have to ask whether you have checked the network speed outside of SW to see what you are getting.

This macro can be run from SW or Excel and will write a big file to a network drive. Watch the speed on your task manager's network monitor. Open your macro editor, past the code below in and hit run after setting a path to a network drive. The macro just writes strings of random numbers to a text file. If you don't get at least 25% utilization you may have a problem with the network.

' Be sure to check (x) MicroSoft Scripting Runtime in TOOLS/REFERENCES in your macro editor before running.

Sub main()

Dim fso As Object Dim mainfolder As Object Dim objFile As Object

strPath = "m:\yournetworkpathhere"

Set fso = CreateObject("Scripting.FileSystemObject")

If Not fso.FolderExists(strPath) Then

MsgBox "Creating " & strPath fso.CreateFolder (strPath)

End If

strFile = strPath & "\" & Format(1000 * Rnd(), "0####.###.txt")

fso.CreateTextFile (strFile)

For i = 0 To 1000 'After each run add a zero to increase length of test

strLine = strLine & 1 / (Rnd(i) * Rnd(i + 1)) If (i / 100 = 1) Then strLine = strLine & Chr(10) & Chr(13) Set objFile = fso.OpenTextFile(strFile, 2, False, 0) Debug.Print Len(strLine) objFile.Write (strLine) objFile.Close Next

End Sub

After trying the network from my machine I got the following results.

Using the macro I use 70% of the network - the "transfer" was very steady I tried copying some files from the same area on the network onto my local drive, where I got an unsteady transfer, useually around 80-85% peaking at 90%. When opening and assembly from SW its an unsteady transfer that goes from 5-15%, and peaks once or twice at 20%

Just discovered they changed the port on the switch, so I only tried it on 100 MBit

Trying it again now on 1 GBit, and the macro runs on ~25% will post the speeds of the 2 other asap

Tried it with a 1GBit now.

Macro: 25% - Peak 30% (steady) Copying files: 30% - Peak 42% (unsteady) Opening files in SW: 1-2% - Peak 2,5% (unsteady)