Unloading a Link Deletes Radial Dimensions

I read THIS post at RFO with interest naturally. The thread is about losing dimensions when linked files are updated. A subtle development in the thread is that radial dimension and linear dimensions are affected differently when a link is unloaded. Aaron Maller noticed that, mentioned it (in the thread) and asked someone at Autodesk about it. They looked into it and replied with:

Originally Posted by Autodesk Team

Here are the details. This is caused by the inconsistency between linear and radial dimension internal design.

For linear dimension, it handles “Unload a linked file" as a special case of dimension references not visible in the current view, while for radial dimension, it handles the unloading as invalid dimension reference, and thus it requires deletion of the radial dimension when unloading.

We will see how we might improve the radial dimension to follow a similar behavior pattern.

The emphasis was added by Aaron. Okay, good to know. For now, radial dimensions are at great peril if they are referencing a linked project. Best bet is to avoid dimensioning to linked elements anyway but especially so with radial dimensions. 

Topography Links and Using Tag by Category Makes Revit Angry

This one is subtle, like so many Reviteristics.

A team is testing the Revit to Civil 3D relationship via BIM 360 and Autodesk Desktop Connector. I don't think there are enough moving parts for this equation but I digress. A user reported that Tag by Category (TbC) causes Revit to crash.

We narrowed it down to linked Topography. If any exists then TbC gets dicey. Here's what we know so far:

• Topography link Not Loaded status > Topography category visible in active view > TbC crash
• Topography link Loaded status > Topography category NOT visible in active view > TbC NO crash
• Topography link Loaded status > Topography category visible in active view > TbC NO crash

The team's project has two different linked topography sources so there are two of them in the Manage Links dialog. I haven't tried with just one present yet.

I'd be curious to see if anyone else can corroborate our situation. I've submitted crash reports (several/many) as I worked on this so perhaps Autodesk will find some lurking evil to contend with in the meantime.

Happy troubleshooting...

Drafting Views have an Origin Too

Drafting views look like a blank sheet of paper we can drop your pen and start sketching in. We can but it might help to know that they do have an origin and you can end up quite from from the origin if we use an external file to sketch over (which happens a lot). I routinely encounter projects that have very large drafting views, when you know where the origin is.

The old trick to find the origin in Revit was to import/link a DWG with a crosshair at the world coordinate system origin. Linked via Origin to Origin places that DWG at the origin of the view. The PyRevit application has a handy function to place a pair of intersecting lines at the origin of a view. I find I just use that now instead. It's about the same number of "clicks" either way.

Now, the natural question to ask is, "Does it matter?" I don't know but if large extents are bad in model views I can reasonably infer that it might also be bad in drafting views. I don't have any evidence that this model was bad because drafting views were huge. I do know that some bad models I've encountered also had drafting views with very large extents. When I deal with a such a model it is one of the things I consider (of the many things, so many things).

Good housekeeping isn't just for the model.

Large Extents -Can't Navigate in a View and-or View Will Only Show Wireframe

I've written about Revit's fussiness regarding large extents numerous times over the years. In some of those posts I mentioned a related view issue. A view that refuses to show the model in anything other than wireframe is a symptom of the large extent issue.

I recently encountered a project that didn't have any DWG files to blame for it. Not only did the view not show according to graphic style settings it didn't allow navigation of any sort. The view was frozen. We could open or close it but nothing else. I noticed I could use a crossing selection window but then using Filter to focus my troubleshooting effort was still too coarse.

I've been meaning to mention how much I like IDEATE Explorer (IE). It has been very useful to examine projects and track down issues. It permits examining a model in ways that Revit can't. for example, I can select a category of elements or instances of each family/type within the category.

