BIM 360 Linked Revit Models use Local Cache Path

We've been running into this situation lately. Linked Revit models start using an individuals collaboration cache location for the path instead of the project's BIM 360 location.

At first it seemed that we could resolve it easily by applying the update for Revit 2020. Most of the active projects I deal with are still based on Revit 2020.

It appears that a fair number of firms are deploying "even" years and skipping the "odd" years. The larger the scope of deployment seems to have some influence over that choice. I've been working with 2021 in smaller situations though, wishing it were true everywhere...I digress.

Autodesk acknowledges the issue and has this ARTICLE to contend with it.

Wishing it were that simple, we are still running into it. Naturally there is another ARTICLE that mentions they are still researching the issue but that using Force Relinquish (BIM 360 Manage Cloud Models option) can cause this situation too. This requires us to clear the collaboration cache for a user who has forced us (haha) to use Force Relinquish. We are still in the diagnosis phase ourselves so we're not convinced of anything yet.

The article also tells us that using Force Relinquish should be a last resort and not recommended for routine use. Autodesk article says, 

"This is happening because somebody has used Manage Cloud Models to force relinquish that user from that link, which breaks the link in the host model for the affected user."

"Note: Force Relinquish is a destructive operation and should be used sparingly! It is intended to be used as a last resort when the user to be relinquished is unavailable for some reason."

"If someone has been forced out through Force Relinquish, then all the changes that they have not synced, become orphaned and lost. While the central model will be unaffected by the use, people can lose work (and have to close and reopen the model which will be slow)."

"It is better for the user to open the model and use Relinquish All Mine to relinquish their permissions rather than using the Manage Cloud Models dialog."

Okay, that's fair. However the new named user subscription based model "forces" this option on us (not haha) at large because we can't pretend to be another user anymore. As soon as we log off to become that user we lose our Revit session too. Catch 22

It would be nice if employees didn't quit and go elsewhere or earn a dismissal. It would be nice if 3rd party applications didn't need to borrow a workset on our behalf and then refuse to return a workset without our knowledge. It would be nice is 3rd party applications that do automation didn't require their own username to run quietly in the background and then fail to return a workset from time to time.

That world is where we can find pink unicorns with diamond encrusted saddles, at least I think that's where they are, I could be wrong?

Right now clearing a workset conflict in Revit Server projects is not nice. BIM 360 at least has Force Relinquish...but now we're told you really shouldn't use it because it might wreck your linked model paths. It starts the kind of internal conversations that make EyeTee license management "heads spin". Nobody wants users to start sharing log in credentials do they?

Additional Collaboration Cache Article

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...

Exploding DWG Files

 "Just don't explode DWG files" is good advice, that is immediately ignored because...reasons...

Setting that aside, now that we've exploded that DWG, now what. First, there is full explode versus partial explode. A full explode will recreate all the DWG elements into native Revit elements (assuming it is possible) but a partial explode will produce some native elements and some new DWG elements (blocks).

Reducing all DWG elements to equivalent elements in Revit is fraught with peril. Not all blocks in a DWG are created well. Explode one block that happens to have very large extents and your project will now have display/graphics issues. A Revit project might have one imported DWG but many times that number after partial exploding.

I recently encountered three project files that had +95k imported DWG files. These were the result of partial exploding less than 20 DWG files. As most people are aware, Revit won't create an element if it is too short (less than 1/32" long). A scary number of these DWG files were invisible, undetectable by eye in any view, because I believe their contents were too short to display. Many thousands were in just a few views. I used IDEATE Explorer to select, open the view they were in, if they were invisible then delete them.

It was time consuming; for some of them it was fastest to just delete the drafting view entirely because the view/detail wasn't going to be used on the project anyway. It was part of the everything and the kitchen sink approach in their template. Many of these details were derived from existing DWG based details created over many years to varying standards.

Back to Revit and exploded DWG elements...

Each line, arc, circle, etc. element is recreated and assigned to a new line style named for the layer it lived on in DWG. Similarly each text element is created using DWG info to define it as unique. Line and fill patterns are created this way as well. Ditto for dimension styles...and filled regions...

Once these exist in a project they are prone to being used by others because they are there. It is hard to ensure the standards a company has developed are used when this additional noise is present.

