Schedule Linked Files

We can schedule elements that are in linked files but there isn't a schedule that is only interested in telling us what linked files there are. We can determine which files are linked easily enough while working inside Revit. What if we want to document what files are linked into our model and include this information on a sheet? We can take advantage of the addition of Grids and Levels as elements we can schedule in Revit 2014.

If we assume that all projects will have levels and probably grids a schedule that is assigned to one of those categories can be manipulated to look like it is just a schedule of linked files. Then we can combine that with a Starting View if we want to see it each time our project is opened. Add the schedule to a general information sheet and it can be part of our documentation too.

I created a schedule that includes the fields for RVT Links and at least one for Grids. In this example I used Grids to drive the schedule but Levels are probably a better choice.

When we load a linked file we can supply a unique "Name" value. When we use Reload From or Reload later to update the model we can revise the "Name" parameter to show the current version/date.

Make a custom titleblock family and add the Project and Client related parameters as desired. Load the family and create a new sheet using this special titleblock. Add the new schedule to the sheet. To use this as a starting view activate the Manage ribbon and click the Starting View button. Choose our special sheet view as the starting view.

I used the Clear Cell tool, new in Revit 2014, to remove the link between the schedule name and the header text. This allows us to call the schedule something meaningful in the project browser and show something else in the header of the schedule on the sheet, as shown in the first image in the post. Since schedules can be on any number of sheets it is an easy matter to place it on additional sheets if desired.

Linked Files and Visibility/Graphics

When you examine the Visibility/Graphics dialog you'll find each Revit file you've linked is shown in a list under the Revit Links tab. In this example I've linked Building A, B and C into a host model. The Project Browser shows three linked files and Visibility/Graphics shows the same three but also shows one child link beneath the top level row for each link.

The top level row for each link is the definition of the linked file while the child beneath it represents the actual instance that is placed in the model. The single child for each link provides a way to customize the appearance of the individual linked file apart from the parent definition. Ordinarily this would NOT be required. If overrides are necessary it is sufficient and appropriate to just alter the definition (top level) only.

However if for some reason you were to use two instances of Building A and Building C the Visibility/Graphics dialog would look more like this, while the Project Browser would remain unchanged.

The new child rows listed for Building A and C are the result of copying the originals for each to a new location. Each new row provides us with the ability to use Visibility/Graphic overrides for each child differently if necessary. For example, I could turn off the first instance of Building C without affecting the second instance.

As you can see, the upper Building C is off now. I could also use the button that appears in the Display Settings column to override individual instances of the linked files. If I want to alter both copies the same way I just need to change the top level definition. I start by checking the option "Override display settings for this instance", choosing Custom, activating the Model Categories tab and then changing the Model Categories drop down to Custom. Now I can override individual model categories in just one instance of the two copies of the linked file.

The link names you see are not default values, I changed them via the Name parameter in the Properties palette.

When worksets are involved the top level is assigned to the Type Parameter "Workset" and the child has its own instance parameter for "Workset" too. This means the definition can be assigned to a workset but each instance can be assigned to different worksets.

If you see more than one child instance of a linked file and there should only be one child that probably means someone has copied a link inadvertently. If you can't tell then it's likely they used Copy to Clipboard followed by Paste Aligned to Same Place and there are two instances on top of each other. Since it's been so easy to accidentally select a link I see this happen fairly often. It can create some confusion when people are trying to override graphics and their efforts don't seem to work. There may be another copy lurking underneath.

Loaded and Unloaded Link Icons

In the project browser we'll see either a blue arrow or red X next to a linked file.

You see the Blue Arrow when the link is loaded and the Red X when it is unloaded or not found. That's true until Worksets are used. If a link is assigned to a workset and that workset is closed the Red X will appear, which will indicate that the link is no longer "present or visible", not that it is unloaded but it's much the same, in a way.

If you open the workset again the X doesn't go away immediately. It will if you do a Reload Latest (assuming there are changes to load), SwC or reload the link itself.

Reloading Links and Worksets

In past releases of Revit, prior to 2014, a linked file that is unloaded would get passed along to other users as they used SwC or Reload Latest, the file would be unloaded in their session too. It was a global effect, affecting everyone. In contrast using Reload on a linked file only affected the person doing the reload. Other users would not see the file as reloaded if they used Reload Latest or SwC. That meant Reloading a link was a local or personal change while Unloading a link was a Global change, affecting everyone.