I use it routinely to check for excess DWG imports (resulting from exploded DWG content), workset assignment, reviewing warnings (more effectively than Revit's own), phase assignment/usage, content naming/usage and resolve line style usage (and more).

After using the crossing selection window in various parts of the view I realized some structural elements seemed quite far apart. Keep in mind the view was a white screen of nothing...imagining gazing toward Earth from Mars and trying to pick out where California is or my house. The Project Base Point and Survey Point didn't even show up in the view.

I started with trying to isolate where in this vast white space the structural element was but no matter what I tried I seemed to always select some structural framing.

Once I knew which category to hunt in I used IE to look at individual framing elements. I found a single framing (W Beam) was 2+ million feet long. I expected to find a family very far away, not one that was just very long. I realized that a Structural Framing schedule could have revealed this element too, if I knew which category and to look at Length. I did make a schedule just to see if I missed any other really long framing.

One Beam, one verrrrry looonnng beam killed any view it was visible in. 3D views are where we were confronted with the problem but other views whose extent permitted the beam's true extent to affect the view were also victimized. In the end we rolled the project back to just prior to the beam being added. 

The views didn't "recover" from the harm when the offending beam was deleted. I surmise other aspects of the model were altered by the extent of the beam, perhaps scope boxes, crop boundaries, a connected or joined element...not sure. That will remain a mystery.

May your troubleshooting be quick, effective and "trouble" free.

Revit 2021 Line Style Naming Tweak

I saw Jason (@RVT) tweet about this yesterday and I thought this is right up the Dept. of Subtle alley.

I've been telling people for years that the brackets meant "these belong to the Revit system" but then there were several other rogue line styles that came along without brackets. I had to explain that any line style you couldn't delete is also a system line styles...

Consider the Dept. of Subtle tickled.

Reset Shared Coordinates Update

During April 2012 I wrote about using a separate file as a diversionary tactic to allow us to reacquire coordinates from a model we used Acquire Coordinates on before; now that it has changed and no longer lines up with our own work.

In the years since that post Revit seems to have decided it should remember more than one file has had the Acquire Coordinates tool used on it. Revit used to be monogamous but that's no longer true.

The reset process is still necessary but an extra step is required now: we must deliberately disable the link's Shared Site setting first.

Usually it is necessary to move the linked file to align with ours and so its new position can be reacquired. If the setting isn't disabled first it will trigger Revit's desire to change the Shared Coordinate system of the link. Keep in mind that Acquire Coordinates is a pull transaction but moving a file that is sharing coordinates causes Revit to think it must push that change out to the related file. If that's what is really needed then consider using Publish Coordinates instead.

Select the linked file and in the Properties Palette click the Shared Site button (by default says Internal unless someone has changed the name). In the Choose Site dialog that appears click the radio button for Do not share site of selected instance.

It should say <Not Shared> like in the image above after choosing that option. It should be possible to move the linked file into the desired position so it lines up with our model correctly again. If it works correctly you won't get a warning to save the changes to the link nor will you get prompted to do so when you save the file.

It is now possible to link a Reset File to use the Acquire Coordinates on. As soon as that is done successfully the original linked file can be used to Acquire Coordinates again, from it instead.

If the disabling step was not taken we'd find that Revit remembers it has a shared coordinate relationship with both files, the original link and the reset file. Examining properties for both linked files would reveal a Shared Site setting in play (Internal) for both.

However, Shared Coordinates and its Survey Point only acts according to the last file Acquire Coordinates was used on regardless how many files Revit is keeping track of. Trying to use Acquire Coordinates on either file in this condition will just generate this warning.

It's almost as if Revit is treating using Acquire Coordinates like a marriage and keeping a record of each marriage, regardless how many divorces the file goes through. I'd recommend it moves on, focus only on the active marriage and make that work.

To recap - if you find your shared coordinate relationship has failed you'll want a divorce. Then you'll fall for someone else quickly, on a rebound, only to discover that your previous love was the best. Just remember you need to get a lawyer involved to disable your first marriage before you start your rebound. This way you'll legally be able to get married again when you come to your senses.

Active View can Matter When Linking Using Positioning Auto - Center to Center

If you link a model via Positioning: Auto - Center to Center in a plan view its zero elevation will align with the host model's zero elevation.

Do that in an elevation or section view however and the linked model may not rest at the correct Zero elevation. The discrepancy man be very subtle or quite obvious. It will depend on the adjusted extents of the view that is active.

The trigger appears to be the elevation or section view being cropped very shallow (only one level visible) prior to linking the model (tested as far back as Revit 2015). If all the levels are visible in the view it seems to be more reliable.

Far safer me thinks to just link via a plan view, something to watch out for. 

Insert From File and a Worksharing File

I bumped into a subtle conflict this evening. I created a new file from a stock template. I then used Insert from File > Insert Views from File to acquire a few drafting views. When I closed this new project and decided to open the file the harvested drafting views are stored in this message appeared.

Keep in mind that no files were actually open at the moment. I was looking at the Recent Files list yet when I attempted to create a new local file for the project I just used Insert From File on the message popped up. This means that the file is technically still open in RAM as far as Revit is concerned, it's just not open for me to interact with.

I had to exit Revit so it could relinquish its hold on the file before I could start Revit up again to get back to work.

Revit 2018 - Insert Ribbon Search Field is Removed

When Autodesk Seek gave up on their mission and handed it over to BIM Object Revit 2017 started to redirect us to that site instead whenever we did a search. Prior to that it would take us to Autodesk Seek.

Notice anything missing from the 2018 Insert Ribbon image above? Well the post title gave it away but the search field has been stripped off. Remember this following image from way back when?

I realize it didn't make sense to leave references to Autodesk Seek in play. Now it's even less helpful to find external content. I guess it's more incentive to install BIM Object's Revit app? Probably what they intended.

No you're not imagining things, it's gone gone gone...

-- EDITED 5/2/2017 --

I installed the BIM Object Revit app.

Holy smokes that's a heck of a ribbon for the primary button I really want, Browse on the far left. Note if you launch any of the tools you can't do any work back in Revit until you finish interacting with their app. If you find that frustrating you could just open a separate browser.

It would be nice if there were some user settings to reduce the number of buttons to just those you're likely to use. I added the browse button to the QAT to get around accessing the ribbon tab each time.

Smooth or Stepped Stair Setting

I want the concrete corner stair to look like this.

When I finished it looked like this.. sad face...

A stair Run has two options for Underside Surface: Smooth and Stepped. Smooth is what I started with.

There are occasions when I want the underside to look like the second image above, if so I'd probably tackle that like THIS POST. In this situation I wanted the following appearance. I got it by changing the Structural Depth parameter to match the height of the stair.

Type Selector on Ribbon - Oops

I received quite a few comments on the last post. Most were pointing out that my powers of observation are failing me. It's a feature that has been in the product since at least 2011 according to one insider at Revit. Mea culpa!

Qualifies for Dept. of Subtle eh?

Revit 2017.1 - Type Selector on Modify Ribbon

Working with some new Revit users last week I noticed something strange happened to my interface and not theirs. I suddenly had a Type Selector on my Modify Ribbon tab, on its own ribbon panel.

I thought, "I don't remember that!" Then I thought, "It must be a new subtlety with Revit 2017.1 that I haven't noticed yet!" Looking at it again, once I remembered to be curious, I found that when I right-click on the Type Selector, in its long standing home on the Properties Palette, two options appear, the ribbon one being new. Those other users had Revit 2017 installed.

Now I don't see the What's New in Revit 2017.1 documentation page taking credit for this subtle change. I don't recall running into it while writing my What's New post for 2017 when that came out either, nor is it listed in that documentation section either when I scanned it again just in case.

I wrote strange happened earlier because I don't recall right-clicking and selecting that option unless I had a short term memory lapse. I suppose I might have been talking and clicking without looking, yeah I've done that while discussing a Revit feature plenty of times. What was I writing about? Oh...

Still I don't remember doing it. I also don't remember it being there all along since installing Revit 2017.1 in the first place and I'm pretty sure I've used it a lot since doing that. ...again with doubting my memory? I suppose it could just be the default location for the original install of the update and I just failed to notice it. I don't that's speaking well of my observation skills though. Well, never mind.

Don't worry about me, just take advantage of it if you like that as an available option too! Since Autodesk isn't claiming responsibility for it, who wants to?

Tags Dimensions and Linked Files

I've mentioned this subject in the past. I'm writing to bring it up again and to focus on how Revit deals with tags and dimensions differently when we apply them to elements that are in linked files.

First as a reminder, when a linked file changes and a user reloads that link in their Local File other users are not necessarily seeing the same version of the Linked File. That's because reloading a link is a local change, a personal action, that doesn't get passed along to the Central File when we use Synchronize with Central (SwC).

Let's imagine User A has reloaded a linked model and they've placed tags on doors and rooms that they observe are now present in the link. User A uses SwC to share this new tagging effort. Now User B, who already has a Local File open, decides to use Reload Latest or SwC to share something they've done or see what work other users have contributed.

It's important to note that User B did NOT use Reload in Manage Links or via right-click on the linked file in the Project Browser FIRST. As a result User B gets the warning in the next image. Don't be confused by the mention of Coordination Monitor which can be confusing. It can make us think we're dealing with something that has been involved with the Copy/Monitor tools.

The Tags are Orphaned, they've lost their relationship with the linked file's elements they are supposed to identify. You can see one tag is highlighted in orange in the image above. In the next image we can see what the floor plan really looks like in the linked file (and what User A sees). It's not quite the same as what User B thinks it looks like is it?

Let's now imagine that User A continues to work by adding the dimensions you see in the image above too. After they finish doing that they use SwC.

User B now decides to use SwC or Reload Latest, AGAIN without using Reload on the linked file. Their reward is a larger collection of warnings (see next image). The first three warnings are dedicated to the dimensions User A added to their Local File. There are no equivalent elements in the version of the linked file that User B sees so Revit's only recourse is to delete them ... or ... choose Cancel ... which is actually a better choice. If User B cancels and then Reloads the linked file first that will eliminate the warnings entirely.

The remaining warnings are focused on the newly orphaned door and room tags that can't find their parent elements. If we select one of the orphaned tags we can either use Pick New Host or Reconcile Hosting. The former will need us to pick a door to associate the tag with. The latter will open the Reconcile Hosting browser which shows us everything that has been orphaned so far. We can select individual items and right-click to use Pick Host or Delete the tag if that's a better choice.

Keep in mind, once this orphaned status occurs it sticks. Merely reloading a linked file afterward isn't going to fix it. We'll be forced to deal with Reconciling Hosting. In some situations it might be faster to delete the tags and use Tag All to place them all over again.

This might be an opportunity for an enterprising developer to write a routine that looks at orphaned families and picks the closest possible host? Better still...Autodesk?

My recommendation, if you MUST use tags and dimensions on linked files?

Develop the habit of reloading the necessary linked files BEFORE using SwC or Reload Latest.

If you get the warning messages in the images above, use CANCEL. Make a note of the elements the warning(s) is(are) focused on. Most likely the warnings are being issued because you need to use Reload on the linked files first.

I'd also consider a moratorium on applying tags or dimensions to linked elements while the link is being changed aggressively. For example, if we know that the link is going to undergo some massive redesign we should just agree to stay away from tags and dimensions until it settles down again.

It's also a good idea to let other people know that you have changed an integral linked file so they can all use Reload (link) to catch up together.

Create New Local is Disabled

I've written about this in the past, like THIS ONE. Today I noticed another circumstance where the option is disabled even though it shouldn't be. When we browse to open a project we can click on a file listed among the contents of a folder. If we do that then Create New Local is enabled and checked by default. At least that's true if other circumstances are not preventing it, like those described in my other post.

What I saw today is that if I choose to type some of the file name in the file name field Windows will supply me with a list of file names that begin with those letters, cool Windows behavior. If I select the correct file using that list then Create New Local sleeps through the effort and fails to become enabled.

Want to see it happen?

Revit 2017 - Align Padlock and Wall Core Centerline

If you think you're going crazy because no padlock appears when you try to align and lock a Wall by its Core Centerline, you're not crazy (not about that anyway). Revit 2017 seems to have gotten distracted and doesn't turn on the padlock when using Align on that portion of a Wall. Damn that's subtle!! They are on it though. I imagine it'll be fixed once an Update Release (Service Pack) is made available.

Revit 2017 - Associate Family Parameter Tool Tip

It's the little stuff...

Revit 2017 is missing the tool tip for the Associate Family Parameter button that it took awhile to get. Now it's tool tip-less again.

It makes me sad for that little sneaky button :(

Revit 2017 - View Range Keyboard Shortcut

Brian Mackey wrote a post earlier today that describes two quirky issues with using the new View Range keyboard shortcut VR. It is definitely subtle, quirky and worthy of an echo.

The first quirk is having to click Apply first and then OK to close in order to make a change stick. I'd run into that too and meant to write something but Brian was quicker to the keyboard. The other, and very important, thing to know is that using it ignores when a View Template has been assigned to a view, meaning the template is supposed to be controlling the parameters for View Range. That's not good! Check out his thoughts.

As such it is no longer his favorite new subtle feature and I'm inclined to agree, too bad.

Family Templates and Reference Plane Inequity

This is subtle but still a source of amusement or annoyance. Start a new family using the Generic Model template and try to copy an existing Reference Plane. Nope, the Copy tool is disabled.

Now try it with the Furniture template. Ah, Copy is enabled.

Try it in the Casework family template. You'll find Right, Left and Front Reference Planes are forbidden while the Center (Left/Right) and Back Reference Planes are not. That makes sense. Wait, what?

Okay, the rule is copying a Reference Plane working on furniture is okay and doing that in Generic Model templates = BAD? Doing it in the Casework template is, well it depends...

Actually the only rule is that you can expect some reference planes in some templates to be forbidden to copy while others are not affected by such thinking. Ralph Waldo Emerson cautioned us to avoid a foolish consistency. In this case a little more consistency wouldn't be bad.

...I'm not asking for all of them to be forbidden either...if you're wondering.

Orientation is not Managed by View Template

When we choose to assign a View Template (VT) to a View, that makes the template the view's boss. It takes over control of each setting we choose to make it enforce. In this image notice the parameters that are gray, not editable?

Those are being managed by the View Template. I've got to edit the VT to change one of those parameters or use Enable Temporary View Properties to override them briefly.

I noticed yesterday that the Orientation parameter does not behave like other View Properties even when a VT thinks it is in charge of it. This is the VT's dialog showing it is currently assigned to Project North; we can choose either Project North or True North. The check in the Include column (on the right side) indicates we want the VT to take over.

Therefore I find it counter intuitive that we can still interact with and change the Orientation parameter in the Properties Palette even though the VT is in charge.

If the VT is changed the view will follow along as expected. I wouldn't expect to be able to change it back in the View's properties with the VT in charge, but I can. This means the Orientation parameter is affected (managed half-heartedly) by a VT but it isn't truly in charge of the parameter, not like it is for other parameters.

It is inconsistent, perhaps a bug?

Levels and Story Above

Listening to Bill's BIM Thoughts podcast with Carla Edwards and Paul Aubin (Session 29), Carla reminded me of a parameter associated with levels I wrote about in 2013 but it was buried within a post of a different title. So I decided to clip it out of that post and give it some air again.

Levels have a parameter called Story Above; and a related parameter called Building Story.

This is the current description for the Story Above parameter from Autodesk.

"From Revit Help"

Used in conjunction with the Building Story parameter when exporting to IFC with the export option Split walls and columns by story, this parameter indicates the next building story for the level.

By default, Story Above is the next highest level for which Building Story is enabled. To access a list of all building stories above the current one, click in the field. The Story Above does not need to be the next higher level or building story. If the selected level is deleted later or if Building Story is disabled, any levels with this level as their Story Above will revert to default behavior.

Unfortunately what Carla described about how it is used isn't entirely on track, sorry Carla. The first sentence in the help documentation description didn't include the information about IFC initially. It was revised at some point after the feature was introduced. The two parameters Building Story and Story Above only factor in if we export to IFC. They don't influence anything else. It might be useful if they did.