Using Teamwork as a standard practice.

[Anonymous]

We have decided to begin using teamwork as a standard practice on ALL projects. This decision has been based on the tremendous performance improvements I have seen in AC 8.1. There are now no significant delays in signing in, changing workspace, sending and receiving, etc. compared to opening and saving a solo project. The only added overhead is (obviously) the requirement to define the workspace.

The advantages we see are greater security against data loss (multiple backups & local drafts) and more administrative control of standards (having to sign in with with exclusive access to change attributes.

I am posting this both to provoke feedback and discussion as well as to promote the idea to others and respond to any questions people might have.

Any takers?

[__archiben]

Ted wrote:
Maybe a step-by-step of sign-in, save PLC (local or net), draft, send/receive, draft, etceteras, etceteras would help me get my workflow thinking in line with yours. We have eight users and the majority of our projects are shared, so any gains are really very helpful.

ted

in our setup we have the libraries required located on a server in 2 'tiers':
1 archiCAD library + office library
2 a folder full of job specific libraries

when sharing the project, the team leader/administrator sets up the file to point to these server libraries. next, a team leader/team mate signs in, loading the default libraries for the project from the server, as set at the point the project is shared.

once signed in and the draft saved, the team mate then uses 'library manager' to enable library caching, see attached screenshot. (i know that it is supposedly possible to enable cache libraries using the sign-in dialogue box at the point of signing in, but i have had mixed results using that and prefer to do it manually this way.)

if you haven't previously created a cache library for that user/machine, archiCAD will ask if you want to create the folder. click yes.

what happens now is that archiCAD copies the contents of the libraries into a folder in the home users directory:
<machine name>/<users name>/Library/Caches/Graphisoft/Local Cache Library/<yourlibraries>

i can't remember if archiCAD copies them immediately or if it happens at the next send and receive . . .

the location of the cache library is then saved in the teamwork draft preference file,
<machine name>/<users name>/Preferences/Graphisoft/AC 8.1.0 v1/<username filename.PREFS>
so if you work on more than 1 draft file, the cache libraries need to be set up individually for each project file in order for the preferences to be saved - BUT archiCAD won't create duplicates of libraries in the cache if a library has already been cached for another project.

every time archiCAD opens that teamwork draft, or signs into that teamwork file, or the user sends changes, archiCAD looks at the server libraries, compares them with the local cache, updates if necessary and then loads up the local cache copy. this has cut library load times down from about 2 minutes to 15 seconds here. i'm guessing that it uses the "LibraryEnumerationCache.dat" files in the libraries as a way of synchronising much in the same way as basic backup software.

users must understand, however, that for all intents and purposes they are using the libraries from the server: they must let archiCAD handle the cache side of things under the hood. in this way if somebody updates a library part, the update is firstly synchronised to the server as a part of the send and receive process. other users caches are updated when they next receive changes.

because of this, the library manager dialogue box pops up more often than usual (and more than necessary IMHO!). simply clicking 'done' suffices to clear it.

FYI we're using G4s (mirrored drives) and a G5 (all OSX 10.3.2), a 100baseT network switch, and an Xserve running OSX server 10.2.8.

hope this helps!
~/archiben

[__archiben]

Weston wrote:
A far better solution would be for AC to store a setting that tries the local drive for libraries first, or use a wildcard name at the root directory level. The only library we need to access locally is the AC standard one - project and office std libraries are small enough that network loads are reasonable.

this is what i would refer to as a relative directory path. i.e. the dots and tildes in standard file path naming are filled in by the computer relative to itself. apple recommend that no hard-coded file paths are written in anyway!

e.g.:
MyFunkyLaptop/Applications/ArchiCAD 8.1 folder/ArchiCAD Library 8.1
becomes:
./Applications/ArchiCAD 8.1 folder/ArchiCAD Library 8.1 where the first dot is replaced by the hard drive name. if the second example is written into the file, it doesn't matter which computer is used to open the file - it will always look locally rather than try and connect to "MyFunkyLaptop"

seems like common sense to me to implement this for something like the archiCAD library, but then i'm not a programmer and there may well be a whole bunch of other stuff that makes this impossible!

~/archiben

PS - we're going a bit off topic here. (sorry matthew).

[Anonymous]

Our firm is new to using ArchiCad and teamwork, but we have been giving it our best. We have some current troubles. Our first trouble is the issue of not bumping elbows while one person is doing plan work while another is doing elevation or wall section work and everyone needing to edit others workspace. this seems like a fundlemental issue that should be resolvable, but it is harder on smaller projects. I am a component to hold out on the Solo side of things for as long as possible.

The other trouble are Library issues with plotmaker. we understand the necessity for anyone who goes into the teamwork file as a leader needs to practice safe library management so members will not have issues later. we also have mixed platforms and have had to make the PC's ArchiCad Library named like the Mac's Libraries "ArchiCad Library 9" I believe. but half the time, in a plotmaker update, some basic libraries will be missing. We find success more often when an update has happened on a Mac after a Mac user was the team leader. Same as the PC.

any comment?

[TomWaltz]

The question of division of labor is a pretty common one.

The best answer I know of requires a change in thinking to more "building" and less "drafting."

What I did here (after a really long time of people resisting) was convince people to divide work by AREA not by DRAWING. That mean some people working on the exterior (with coinciding layers) and some people working on interiors (with coinciding layers). The real key was having the layers needed to divide up the model.

Once the model layers were divided, the teams evolved into two groups: modelers and annotators.

The modelers were usually the more experienced people on the team who built all the walls, trim, roofs, fixtures, etc, working mostly in the plan and 3D windows.

The annotators were the less experienced (or less CAD literate) staff who worked almost exclusively in elevation/section and detail views with no model layers signed out. They were completely out of the modeler's way, and could note, dimension, and crosshatch as needed.

Most importantly, it cut the number of "change workspaces" dramatically.

It's not ideal, but given the limitations of Teamwork seems to work well for us. We've had as many as 9 people in a project (14-story apartment building) using this method without too many headaches. Most of the problems were performance related to the file size (about 180 MB).

As for the libraries, I cannot say. I'm still an old school "publish to PMK" holdout for the time being 😉

[Anonymous]

Tom,

thank you for your advise. The building (model) over drafting is a hot topic at our office right now (all the time).

I am in the 'more model' camp as we argue. but your comments cause me to think about the balance of productivity you came up with by assigning qualified users 'to model' verses 'to annotate'. Right now since most people are new to the CAD, we have been cross training ourselves. this a natural response to learning the software I think.

[TomWaltz]

I think the evolution of our process came from having 6 to 9 people on a project at once.

On smaller jobs, it tends to be a simpler grouping, with one or two people on interiors and another on exteriors.

Also, if a project uses modules/hotlinks, another person can work on that in a completely separate file.

All that said, I think Teamwork is in need of a major overhaul.

[Anonymous]

I have an interesting dilemma....

We have 6 Macs in the office, we have a network, but no dedicated server. All machines have archicad installed with their own wibu keys etc. I understand that we can still use teamwork as long as all the computers can talk to each other.

The problem!

Everytime we send a file over the network to another machine the Mac os operating system locks the file, we tried the team work option but it kept telling us it could not access the file because it was locked (even though it was not locked on the persons machine the file was) our tech guys don't have too much knowledge on the Mac OS does anyone have any ideas or suggestions?

[TomWaltz]

Sounds to me like a umask problem. OS X makes all files locked by the owner so others cannot edit them.

I forget the exact terminal command, but I'm hoping your sysAdmins know enough Unix to fix a umask problem. If not, it may be time to find some new ones or get these ones some training.

[Anonymous]

Being a small company of only 3 architects and 3 technicians, we have no such thing, I try and sort out any problems that occur, but I really only have a PC background so Unix is new to me, I will however look this up in a few knowledgebases. Training unfortunately is nill as we are too busy and don't have the money for these courses. Its a catch 22 situation that alot of very small companies in the UK are in at the moment, you have to do your bread and butter work for pittance and hope something descent comes along. The director is even working on jobs on cad. For a small business there is no such thing as an IT sys manager, there isn't the budget to hire one or the time to train one of us up to be one. I am lucky that I have a basic understanding of how a computer works and a good sense of fault finding, but unfortunately not even our Cad suppliers / technical support can help us as you say a unix problem and they don't have an extensive knowledge of the OS.

[Thomas Holm]

OK. We're smaller than that. And have no IT techs.
But it's possible to manage.
You should set up a central storage area on ONE machine, preferably one that is NOT used as a workstation, even if that can work too (we do it but it requires more knowledge and work. Note that a 5 year old Dual Mac like the 533MHz I'm sitting on works fine - it has Gigabit ethernet. And you can get such a machine cheap. Install 2 new identical internal hard disks and set up SuperDuper http://www.shirt-pocket.com/ for regular mirror backup.)

Set up a shared data folder on that machine. Best is to install MacOSX Server on it, but if you want do do it cheap, you can use Sharepoints
http://www.hornware.com/sharepoints/ like we do (but it requires more knowledge and work).

You should also set up a shared library folder, of course.
Then let everybody copy their projects to project folders within the shared data folder on that machine.
Regularly run BatChmod http://macchampion.com/arbysoft/ and
set it up to allow all users read, write and change access, but NOT change owners, and check 'unlock' and 'all included files and folders' as well.

For extra safety, regularly back up the shared data folder to one or more external Firewire drives, using for example Silverkeeper http://www.silverkeeper.com Keep these drives locked up in different fire-proof storages separate from the office.

No Unixish required!