Opening Linked Models for Editing

NOTE: This is a re-post from the HOK BIM Solutions blog

One of Revit’s annoyances is the inability to open a linked model for editing and keeping it loaded in the host project, all at the same time. This leads users to believe they need additional sessions of Revit in order to refer to the fully aggregated model and edit the link/s at the same. Doing so causes various problems, such as reducing available RAM consumed by the additional sessions (0.35 to 0.4GB/session observed) and the potential to run out of network licenses for other users.

Revit’s UI gives us the option to open a link but at the same time, forces us to unload it. Somehow Revit seems incapable of having the same file in memory (based on filename) both as a link and opened independently in the same session. To make matters worse, most of our linked models are workshared, so opening a link in the way shown above is highly discouraged as you would be directly opening the central file. Revit does have safeguards for situations like this and does not let you directly do a Sync with Central if another user has synced since you opened the central file. Regardless, the current workflow of dealing with linked models is highly problematic and not sufficiently well-developed by the Factory.

Luckily we can work around the current limitations when the linked files needed for editing are workshared. We can in fact achieve this in the same session without unloading or requiring the user to open a separate Revit session by following these simple steps:

1. Make sure to not use the right-click option shown above (obviously!)

2. Navigate to the original linked central file and open through Revit’s Open dialog in the same session. If it is a valid Central File, Revit will automatically create a Local File by appending your username to it and happily open it for editing.

3. Alternatively, use the Revit Launcher (an HOK custom tool) to create a Local File for the linked model in question and open as usual.

NOTE: If the link to be edited is not workshared, you are out of luck and need to open it in a separate session if it is important to you to keep it loaded in the aggregated model.

Commentary

There is no doubt that this functionality needs to be polished further. The current implementation might be a reflection of various technical reasons/limitations, but should not be a reason to leave things in their current state. Here are some thoughts:

• Revit should be capable of opening non-workshared links directly and leave them loaded in the aggregated (host) model.
• If the link is workshared, Revit should recognize this and serve a UI that offers the same options when selecting a workshared file in the Open dialog so we can 1) open a detached copy, 2) create and open a local file so we can make changes and sync them with central (default), and 3) offer the option to open the central file directly.
• Give users the ability to edit a link in-context (in-place), whether it is workshared or not. This is not necessary functionality, but would be very nice to have.

Opening Linked Models for Editing

Pesky filters

Recently I’ve come across an issue on various project files and have been unable to pinpoint a cause or figure out how to reproduce the problem on demand.

Basically in a workset enabled project, there are times when during a synchronization with the central file, filters get renamed and a number gets appended at the end. So Filtername becomes Filtername1. The requirement seems to be that there is more than one person working on the project and that the renamed filters are being used in some views where multiple users are making changes. If only one person is working in their local and synchronizing regularly, renaming does not occur.

A peculiar thing that happens in this case is that Revit issues the familiar yellow warning dialog while saving but this message is actually blank and goes away on its own almost instantly. Also, nothing is captured in the journal, which makes troubleshooting really difficult. This was filed with Autodesk Support but due to the difficulty in tracing the root cause, not much can be done about it.

If you have experienced this problem or have managed to put your finger on the cause, please send a comment or email me. Maybe we can provide enough data to uncover the culprit.

Pesky filters

Salvaging your work

When working with Central files, there’s a common mistake that users can commit which could result in loss of work. Understanding exactly what is happening is of paramount importance and can be the difference between a few minutes of lost work or a few hours.

Saving your work needs to become a natural habit. Lots don’t and then despair when a computer crashes. In most applications, using the keystrokes Ctrl + S saves your active document. However if working on a workset-enabled (workshared) project, only your local is being saved. That’s not so bad, but if you habitually use a scripted solution to create locals or use Revit’s Open dialog to point to a Central file, you can end up losing work in case of a crash.

With a scripted solution, if you run a shortcut to create and open a local file (such as in my previous post), you need to be careful in case of a crash. Let’s say you worked for 4 hours and saved your local 10 minutes ago. Over the last 4 hours you did not synchronize with the central file. So if you crash and run the shortcut as you’re accustomed to, you’ll end up with a new local that has 4 hours of “lost” work. You really need to just open the current local file instead and then synchronize as usual, losing only 10 minutes of work since the last local save. If you encounter a user that ran the script multiple times (happened this week!), then you’ll need to go to the Recycle Bin to retrieve the local with the most info. in it. Check the time saved and the file size.

