Lately we see this warning message appear, in BIM 360 hosted projects, when clicking the Save button (local) instead of the Synchronize with Central button.
Wednesday, April 14, 2021
Wednesday, April 07, 2021
A team was trying to override the appearance of the DWG layers after linking the file to their Revit project. Usually the reason for this not working is elements are not assigned to color or line pattern BYLAYER in the DWG.
In this case it wasn't working because the DWG was not within View Range's Primary Range, it was in the View Depth zone. Projection and Cut linestyles work inside the Primary Range and the <Beyond> linestyle is used for elements within View Depth.
Good catch Mia!
Friday, April 02, 2021
If you've found rogue RVT links in your model it might be Transfer Project Standards (TPS) and View Templates to blame. When you need a View Template from that other project you're working on you run the risk of adding RVT links to the project's database. You'll find them listed in the Manage Links dialog but if you try to reload them Revit will tell you there aren't any instances placed.
This happens when a View Template manages overrides to those linked RVT files in "that other" project. Just remember to check Manage Links after using TPS (reports, haha); otherwise this Gotcha will Getcha.
Hat tip to Alexis Kotzambasis for identifying this issue.
Friday, March 19, 2021
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?
Thursday, March 18, 2021
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.
Wednesday, March 17, 2021
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.
Monday, March 15, 2021
"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...
Sunday, March 14, 2021
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.
Saturday, March 13, 2021
Wednesday, January 27, 2021
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.