TW2 Slow refresh + frequent crashing

[Anonymous]

Just in case anyone has some tips or leads:

We've been running TW2 on AC13 Vista/7 on 64bit machines successfully for about 4 months with no dramas other than a spat with a corrupted user account (windows issue).
...until recently. One project (mine) has been getting slower and slower. Also the crash out rate has increased to up to 4 times a day for some users, (some autosave recoveries are no longer re-connectible ...yawn). By slow I mean the refresh rate between every action including pan, takes up to 5 seconds.
The project is entering into documentation now but can not be described as a 'huge' file. The libraries are clean with minimal duplicates - no missing objects.

Have tried the following without great results:
1] Working offline - no difference
2] switching off zone stamps - slight increase in refresh barely noticeable though.
3] switching off door and window tags - no difference
4] Have archived and restored from the archive (under a new name - as we change phase)

The next thing on my list to try is to save out as a pln and re-share but I am definitely running out of ideas.

As part of our documentation we have begun to add our own custom door tags and zone stamps which were written in AC12 - could this be an issue?

Any advice appreciated.

[archigreen]

I used to have the same problems when running both AC12 & AC13 at the same time.
Try to work only on AC13 or only on AC12
This is a library issue.
Good luck

[Anonymous]

-Do you know it is a TW issue? Have you tried saving it as a solo project?
-have you updated to build 3600?
-does the server and your computer have enough space?

HTH

[owen]

We are experiencing the same problems - frequent spinning wheel when panning, crashes (infrequent) and long delays when Receiving Changes.

Our model is quite large polygon-wise but only ~50MB actual file size.

Save back to a solo project and the problems go away.

We are running good hardware (8-Core+ Mac Pros) both for clients and server with latest AC13 build. Upgrading the BIM Server to AC14 does nothing for hosted AC13 projects as only AC14 projects are able to make use of the increased BIM Server RAM.

No solution yet - we are upgrading some of the project files to AC14 this week to test the waters.

cheers,

owen

[matthewjj]

We are having similar troubles with 14 Teamwork projects. Spinning wheel, slow send-receive, slow to open file, some crashing & frequent "offline" messages.

If anyone has info here it would be great. We can't confidently move our whole office to 14 if Teamwork is like this. Oddly, by comparison 13 Teamwork seemed very fast with the same files before migrating to 14. We have ditched all older libraries and embedded parts that could be upgraded to the 14 library.

[monster]

In our company we also have problems with TW in AC14.
Reserving, releasing elements, sending and receiving changes
works so slow which is not acceptable for us.
We had to go back to AC13 which has a lot better performance in TW.

[Anonymous]

Anyari sent me a pm asking about an update on this thread. I think it's worth adding here:

Anyari,

We've had similar problems with other files but not to the same extent as the project referred to in the post. We continue to work on this project and things have improved re refreshing and crashes but it is still temperamental (crashed out twice yesterday). We have learned to work with it. We are still on 13 but will make the jump to 14 shortly. The latest hotfix 3826 has not caused any additional pain ...yet.

So no sliver bullet I'm afraid. Just a list of suspects.
Things we would do differently next time (Suspects implied) -

1) Centre whole project at origin - not where the survey imported to. (AC does not handle large distances from the origin well)
2) Consider not having all drawings in the same file (file size)
3) Watch out for labels that read from objects, eg door labels, slab lables that read finishes etc - we suspect this is adding to refresh times. when we turn their layer off things run faster (we are exploring editing the gdl to put the checking bit in the parameters script - so they do not run at every screen refresh).

Things we do to reduce crashes
a) Send changes rather than send and receive. Receive changes only when you need to. Send changes is faster, we do it often as we can.
b) Only one person is in charge of updating modules - multiple people updating modules at the same time causes crashes we believe.
c) Import dwgs as placed external drawings - less mess to layers and easier to switch on and off (if only xrefs had a master layer like modules).
d) This measure comes with a disclaimer - I do it myself but I do not recommend everyone do it - Disable autosave. Many crashes were happening during an autosave. It also took forever. So I rely on sending my changes and I save when I can accommodate a pause. Downside is when recovering from a crash you generally have to load up the whole project again. But if you've been sending your changes like mad you'll have not lost much.
e) Work with your tags layers switched off - door tags, finishes tags etc - anything which has read information from another element.

hope some of this helps.