If we must explode a DWG let's not do so in our active project. Use an isolated file, based on our project standards (template). Once exploded, take the time to convert everything to our standard types. The completed drafting view can be added to our active project using Revit's Insert from File tool.

Also consider the time is takes to do this well...might be as long or longer than sketching over a detail DWG instead. If our detail item library is pretty good we'll be able to create a detail faster because we have components to represent the same kinds of things the DWG has in block form etc.

Don't sweep the DWG remnants under the rug...

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.

DWG XREF Follow Up

 A year ago I wrote about XREF DWG files showing up in Revit even when they are assigned to Overlay vs Attached. It hasn't been resolved, meaning Revit is still doing it, no change...

Shortly after writing the post we arrived at our "solution", to assign all Xrefs (in AutoCAD/Civil 3D) to a unique layer(s) and turn that layer(s) off in Revit (via View Templates usually). This way the extra layers of the xrefs do not show up even though Revit is technically ready and willing to show them.

Create or Opening a Section View Crashes Revit

Have you encountered this issue (and/or elevations)? By crash I mean Revit stops responding, the blue spinning wheel of death. One cause I've identified is HVAC Zones. I've been able to resolve each on so far by deleting the related zone(s) and creating the zone(s) again. I haven't figured out what is going wrong with the zones. I'm just calling it corruption for now but I have no idea if it is something I can prevent or see first yet.

Happy to hear if any readers have encountered this situation too.

Parameter is Missing for Some Types

From a thread at RFO, Aaron explains what's gone wrong...

Aaron wrote:

"If someone deletes a family that is also the default option for a Family Type, with that Shared Parameter: Yes, the entire parameter gets deleted. It's terrible behavior, and its been that way for years.

In case I wasnt clear: This is a known issue, and it's easily reproducible.

1. Take any Family that uses a Shared Family Type Parameter, that has a default value.
2. Find the family in the project browser, that is the Family and Type that's in the default value.
3. Delete that family from the Project Browser.
4. After you've clicked *DELETE* in the warning, go back to the original Family (the parent family with the parameter).
5. For JUST the types that had that default value set, that parameter is now gone.

And yes, the instances in your project are hella broken, now."

Keynote Schedules Not Updating

I wrote a post in April last year when we were observing some projects that would not update their keynote schedules during printing.

When they issued 2018.3 that issue was reportedly resolved. Moving forward into 2019 and 2020 versions it seems true. However we've seen a few projects that seem to continue to exhibit the problem. Specifically a keynote schedule does not show all of the keynotes that are actually visible in views on the sheet.

With these troubled project files we can force a regeneration IF each sheet view is open during printing. Like before turning the annotation crop boundary off/on or on/off will cause a regeneration too. However printing is when it matters the most. More testing is required before I can be certain there is an ongoing issue in the more recent releases but these projects do exhibit the problem in more recent versions too.

The current solution is to open all the sheets that must print first and then print to PDF. Alternately open a sheet view and print and repeat for all required sheets. If all the views are open then the revision schedule regenerates (you can watch it happen). The sheet view does not have to have Revit's focus, just has to be open in the background at least. Any sheet views that are not open won't refresh.

Revit 2020.2.1 Hot Fix Posted

Regarding my last post - a Revit 2020.1 Hot Fix is now posted.

Of specific interest...Autodesk writes:

Issues Resolved:
Fixed an issue that resulted in the loss of family data in some workshared models when family definitions had not been recently modified. This fix does not repair models which have encountered loss of family data, for more information refer to Family Corruption in Revit 2020.2

Revit 2020.2 Corrupt or Unusable Families Issue

Autodesk posted an article describing a particularly unpleasant bug/issue that started to appear shortly after 2020.2 was made available. This is the text from the article. If you're using 2020.2 pay close attention, you don't want to catch this bug. They've removed the 2020.2 download until they've resolved the situation.

Issue:
The Revit team has identified a defect with Revit 2020.2 that affects a small percentage of customer projects. In order to reduce the likelihood that customers come across this issue, we have temporarily removed the Revit 2020.2 updates while we work to provide a build that remedies this defect. For customers that have already installed Revit 2020.2, please see the FAQ below. We apologize for any inconvenience this issue may have caused.