As a result we started assigning individual linked files to their own worksets. This gave us discreet control over the unloading and loading of links through the workset dialog instead. Using Close and Open for a Workset is regarded as a local or personal change and doesn't spread out to other users on the team.

In 2014 I find that both Reloading and Unloading a link is now propagated to other users when using SwC or Reload Latest. They are now both global transactions.

This means it may not be necessary to bother with the Workset approach to manage the links now since it was originally put into practice as a workaround to avoid the reloading/unloading link "dance". By dance I mean, everyone gets a link unloaded and then we all end up trying to get the link reloaded each time we SwC or Reload Latest because someone else has unloaded it. This change doesn't eliminate the dance entirely. It just makes it easier to get the link re-established by one user so everyone else can see it again.

If you prefer to treat the unloading (and therefore the reloading) of a link as a personal or local change then the practice of one workset per link remains useful.

Overlay VS Attached

A question posted at AUGI started out simply by asking if this concept is the same at AutoCAD. I replied, "Exactly the same concepts". Then another member expanded on my reply and it seemed to muddy the water for the person who wrote the original post because when they replied it sounded like it was still unclear. I wrote this longer reply and decided to put the explanation here too.

Choosing between attached or overlay is to determine how Revit should regard a link when the host file is linked into yet another file. For example, if File 1 is linked into File A and set to "attached", when File A is linked into File B, File 1 will also also be loaded into File B. If File 1 is changed, when its host File A is reloaded in their host File B, File 1 changes will also be seen, if its own changes have been saved before Reload is used. Both files are read independently during a Reload. You will only find the host File A listed in File B's Manage Links dialog however. Written another way, when a link is reloaded, it's attached nested links will also be reloaded.

When Overlay is chosen instead File 1 does not get loaded into File B. No circumstance will cause it to appear nor will we be aware of changes within the link.

We should use the "Attached" setting when we link a file into another file AND expect its own linked files to show up as if they are native elements in the file too. Changes in either the parent or child will appear when the parent file is reloaded into its host or if the host file is opened after changes have occurred in either.

In practice, if we create an architectural model (parent) that uses linked files (children) for repeating units they will need to be set to Attached if we want the units to appear when the "parent" architectural model is linked into a structural model. When we pass along our model to the structural engineer we will need to send both the "parent" architectural model and the "child" repeating units. When we link in their structural model we should use "Overlay" so Revit does not try to load their structural model when the structural engineer links our architectural model into their own model.

Clear as mud?

Synchronize with Central and Referencing Elements in Linked Files

A post yesterday at RFO reminded me I've not written about this situation before. Generally Revit supports applying dimensions to elements that are in linked files (tagging too). If we go down that road a paradox of sorts can occur as several of us are working. RFO member AnthonyB did a nice job of explaining the conditions he encountered. The following is based on his example, applying dimensions to linked walls:

Model A has walls and Model B has dimensions. Larry adds some new walls to Model A and uses Synchronize with Central (SwC). Then Larry opens his local copy of Model B and adds dimensions to his new walls followed by using SwC.

Meanwhile Darryl already had his Local File of Model B open doing other things and Larry's changes all happened while he was working in this file. When Darryl uses SwC to share his changes he gets a warning message like this one.

Further, since Larry added a couple tags on walls, in the link, Darryl's message includes something like this one. The host elements (walls) are not present so Revit wants to toss the tags too.

We must take extra care when we choose to reference elements in linked files. If your project uses this approach you'll need to let others know that they should use Manage Links, select each affected link and click Reload BEFORE using SwC. This will ensure the elements that your current project file is supposed to see, will be. Be careful out there!

Schedules Can Include Linked File Information

My reply to a thread at AUGI this morning prompted me to post this. I've probably mentioned this in the past but it's easy to overlook. When you use a schedule that includes elements that are in linked files you can also include two parameters for the linked file. It starts by checking the option to Include Elements in Linked Files. Then you can choose the drop down list Select available fields from:

Choosing RVT Links will provide two parameters: File Name and Name (a value you can control/change). The following image is a little mockup of windows that are both in the host file and in a linked file. The issue expressed in the AUGI thread is figuring out which file incorrect windows are in so they can be replaced. In that situation there were many linked files so it wasn't as easy as opening up one linked file.

Linked Files and Delete Rooms

When you are opening a project with linked files (or reloading one) if you see a dialog giving you the option to Delete Rooms, please don't click the Delete Rooms button. Please!