Even more scary, if you use Revit’s solution, select the Central file (“Create Local” is automatically checked) and you overwrite your local when prompted…well, tough luck! You just erased 3 hours 50 minutes of work. There’s really no fool-proof way to prevent this: you still have to develop a basic understanding of the mechanics of working with workset-enabled projects.

Salvaging your work

Streamlining Local File Creation – GUI (v5)

With the launch of Revit 2011, I finally completed the application I started and stopped back in January 2009 when Revit 2010 was still in Beta. I wasn’t sure this approach still had value due to Revit’s new native ability to create local files directly from the Open dialog. Having had a very busy couple of months following the release of Revit 2010 and after some changes in my workplace, this fell on the sidelines. Believing that this was still the most efficient way to work in workshared projects, it was time to Git-R-Done!

The application was mostly re-written to incorporate a GUI option. I have always favored the shortcut approach because it is a much faster way of working with local files as compared to navigating to your project folder every day. Adding a sidebar link to the Open dialog works quite fast in addition to Revit’s functionality of automatically creating a local file, however depending on the method used to add such link, naming it is a whole other issue! Not to mention the inability to organize locals into different project folders and doing other types of checks in the process.

The drawback of the previous app. was decentralization and the fact that you had to manually create a shortcut, remember how to do “switches” for different options, etc. So the new version takes all that out of the equation. The new version is meant to be located in one place: on the network or your local drive with a shortcut to the executable on your PC. You simply navigate to find your Central File folder and then right-click on a Central file to pick one of three options (or double-click to launch the default). Most settings have been pulled out of the script and into settings.ini, such as default options, links and paths. The app. automatically creates the desktop shortcut for the project and option chosen (you can uncheck the option to create the shortcut if desired). Next time you will be able to launch this shortcut to perform the same actions without the GUI.

The launcher has been tested on Vista Enterprise (x64) and Windows 7 (x64), but should also function properly on XP. It works with Revit 2009, 2010 and 2011. If you’re still on 2008 you’re nuts, but you should be able to use this app. anyway!

The other notable enhancement is Build Checking. Now only the machines with builds older than the project’s build will be warned and once they are upgraded, the message goes away automatically. This data is written in projects.ini which is created either in each central file folder or a centralized location of your choice. Here’s an example warning (not the final 2011 builds):

 

So just click on the image below to download it from the AUGI forum post (free membership required). Feel free to add comments to this post or to the Documentation page and hope you find it useful!

Special thanks go to David Kingham and James Vandezande for openly sharing their AHK scripts, solutions and ideas!

Streamlining Local File Creation – GUI (v5)

Visibility mystery

Picture this…you have a Site project linked into an Architectural project. You go to a 3D view and nothing from the site file shows up. The treasure hunt begins.

It could be as easy as the workset assigned to the Site link being turned off. Or the link being turned off in the view. Or all the object categories that exist in the Site project file being turned off in the host view. Or having the link visibility being set to “custom” and all categories being turned off. Or the link being overridden in the view and turned off (yikes!). Or a filter’s visibility being unchecked. Or a particular workset in the Site project was closed when initially linking it in. Or a hidden section box was clipping the site project elements out of the view. Phew, I’m out of breath!
However, there is a condition where none of the above are the cause of the problem and could leave you scratching your head for some time. It’s a condition that exposes another little Revit shortfall which makes us beg for even more visibility control.
The problem is a workset in the Site project file that is set to not be visible by default in all views. In this particular case, the users were able to see the information in a plan view set to “By Linked View”, but in 3D views the Site project was invisible. It turns out that all site elements were on one workset set to not be visible by default. We don’t have control over the visibility of worksets in linked files and I think we really need to. The fix was to create a new workset that is visible by default in all views, delete the offending workset and move all objects to the new workset, and then rename it back to what the original one was. Mystery solved!

EDIT:  As of Revit 2011, we now have control over the visibility of worksets in linked files. Thanks Factory!

Visibility mystery

Streamlining Local File Creation – update (x64) v4