Solution:

Q. What is the issue?
A. A change in the way that Revit 2020.2 processes families can cause family content to go missing from workshared central models created in previous versions if the families have existed in an active project for a long time without being modified. The defect results in the deletion of the family content from the central model.

Q. Which versions/models are affected?
A. This issue affects only Revit 2020.2. Previous versions are not affected.

Q. What models are affected?
A. The issue can affect workshared models that were created or upgraded in Revit 2020.0 or 2020.1 which are then repeatedly modified in Revit 2020.2. This issue can impact central models stored locally, on Revit Server, or in Revit Cloud Worksharing. The following models are NOT affected:
Non-workshared models
Workshared models created and exclusively modified in Revit 2020.2

Q. What if I have already installed Revit 2020.2?
A. If everyone on the project team is working in 2020.2, there are a few one-time operations you can take in a Revit 2020.2 build to prevent the issue:
Rename all families in the project (e.g. FamilyX to FamilyX-2 and then back to FamilyX)

OR

Save the model as a new central (must be a new file, not Save As to the same location)

OR

Reload all families (including company, Autodesk, and 3rd party families) in the project

OR

Move the entire project team back to Revit 2020.1
If the team is working on mixed versions, we suggest first getting everyone onto the same version. Working in a mix of Revit 2020.2 and earlier versions can reintroduce the issue to model(s).

Q. What is Autodesk doing to resolve the issue?
A. The Revit team has reproduced the issue and is actively working on a build that does not contain this defect. In the meantime, we advise against installing Revit 2020.2 until the Revit team provides an updated build. To reduce the likelihood that customers come across this issue, we have temporarily removed Revit 2020.2 updates from Accounts and the Autodesk Desktop Application. Due to backend constraints a full install of Revit 2020.2 continues to be available from Accounts.

Q. When will a fix be available?
A. Thanks to the support of our valued customers, the Revit team has been able to reproduce the issue and has identified a fix. In the next few days we will be thoroughly testing the fix. Assuming all goes well, it will then take the team a few more days to make the build available in Accounts and the Autodesk Desktop Application.

Q. Revit 2020.2 has been available for months – why didn’t Autodesk communicate anything previously?
A. The Revit team was first made aware of a possible issue by our customers a few weeks ago. Since these kinds of issues can be difficult to reproduce from scratch, from the time a concern was raised we have been working closely with those customers to reproduce the issue. We were finally successfully able to reproduce, and therefore confirm, the issue at the end of last week when we took action to limit the availability of Revit 2020.2. We have been working diligently to clarify the full scope of the impact and the possible workarounds in order to write this communication.

Q. Why didn’t the Revit team discover the issue during pre-release testing?
A. Unfortunately because this issue requires a combination of model creation and modification of families in a previous version and then extensive modification to the same model in 2020.2 it does not lend itself well to typical testing practices or automated regression tests. This means that unfortunately, despite rigorous Revit 2020.2 testing, we were not able to identify the issue before it affected customer models. We sincerely thank the customers that escalated the issue to us so that we are now able to take appropriate action.

Q. What actions will the Revit team take to prevent this kind of issue from happening again?
A. After the Revit team resolves the immediate issue, we will be holding a retrospective to clarify how the defect occurred and what specific actions we can take to prevent similar issues in the future. As much as possible we will look to create automated tests to cover this kind of situation as that means that every future Revit code submission will be scanned for similar problems.

Linked DWG Xref Overlay vs Attached Bug - Part Two

Two options exists to work around this situation (last post). One is easy and Revit focused but depends on the AutoCAD user a little and the second is impractical and depends on the AutoCAD user entirely.

• Xrefs on their own layer
• Xrefs always unloaded

If we can count on the AutoCAD user being consistent to assign all of the file's xrefs to a unique layer not shared by any other elements then we can still turn off the overlay xref when it shows up. This shouldn't be too difficult to achieve and many firms already have that standard for xrefs.

If the xref's are always unloaded before closing a file then they won't show up in a Revit project. That's pretty unlikely. It's inconvenient for AutoCAD users and forgetting just once and the system fails.

UnHelpful Help Location URL