Nobody will be happy with you if you do, not even you. It would be wonderful if Revit stopped offering the ultimate in self-destructive options in warning dialogs. Too often Revit's solution to a problem is a delete button. As the knight's in Monty Python's Holy Grail movie said, "Run away, run away!"

Paste Aligned Won't Play Along

I recently encountered a situation where two Paste Aligned options did not work while the option for "Aligned to Same Place" did. In this situation I was moving elements from one building file to another because of a scope of work switcheroo.

Typical we can select elements in a linked file and then paste them into the host project. Ordinarily I can paste walls, for example, using "to Aligned to Selected Levels" or "Aligned to Current View". In this case the walls didn't seem to remember their level arrangement even though both models observe the same elevations and naming. Revit insisted on putting them on the level above or the level below.

I ran into the same disrespect using "Aligned to Current View". The only way I got what I wanted was using "Aligned to Same Place". I was in a hurry so I didn't back up and try to figure out what might be contributing to the issue. I've never had a problem using the other options with elements that were already part of the same host file, you know just pasting elements to other levels to copy them upward or downward. Maybe it has something to do with the fact that these elements were coming from the linked file?

Something to consider the next time you are copying and pasting elements from one file to another.

Filter Pesky Levels

Need another way to manage the Levels of linked files? Sure we can assign them to specific worksets and have matching worksets in our model. Sure we can edit the V/G settings of the link in views (and view templates). Here's another, use a Filter and the criteria "Structural" that is available for levels.

When you examine the properties of levels you should find the parameter Structural. If the engineer uses that for their levels and you don't, then this concept works.

Now build a Filter that hunts for levels with the Structural parameter.

This is before the filter is applied.

This is after the filter is applied.

They can do the reverse by reversing the logic of the filter, Structural = no.

Happy Filtering!

Linked Files with Linked Files

Ran across a recent situation where a good number of units were modelled as linked project files and combined into a "master" file. This master file was then linked into another model. As attached links that meant they would automatically show up as long as the source file was "found" (in a folder it could find).

It may have seemed like a good idea when they started, but the down side is nearly zero control over the nested linked units. About the only way to control what they look like is if every (and I mean every) sort of view configuration you might need in other files that host the combined file are preset in the "master file". The display of nested links can be configured to use the Linked File settings. Unfortunately, this is hard to really accomplish because we might not be able to imagine everything that will need to be done. That means an awful lot of back and forth to get it all to work.

My recommendation? Don't go there...

Linked Files have Instance and Type Workset

Linked files are assigned to the active workset, when worksets are in use naturally. When you select the link you can see the Workset parameter in the Properties Palette. Less obvious is that they also have a Type Property called, you guessed it, Workset. This can trip you up when you are trying alter visibilty graphics because they need to match.

The reason they have both is that the Type Parameter is for the definition of the link in the database and the instance parameter is for the actual link. There is a row in the Visibility Graphics dialog for each link as well as a single row beneath it for each instance of the link.

I say each instance because a link can be copied. If you import a file it is both the definition and the instance. If you copy it and put the second instance elsewhere you'll see that another row will appear beneath the first one and both will be under the primary entry. This is done to make it possible to alter each instance of the same linked file differently via Visibilty Graphics.

Experiencing control issues with a link? Remember to check the workset assignments.

Wall Floor Interaction and Linked Models

When we have architecture and structure in separate Revit models we end up with somewhat clumsy graphics in wall sections. This is more pronounced if the structural slab is in the structure model only. It could look like this.

The wall continues past the floor as if it isn't there. One possible solution that allows us to keep the structural slab in the separate file and avoids the copy/monitor scenario is to place a Reveal on the interior side of the wall. The profile needs to be equivalent in size to the slab thickness and the wall thickness (inside surface plus however far the slab extends toward the exterior). This approach creates a bit better result.

I should mention that this works the other direction too, since the reveal is part of the wall it will leave a "hollow" space for the structural model's floor slab to occupy.

In Search of a Side Door Managing Links

I wrote about the Manage Links dialog yesterday. Something else has been bugging me about it so here's another post. I'd love a side door to Import a file from the Manage Links dialog!!! It would be nice to be able to click Import File when I've realized that I need to do that instead of closing the dialog and then clicking the front door buttons for the task. Each tab could have its own side door for the appropriate file type. Crazy?

There are other precedents like the Materials browse button in the Edit Assembly dialog for walls, floors, roofs, ceilings. Another precedent, the browse button for accessing Assembly Code data?

See, not so crazy me thinks!!