The Global ARCHICAD Community

Stay informed. Get help. Share your knowledge.

Discussions about managing ARCHICAD in architectural practices (Project Setup, Templates, Attributes, Migration, Compatibility with Previous Versions, Preferences/Work Environment, User/Project/Application Administration/Management etc.)

Moderators: Karl Ottenstein, LaszloNagy, ejrolon, Barry Kelly, gkmethy

#299010
Even though there are many discussion and posts about layouts and efficient workflows, I thought I’d share with you my own experience with a special topic: how to handle layouts and publishing in very big projects.

It is actually nothing that I have discovered, but the need for an efficient workflow in our office brought me to many spent hours in experimenting, consulting others and putting all possible information in one place. The reason why I took this journey is because our publishing process of over 100 plans into PDF and DWG took more than 2 hours. This is too much and is even worse since for a period of 1 hour none of the 9 team members could work in Teamwork (I will explain later why). Therefore, the experiments reduced the publishing time of the same plans down to 30min. It is still a lot but, that’s the maximum I could squeeze. This “slow” case that I am describing you here is the scenario where drawings are placed as views in the same file and updated automatically.

One of the problems with big projects, especially in construction phase, is the updating process of those plentiful drawings in layouts. Some layouts in our case have 4 drawings and some even 12. Some representing floor plans and some section or even elevations and also a combination of all mentioned. Every time you open a layout, the updating process of those specific drawings will begin. In total to update all drawings for all layouts took us around 1h. After this process, we could start publishing PDF and DWG which took another 1h. The PDF was not so painful as publishing DWG. And the reason why nobody could work for this 1h in Teamwork is because the moment someone drew something, the layout saw this as a change, hence wanting to update again, and again, and again... To publish a DWG is more delicate case then a PDF, because everything must be up to date and correct, otherwise you get errors.

For the solution I took something that I hadn’t worked for at least 10 years. The famous PMK file. This is why I am saying that I did not discover nothing new here, because the Plott Maker strategy was introduced by Graphisoft more then 10 years ago. The plotmaker was discontinued but the PMK format stayed though.
Our strategy was to publish VIEWS from the model files (since the project is big, we have 5 teamwork files) as a PMK and store them at our local server. These views will have their corresponding place in an external layout file that was dedicated only for publishing. This allows fast opening of layouts and a very fast possibility to update them. Compared to a normal updating process which took around 1min per layout, updating from PMK is a matter of 3 seconds and sometimes even milliseconds. With the help of the drawing manager you are able to update, control and correct drawings also in a matter of a few seconds. All PMKs are stored at a single folder (a pool) where these documents are going to be overwritten when the publishing time arrives, hence updated in the layout file. File size of a PMK ranges in kB with rare occasions up to 2Mb. The drawings in the layout could be left to “automatic update” since I could not see any rise in file size when switching to manual update (save in project). But for management reasons I left this option to manual, for the users to have better control when updating plans.

Another cool advantage is the change manager which also works in PMK. All changes, respectively change clouds, are saved in the PMK and correctly read and documented by the Index-Table in the Layout file. The only disadvantage of the change manager and separate layout file is the backward synchronization to the main file, which changes have been published or are closed. There are some workarounds for this (I can explain if someone is interested).

In addition, all possible auto texts and especially the ones referencing to drawings are displayed correctly. Scale of the drawing is also correct. No information is missing or displayed wrong… so far.

In the end I also tested a disaster scenario where we lose connection to our server, meaning the link between the PMK file and drawing is lost. It might look like a moment to panic, but the program is capable to reestablish the connection within a matter of seconds, hence again all drawings up to date.

I hope with this “short” resume I could explain and give some hints for those struggling with this matter. Feel free to comment or even give hints
#300190
Hi Agron,

you told about backward synchronization to the main file, which changes have been published or are closed and that there are some workarounds for this. We are working on a large social housing project and I would be keen on your further experience about this...

Cheers
Szab from Germany
#300779
sab wrote:
Sat Aug 03, 2019 1:48 pm
you told about backward synchronization to the main file, which changes have been published or are closed and that there are some workarounds for this. We are working on a large social housing project and I would be keen on your further experience about this...
Hi,

The problem with Change Management ist that all changes documented in the main file, cannot be marked in the part files. In this case the program does not send a "Signal" from the main file where the LayoutBook has been closed to the part files.
Our current workaround is to mark changes in the part files; synchronize them to the main file where they are going to be closed. At this moment we immediately publish plans as PDF and in the part files all changes are going to be moved to another layer so the don't bother the users.
If you follow the steps there, it works well...

regards
#301087
Another thing that smoothes the process of getting a deliverables out is to have a separate unmanned computer on hand. Use it to open the Teamwork Project with the Layouts, reserve them all, and use the Drawing Manager to constantly update (after setting all Drawings to Manual Update). Waiting around for a sheet to regenerate when you have real work to do is demoralizing and counterproductive.

Funny you should mention PlotMaker. This was a workflow I used to use with that program long ago, which was nice because PlotMaker did not require a license key. In your case, you will need a separate license. However, the cost for having another computer and license is probably less than the time lost waiting for updates. A good machine is $3000 (replace every 4 years or so), an AC license is $5000 + $500/year (less than $2000/year over a decade), and this should be insignificant as large projects like this should be raking in hundreds of thousands, if not millions, in profit. Just good business.
#304472
Hi,

I hope is not too late to come back to this post but I have a question regarding the PMK workflow and I would appreciate your feedback.

We have a dedicated machine exclusive for the BIMcloud. All information regarding non teamwork projets and all the publish files from temwork projets are stored in another machine. We are now starting to implement the separate file workflow for layout only with pmk's for large teamwork projets.
The question is: should we publish the pmk files into the machine where bimcloud is running or into our regular server? I am aware that both ways works but is there a clear advantage for publishing to one machine or another? Speed? file path issues? etc..?

thank you.