Hi all, please accept my apologies for not posting much lately. I’m currently on an “expedition” in Eastern Europe and spend most of my free time blogging about that instead of Revit! I’m sure you’re smart enough to find it if you want to know more ;) I’ll hopefully be able to return to the usual weekly schedule in July/August.

Anyway, I’ve completed the update of the Local File Creation script a month ago and forgot to post about it here. So this will be an easy post for me! With the new functionality built into Revit 2010, there’s less need for such a script. However we still intend to keep on using it as we have other functionality built-in which doesn’t exist in the Autodesk solution. So this is tailored specifically to our needs.

In the future I will be making changes to this script to include a GUI option and have the application make desktop shortcuts automatically. The application will also be centralized (either on a network or local drive…your choice). This means that you won’t need to keep placing a copy of the exe file in each project folder like you do now. This will make updating the app much easier. But that will be released later and most of the functionality will be very similar to the current version. These are the main updates:

1. Compatible with 2010 (32 & 64 bit) and works all the way to 2009 (32 & 64 bit) and 2008.
2. Adjusted some of the logic so now when creating a Detached copy, the Central is not copied to the C drive. You can also create a detached copy of a project while a local file for the same project is still running. This wasn't possible before.
3. The script ends properly and the splashscreen should not persist after it finishes. Please see the Known Issues section in the Readme.txt file for one case where you might still notice this problem.

Note that for both 32 and 64 bit versions, the installation folder is assumed to be C:\Program Files\ and that you’ll have a 32 bit version of Revit on a 32 bit OS and vice versa for 64 bit. As always, you can download the zip containing the documentation, AHK script, the compiled executable and icon from this AUGI thread (first post with version history). Enjoy!

Streamlining Local File Creation – update (x64) v4

Some thoughts about Revit files

So now with the new feature built into Revit that recognizes the “DNA” of a central file and automatically checks the option to create a local file with the appended username, adding the word “central” at the end could actually cause confusion when your local file is named myproject_Central_dbaldacchino.rvt. This is why we’re probably going to stick with a script for creating local files like in the past, so we can control the naming conventions, besides some other benefits. Hopefully we’ll have an even better user-friendly version, which is still in the works.

That brings me to the purpose of this post: Why don’t the developers implement a file extension system that identifies what type of file we’re dealing with? Perhaps .rvc for Central files, .rvl for Local files and leave the .rvt for non-workset enabled files. This would make it totally clear what you’re dealing with, eliminating the need for arcane naming conventions. A unique, easily identifiable icon for each file type would also be a very welcome addition.

Some thoughts about Revit files

Streamlining Local File Creation – update (x64)

The script has been updated to work with the following combinations:

1. 32 bit Revit on a 32 bit OS
2. 64 bit Revit on a 64 bit OS

It will look for an installation in the folder Program Files, so if you changed the install location, it won’t work. The previous script was a bit more flexible and automatically retrieved the custom folder that you might have used as your program installation folder. However on a 64 bit OS, the parameter is retrieving the Program Files (x86) folder, which is not the correct location for the 64 bit install. Because of this, I just hard-coded the folder into the script in lieu of the parameter.

You can download the zip containing the documentation, AHK script, the compiled executable and icon from this AUGI thread (first post with version history). Enjoy!

Streamlining Local File Creation – update (x64)

Streamlining Local File Creation - update

Earlier this month, I posted about a script/program to streamline local file creation. I finished some new updates which you can find on the AUGI thread Transparent Local File Creation (see the first post). I'm calling it Version 3, whatever that means :) I have added a readme file to the zip file that contains all the details you need to know about how it works, version history, etc. Here are the new additional features:

a) Check for Revit build between users working on the same project. The program will warn the users using a build other than what was used originally to create the first local file (using the script/program). This will help in alerting the BIM Manager/Workstation Administrator that some team members need to be upgraded.

b) Check if Revit is already open with a local version of the same project, belonging to the user that is running the script. If such case is detected, a warning will be issued and execution will stop.

c) The program will launch any Revit version from 2008 onwards (until they change the naming again!). So you'll be able to use it in a couple of weeks when the 2009 line-up is released!

d) Added an informative, animated splashcreen for a few seconds while a Revit session is launched.

