Layouts – Troubleshooting Guide

by GRAPHISOFT and Katalin Borszéki · updated: 09.25.2013 · RefID: 148211

Rotated layout and section upon opening

Issue

Upon opening the project full layouts and sections are rotated. The angle of rotation is consistently the same on all sheets. The rotation includes the titleblock of the page.

rotated

Cause

Bug in connection with rotated origins.

Workaround

  • After closing and opening the project the rotated layouts often right themselves.
  • Until the problem is fixed avoid the use of rotated origins when possible.

{i} Note: This issue was fixed in the hotfixes of ArchiCAD 16 and ArchiCAD 17.

Drawing Does Not Update

Issue

Possible areas where drawing update might not work as expected:

  • Update All does not update all of the drawings
  • Users with up to date copies could see different versions of a drawing
  • Drawing update with project separated into model and layout
    • Long delays when swicthing between instances
    • Layout update refuses to run even after model instance sends and receives

Cause

Update All

Prior to ArchiCAD 16 a teamwork user could select all of the drawings in the drawing manager and the Update Drawings icon would become active.

UpdateAvailable80.png

The drawing manager gave the appearance it would update the selected drawings, but the update was not guaranteed. If a drawing was not reserved it would not be updated even if it was available.

Users with up to date copies could see different versions of a drawing

Prior to ArchiCAD 16 two teamwork users could see different variants of the same drawing even after each had freshly sent&received and updated the drawing. This could lead to old versions being published as if they were new. The nature of this problem was complex, which is why it rarely was experienced. The important settings are shown in the below slide:

DrawingSelectionSettings80.png

In words:

  1. A teamwork user saved a drawing on their local machine – not in a folder publically available to all teamwork users of the project.
  2. The Update type was set to Auto, which meant ArchiCAD could present the most up to date version of the drawing to the user who could access the source –in this case only one user.
  3. The user thought the source was irrelevant to the other teammates, since the drawing was stored in the project file. The user expected that changes to the source would be shared with others with a send&receive.

The expectation was wrong. Only changes to reserved items could be sent to the server. This rule continues to be in place. When the user originally placed the drawing it was reserved automatically as part of the placing process. When the user sent and received for the first time the drawing was stored in the project. The confusion and problem started when the user released the drawing and at a later time replaced the source with perhaps an updated source from an outside consultant. From that point on the user who could access the source data would see the fresh version, because the Update type was Auto.

Other users at this time saw old data until the user with access to the drawing source reserved the drawing and sent and received. Reservation here is the key concept. Update followed by send&receive for versions earlier than ArchiCAD 16 would not guarantee change to the data stored on the server. Since reservation was not guaranteed, other teammates could see drawings that were not current even though they performed actions that would give them the expectation of currency. In ArchiCAD 16 the update is not allowed until the drawing is reserved thereby guaranteeing that other teammates will see the same version of the drawing source when their send&receive is current.

Drawing update with project separated into model and layout

A common workflow for large architectural jobs is to separate the model from the layout into two or more teamwork projects. In this workflow a user working on documentation will typically have the model and the layout projects open in separate ArchiCAD instances.

When the user switches between ArchiCAD instances or another program and then back to the layout instance an update check will take place for drawings set to Auto update. Larger projects will take longer for this check to take place and the non-responsive nature of ArchiCAD could be annoying.

Additionally, updates in the layout instance might be blocked by falsely concluding that the project instance should send&receive. This state sometimes is not resolved by the the project instance sending and receiving.

Solution

Drawings that ArchiCAD 16 cannot update it lists in a warning dialog similar to the one below.

DrawingsCannotBeUpdated80.png

To avoid the annoyance of check status followed by Auto updates when switching between applications many users are willing to forgo the automation and rely on manually checking the status of their drawings with either the check status button in the drawing manager, or just simply updating the drawing. If this is the case for you, there are registry settings that can optimize the teamwork experience. See the below example:

TeamworkOptimizationforDrawingManager80.png

{i} The above example is for an Australian localization of ArchiCAD 15. Solo users will most likely prefer to keep the defaults and leave this set of keys alone.

The registry settings to CheckStatusWhenAppActivatedCheckStatusWhenWindowActivatedStatus refresh delayStatus refresh frquency, in the above example turn off the status checking and makes sure that the status refresh will not kick in under any circumstances.

The IgnoreUnsentChanges key is special. This key can solve the problem when ArchiCAD falsely concludes that the local copy is out of date when a layout and model instances are open with the same architectural job. In this case the two available options are either to close the model instance or set in the registry the IgnoreUnsentChanges to 1. If you set IgnoreUnsentChanges to 1 the up to date check will be disabled leaving the responsibility of currency of the project to the user. Most teamwork users prefer to accept the responsibility of currency, so setting this key is not a problem. If you believe you or your users will not insure that the local copy is current by a send&receive before updating the layout you should leave this key set to 0.

Related content