I read about quirky Reviteristic issue at RFO this afternoon. A weird graphics glitch occurs when we interact with the Help Icon families that use the URL parameter feature to reference an external document. This is an example of it in the sample architecture model that ships with Revit (rac_basic_sample_project.rvt - in imperial content).

When we select the icon and examine its properties we get this Learning Link parameter.

When we click in the field the small button appears with the ellipsis icon. Clicking on the that button will take us to the URL saved in family.

The trouble begins after we move our cursor away from the field and start to resume work. The URL is stuck on screen over another parameter like below, the Detail Number parameter for the view.

I noticed that I can work past the issue if I click in the Default Analysis Display Style field, which I presume works because it also has an navigation/ellipsis style button.

I also noticed that if I am careful to click on the field right above the Learning Link, called Location, before leaving the Properties Palette I can avoid the issue too.

The forum thread was talking about this in 2019 but these images are from 2020.2. 

Revit 2020.2 Internal Origin Part Three

John Pierson and Parallax Team Apps recently shared a solution at the Autodesk App Store called Internal Origin Hide-ifier. I thought mine was cool but it doesn't install itself or come with a Doge.

It's only 1,000 bucks...nope its free!! Check it out.

Internal Origin Follow Up

After I shared the earlier Dynamo graph I received an email from Aaron Rumple that did away with any package requirements. He wrote a python script and added it to my graph. It also eliminates the warning message that appears after running mine. The crux of that issue is the need to filter out view templates from the process because while view templates are applied to views under the hood they are also views...at least that's my layman's understanding.

Many thanks to Aaron, a real design software savant.

Download the new Dyn

As before, my graph allows you to include/exclude the internal origin, survey point and project base point. Just edit the settings of the Dyn before running it (see previous post).

Work Plane Based Families and Rotate w Copy

I participated in a thread at Autodesk's Revit forum and it took me far too long to catch on to the issue described at the outset. I should have retraced the thread sooner, but I did get there eventually.

I'm referring to the Rotate tool and its Copy option, this...

The issue boils down to this: the Rotate with Copy option works/affects a Work Plane-Based (and face-based) family differently than when a family is merely hosted by a Level (all non "based" families). Let's start here, imagine I want two screens on my desk like this.

These are stock families: TV - Flat Screen.rfa and Desk.rfa The desk has a top surface that isn't visible in plan view so it can't act as a face to host the TV. I changed that. The TV isn't a work plane-based family. In a plan view, when I place it on the desk it ends up eaten by the desk because it looks like this in a 3D view.

Sure, I can use its Elevation from Level parameter to put it on the desk (an illusion of a relationship). When I move the desk I need to remember to select the TV too (or make a group...or...I digress). I get the clever idea, "Make this family Work Plane-Based, that's easy!"

Using Rotate with Copy should give me the result I want in the first image and it does until I check the box for Work Plane-Based. The angle I decide I want between the screens is 22.5 degrees. I added a couple reference planes for the images to help see what happens, the desired result.

That's what I want except that they should be hosted by the desk, not relying on using the Elevation from Level parameter. When I use Rotate with the Copy option after editing the TV family to make it Work Plane-Based (also Always Vertical is checked) I get this result.

Notice the TV angle itself is correct but it's location is wrong...and a warning message appeared to help me notice... It's been moved/copied by double the input value of 22.5 degrees using the origin of rotation correctly and managed to maintain the angle I wanted. This next image summarizes what happened.

That's weird enough on its own but I can go weird by one more, un-check the TV's Always Vertical parameter. After running through the exercise again I get this outcome.

This time it applied the rotation input angle of 22.5 degrees x 2 = 45 degrees to both rotating the family and its position. This time it did it fully wrong while the previous time it only did it half wrong.

Introduce a Floor, instead of a desk family, into the mix and place the TV family before it is Work Plane-Base with Always Vertical and this happens. No rotation, just copy and in the same place no less.

When the TV family is Work Plane-Based and Always Vertical is used then it works wrong in the same way as relying on the desk's face as the host did.

I imagine Revit is attempting to relate the rotation and copy actions to the family's host, since that is the work plane the family is hosted by. Clearly it is unable to do so properly. I think it is reasonable to expect to get the same result whether level based or work plane-based. This post and the images are from using Revit 2020.2 but I did the same things in Revit 2016 with the same results. This has been around for quite awhile now.