e) Revit will now always open maximized.

If you find any problems, feel free to contact me. I'm also eager to hear your suggestions to make this a more useable tool. At the moment I have stayed away from using a GUI interface to select the project to launch, as this is tailored to our firm procedures, naming conventions, etc., and so far, it has been working very well for us.

Streamlining Local File Creation - update

Streamlining Local File creation

Creating local files for workset-enabled projects can be confusing to users and is quite an unelegant task. A while back I started a thread on the AUGI Revit forums titled "Transparent Local file creation". Thanks to AutoHotKey, I was able to come up with a nice, automated way to help teams working on workshared projects get started every morning in a consistent and easy way.

Since then the thread has had over 2,400 hits and numerous users have contributed to the ideas and solutions of this script. Today I finished version 2 and decided to post about it here. If you like what you see, go to the thread above (or click here) and download the script. I hope it will be as useful to you as it has been to me and a lot of AUGI members. All you need to do is to place a copy of the exe file (compiled version of the AHK script) in the central file folder and have team members create shortcuts to this file on their local drives (the Desktop is ideal). Then just double click the shortcut and wait until it's finished doing it's magic!

-------------------------------------------------------------------------------------------------

The script will do the following:

1) Check if the Central file exists. Filename is assumed to be XXXXX #VV central.rvt, where XXXXX can be anything of any length, # is the discipline (A, S or MEP, where the 3 letters in MEP can be expressed in any order) and VV is the version number (since we’re on 2008, we would use 08, but the script doesn’t care about this and you could in theory type anything). The spaces shown in the filename can be any character you want, including a space. So 123456789 Project_A08-Central.rvt would work the same as 123456789-Project-A08_Central.rvt (you get the idea).

2) If no Central is found or more than one exists, dialog warnings will be issued. The Central file folder will open in Explorer so you can investigate the problem immediately.

3) The discipline is evaluated (from # above) and if the input is not as expected, you will be warned and the script will terminate. The Central file folder is opened in Explorer so you can investigate the problem immediately.

4) Local files will be created in C:\Revit Local Files\XXXXX #VV\ so if the folder does not exist, the script will create it. It will also automatically create backups of your local files just in case you might need one (like if the Central becomes corrupt). So first it will delete the last backup and place it in the Recycle bin (it will stay there until you empty your trash). Then it renames your local file and appends “_BAK” to the filename, copies the Central file to this folder, and removes “central” from the name and replaces it with your Windows username (Ex: 123456789-Project-A08_DBaldacchino.rvt).

5) Check if the required Revit flavor is installed. If not, it will give you the option to open the file with the Revit flavor you have installed on your PC (Ex: it will use Revit Structure 2008 to open an Architectural file). If no Revit is installed, it will let you know and ask you to contact IT (niiiiiice!), after which the script will terminate.

6) The username in the Revit.ini is deleted to prevent problems down the line (you've all experienced having two people working on a project with the same username and one of them complaining they cannot STC, right?!). This ensures that when Revit opens, the username will be set to your Windows username. If multiple flavors of Revit are installed, only the ini file of the discipline that you’re trying to use will be edited.

7) The script will now evaluate what command line/switch was sent through the shortcut. It recognizes "detach" or "worksets" (not case sensitive). In the "Target" field of your shortcut, leave a space at the end and type "detach" or "worksets". If you type anything else, the script ignores it and opens the local file as if no command was sent. So for example your shortcut target would look like this: "\\servername\Projects\ABC\Central\test_A08-Central.rvt" worksets. In this case, the script will write a custom journal called "select_ws.txt" in your journal folder and fire it up in a new instance of Revit. If the command line parameter was detach, a journal called "detach.txt" would be written and used. The script still makes a copy of the central file as a precaution when detaching. Note that currently there is no way to run a journal in an already running Revit session through AHK, so using one of the two switches will cause a new instance of Revit to open.

8) If there is no command line parameter (or an unrecognized one) in the shortcut, the script proceeds as before. First it checks if Revit is already running. If it is, the session will be activated and the local file will start opening. If not, a new session is fired up and the local file starts to open.

9) When the annoying dialog shows up (that this Central has been copied….), it is automatically dismissed, thus rendering the whole process entirely transparent.

Streamlining Local File creation