If it is any consolation, the Mirror and Polar Array tools don't suffer from this malady but each have their own prep work required to make them a ready replacement.

Revit 2020.2 Internal Origin Redux

Happy Thanksgiving to those who observe!

One little thing I'm thankful for, I got a file yesterday from Autodesk (TurnOffInternalOrigin.Dyn) that is meant to be run in Dynamo Player (it's a custom node in testing ATM). You can download the file, place it wherever your Dynamo Player is looking for files already or in Dynamo Player just browse to wherever you placed the file. Click the play button (see image) and it will turn off the Internal Origin in all views. This approach means very little Dynamo knowledge is necessary, just enough to get Dynamo Player open and find the file.

Since I already put in some time with my own graph which included the Survey Point and Project Base Point I decided I'd like to be able to turn on/off all three or just the internal origin or some combination. I modified my graph (Control Coordinate Graphics.dyn) to provide input options (see image).

When you use Dynamo player you can edit the input options through On/Off switches (see image).

Click the little Properties button (looks like a old Macintosh computer to me). Clicking the toggle will make the statement either true or false for each "hide" question. All three true = all off for example. Remember my graph is dependent on a node from the Archilib package, make sure you've installed that before trying to use it.

Reference Planes without Names

It is a common practice to add a name to the reference planes we create. If it isn't common where you work then it ought to be. The name helps give a hint to anyone that works in the model that this reference plane is more important than those without a name. It can also help understand what it is for, why it was made.

There are some who make the effort to clear out reference planes that are not named periodically, just another of any number of model/housekeeping chores. I've even seen Dynamo scripts intended for this task.

If you're using Ideate's Explorer you'll find it easy to see a summary of all the reference planes in the model. In the following image I've created two reference planes, one with a name and another without a name.

Notice that there are five (5) reference planes listed though. As it happens, when the Edit Profile concept is used on a wall four reference planes are created and internally applied against the sketch of the wall. They are only visible to us while editing the wall's profile sketch. We can't see these reference planes in the regular user interface, it only becomes very apparent with their Explorer tool.

It is also possible for us to create reference planes while creating any sketch based element, like a floor or stair for example. These reference planes are only visible to us while editing their related sketch.

The reference planes associated with a wall's edited profile can't be deleted via IDEATE Explorer. It can delete them when we've created our own within a wall's profile and other sketch based elements.

Attempting to clean up these unnamed reference planes might also be an issue if you're writing your own code or Dynamo script to delete them. We can/could add names to these internal reference planes (wall profile) but I don't think that's a task that worth the effort.

Something to keep in mind.

Structural Column Disappears - Part Deux

Yesterday while trading messages with a friend we discussed my previous post about columns disappearing. He suspected it might explain the issue he was observing. After looking more closely it turned out that it doesn't. In his situation the structural columns were modeled the full height of the building and Join Geometry was used on walls, that passed through (overlapped) the columns, at each floor (level). The result: at some levels no column appeared while at others they do.

It was necessary to pull the walls back so they stop at the surface of the columns. Join Geometry allowed for the desired appearance and the columns reappeared at the other levels where they were missing earlier.

Structural Column Disappears in Detail View Type

When we create a Callout within a plan view we can choose between Floor plan and Detail. A structural column that uses a negative offset won't show up when a wall exists in the same location when a Detail view type is used. It works fine in a Floor plan view type.

Here are some example images. The first one is showing the negative offset used. If the offset is zero then there is no graphical issue, the column shows up.

This image shows both callouts in the overall floor plan, Detail on the left and Floor on the right.

This is the Floor Plan Callout, column shows up as expected.

This is the Detail Callout, no column is visible.

This is the same Detail Callout but my cursor is hovering over the column and Revit sees it, highlights it despite not being visible. The wall is masking the column.

This is the same Detail Callout but the view is changed to use Wireframe and the column appears.

It boils down to the negative offset applied to the column. The graphics hierarchy does not respect the full height of the column and the wall element is drawn over the structural column. We can also get around the issue if we edit the column family and remove the option: Show family pre-cut in plan views.