Showing posts with label links. Show all posts
Showing posts with label links. Show all posts

Friday, March 19, 2021

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



Wednesday, January 27, 2021

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.

Wednesday, August 22, 2018

Remember Linked Files Have Two Workset Parameters

I find this overlooked regularly. Each link has an Instance AND Type parameter called Workset. If we select a link (RVT) in the Project Browser we can see the Type parameter for workset, even if the link isn't loaded.


If we right-click and choose Select All Instances > In Entire Project we can see the Instance parameter value, unless there is more than one instance (copies of the link).

The best way to ensure that both parameter values are assigned to the same workset is to make sure the Active Workset is set correctly first, before we link the file. If not then we have to check both values.

Why are there two parameters?

The Type parameter governs the existence of the link in the database while the Instance parameter governs the actual instance you can see in the model views. The linked file can be copied, for example House Design A can be copied so we can show that it will be located on several lots within a development, each likely oriented differently.


The instance parameter allows us to assign each copy to a unique workset while the Type parameter affects all of the copies. That means closing the workset assigned to the Type parameter will close all of the copies of the link, none of them will be visible.


If we close the workset assigned to just one copy then only that linked file won't be visible.


If we experience erratic issues with linked file visibility it is the first thing I check. I'm also in the habit of looking at all the linked files every time I get introduced to project. This also applies to other linked files (CAD,Point Cloud).

Thursday, November 24, 2016

Publish Coordinates and Inter-related Linked Files

I frequently have models that are organized in/by what I call a Master Site model/file. This file is the Parent in the shared coordinate relationship for all the children/siblings models/buildings that I link into it.

When model positions are changed in this parent file I find it is sometimes (often) necessary to use Publish Coordinates on all the linked models, even those that have not been altered. I've observed inconsistent results where sometimes the location of a linked sibling does not adjust (update) when viewed (as a link) within another sibling model. Using Publish Coordinates seems to force these linked files to refresh properly when a model is opened, even though it might seem unnecessary for those that didn't change.

As such, it is possible that seeing other linked files appearing to be out of alignment for this reason may motivate us to try to reset everything. Pause, breathe...try using Publish Coordinates on all the links first.

Friday, October 14, 2016

Schedule Linked Files and Current File

I wrote an earlier post describing a way to create a schedule of linked files. I read a thread at RFO asking about including the current file in the schedule too. I can use the same approach to get that result too. This is a schedule of Levels (since all projects have at least one).


The schedule will naturally reference levels in the active file and I only need to check the Include elements in links option to get their levels too.

The query at RFO also dealt with custom file naming so I took advantage of the built-in Project Information parameter called Building Name. In each project file I've entered a custom File Name in Building Name. This example is using the format described at RFO. I also unchecked the option for Itemize every instance to avoid having many rows for each and every level in the files. I used Clear Cell to eliminate the Title (also turned off that option in Appearance) and used Hide Column for all the fields except Building Name. For this to work long term we need each trade to include this same piece of information in their model/file and update it when they post their next version.

Friday, August 12, 2016

Selection Box and Linked Models

I was just thinking that it seems unfair that the Selection Box (reasonably new feature) goes to sleep when you select just a linked file. Maybe I want to crop the 3D view down to just that link? That's when I realized that I happen to have a scope box around the link already. Select the Scope Box and then use Selection Box - et voila!

Yeah, I'm writing as if I didn't just go two months without so much as a by your leave...things have been...hectic, yeah. That's my story...

Thursday, May 05, 2016

Getting Started with Collaboration for Revit (C4R)

Below are a couple of links that describe the process for getting your project started using Collaboration for Revit (C4R).

It all begins with creating a project using your A360 account/subscription. Naturally you've got to create an account first so this assumes you've done that. The linked page also explains how to upload your current project to the A360 project if necessary.

If you're responsible for putting your active file on the A360 Project, READ ME, it has a video too.

There is a ton of information lurking at Autodesk, just use your Google-fu.


Sunday, February 21, 2016

Clearance Subcategory in Linked Files and Families

You've linked a model that has families which include clearance elements. That's excellent for doing clash detection. However you may not really want to see the graphics they've provided for this in all of your own documentation views.

Hopefully the clearance elements have been assigned to a unique subcategory that you can control by overriding the link's Visibility/Graphics.


If so and you'd like to control the subcategory without overriding their linked file you can use Copy to Clipboard on one of the families (TAB to select it) with the clearance elements in them. Then paste a copy somewhere in your model. Now the family's subcategories are part of your own model. You'll be able to control it via V/G without overriding the link, assuming the link is assigned to By Host.


You probably realized that doing the above is a shortcut to creating a matching subcategory assigned to the correct category in Object Styles ourselves. It is a shortcut because we probably won't know what subcategory the family is using without examining the family more closely, by opening the linked file and editing the family directly. Using Copy and then Paste provides us with a copy we can interact with directly instead and any subcategories it has are brought into our project for us.

Families are prone to inconsistency because they can be obtained from a variety of sources. Consider that even the families from Autodesk aren't entirely consistent from one to another. It may still be necessary to crack open a family to find out how their clearance elements are controlled. For example, the lines that form the "X", and the "box" around them, in this family are assigned to the Hidden Lines subcategory, not Clearance.


In 3D there are forms to indicate clearance requirements and they are assigned to a Clearance subcategory but they also have their Visible parameter unchecked which means we can't see them in the project at all, anywhere.


This family does not intend for us to turn off the clearance "X", at least not via its Clearance subcategory. It has a subcategory called clearance and the solid forms for its clearance zones are assigned it but then it was decided they shouldn't be visible at all. By the way, doing so does not prevent Revit from seeing the clearance forms when using its own Interference Checking. However in Navisworks they don't show up. That might be considered bad form (pun intended). From a family editor perspective (and user), it would have been more flexible if the Visible parameter had been associated with a Yes/No parameter to allow us to turn it on or off if necessary. Unfortunately, keeping in mind that this post began about families in a linked file, it wouldn't make any difference for us.

Consistency is easier to manage and achieve when it is your own content library and your project files. It can be a bit trickier dealing with the content that is part of the linked files you need from other disciplines. It's easy to create a family that makes me happy, or my team. It may not make the other consultants happy though. Something to think about while you're being happy making content.

Tuesday, April 07, 2015

Survey Point - Post 4 - Acquiring Coordinates and View Orientation

The bias of the last three posts has been on creating a Master Site file and linking building models to site. That's moving buildings on a fixed site versus moving the site under fixed buildings. The earth doesn't go anywhere, we put buildings on it, so to speak. That bias feels right to me, the ways things really work.

These are links to the three preceding posts.


If you choose to take the reverse approach, link the site to a building, you have to adjust the survey information to align with the building; since its harder to move the model elements around than the survey file. In this example, I've started in a Floor Plan view assigned to Project North.


At this point is doesn't look much different than images early on in the other posts. The building is oriented conveniently for putting in on sheets. I need to move and rotate the survey DWG into a better orientation. I'm using the same preferences I had in the previous posts.


Now I just need to shift the survey down since the contours are at their actual elevations and the building model is at an arbitrary ground floor elevation of zero.


I used the same 22 feet for the ideal ground floor elevation I chose in the other post.


Now I'm ready to use Acquire Coordinates. I opened up both the floor plan and site plan views so I can see the change occur. I used Acquire Coordinates in the floor plan: Level 1 (that's significant...in a moment).


Since there are few possible combinations of actions, let's imagine that I used Acquire Coordinates a little differently. In this case I Acquired Coordinates in the floor plan view: Site and I wasn't observant enough to notice that the view is assigned to Project North which ordinarily wouldn't make sense to do, to me at least. It's easy enough to overlook because at this point the building orientation is technically the same as it is in other views assigned to Project North.


After I Acquired Coordinates I noticed the view didn't change so I realize it needs to be assigned to True North. I do that and the model rotates to show the orientation based on the survey's coordinate system, as I expected initially.


Now a little time passes (we're pretending). I find it necessary to use Reload to update the linked survey file, maybe I cleaned up some of the layers to make it a little lighter in our model. When I click Reload this happens. The survey spins out of alignment.



The cause is subtle and simple: it is IMPORTANT to respect the Orientation parameter setting used, in the view that's used, when Acquire Coordinates is used. If you change to the opposite setting and then Reload the link the orientation of the link will change undesirably; regardless of the view you happen to be using during the reload process.

To restate the cause and effect, I used Acquire Coordinates in the Site view while it was assigned to an unnatural orientation setting of Project North. I then changed it to use the more logical True North but AFTER I already used Acquire Coordinates. This means I have to remember to change it back (to Project North) EVERY time before using Reload on the Linked survey file... Or I fix it, which would require resetting the coordinates so I could Acquire Coordinate again with the better settings in place.

I believe this is another good reason to use a separate Master Site project file. The survey is linked and moved into position but it isn't rotated to reflect True North because UP is North already. The quirk I've described only affects the links rotation and there is no need to rotate it in the Master Site strategy.

Friday, May 30, 2014

Insert using Auto-Center to Center

Whenever we insert a linked file we find that Revit is wired or biased to using Auto-Center to Center. It doesn't matter if we've just used another placement option Revit faithfully returns to its favorite.

The reason for this preference or bias stems from the reality that DWG files are a perfect storm of chaos that we cannot reliably expect that the elements in the file are located near the origin of the file. Floating Point math calculations rely on constraining the size of the world we work in to a practical scope so that calculations can be "accurate" enough to roughly 12 decimal places. Revit uses double precision which technically extends to 16 decimal places but it only displays 12.

When elements in the imported/linked file are very far from the file's origin then Revit's ability (of all CAD software by the way) to accurately display and describe information begins to suffer. The Revit development team is a bit more fussy about this than how other software confronts us with this concern. One visual clue that this is affecting your project is snap icons fail to appear directly on the element it is related to.

Using Auto-Center to Center is safer from the developer's mindset, protecting us from BadCAD and or ourselves.

Now we've been bringing this up for years, asking for Revit to remember what we've used before and/or letting us set which option we prefer. The good news, from my perspective, a recent conversation with someone at Autodesk has made me optimistic that we will get our way sooner than later.

Tuesday, January 21, 2014

Accuracy

Every now and then we get nervous about the results we see in schedules or in dimensions. I received an email a few months ago asking about an error they observed in the length of a wall. They exported from Revit so they could examine the model against others with Navisworks. They saw a wall that is 10 meters long reported a length of 10.000000000001 meters in Navisworks. That extra one would need a lot of friends to add up to something we could actually see with our eyes. It's still worrying?

A thread at RFO today popped up regarding the accuracy that dimensions were showing. In this case the project units were adjust to 12 decimal places too. The dimension was reporting extra info in the 12th digit too. I replied there that it's a floating point math issue. I also wrote that I believed that Revit only calculates to six digits places but limits displaying values to 12 digits. I was wrong and you'll see what Leonid explains if you follow the link in a moment.

Chris replied with some great links, one of which I remembered reading but couldn't recall where (AUGI naturally) at the time. This is one where Leonid and Irwin weigh in on Accuracy (Revit Founders).

Regarding that thread at AUGI I particularly liked Irwin's explanation of the magnitude of the error being discussed. He wrote:
...The difference you are seeing is approximately one part in 10 to the 14th power -- it is around one ten thousandth of the diameter of a hydrogen atom. Revit uses double precision numbers for all calculations (as do all CAD systems), and they are only good to around 14 or 15 digits.

Regarding your concern about angles, if an error of this magnitude were introduced into the angle between two walls, and the length of the walls was the distance from the Earth to the Sun, then the error in the distance between the ends of the walls would be around 1 mm...
These are the other links that Chris shared:

Lahey - Floating Point
Double Precision floatin Point format - Wikipedia
What Every computer Scientist should Know about Floating-Point Arithmetic. Warning Chris says it may hurt your head!

From the Lahey site I found this snippet interesting (with my added emphasis):
...Floating-point representations and arithmetic are inexact, but I don't believe that is particularly troublesome to most programmers. Many input values are measurements, which are inherently inexact, so the question about the output values isn't whether there is error, but how much error should be expected...
And this (keeping in mind these are written from a programmer's viewpoint):
  1. Only about 7 decimal digits are representable in single-precision IEEE format, and about 16 in double-precision IEEE format.
  2. Every time numbers are transferred from external decimal to internal binary or vice-versa, precision can be lost.
  3. Always use safe comparisons.
  4. Beware of additions and subtractions that can quickly erode the true significance in a result. The computer doesn't know what bits are truely significant.
  5. Conversions between data types can be tricky. Conversions to double-precision don't increase the number of truely significant bits.Conversions to integer always truncate toward zero, even if the floating-point number is printed as a larger integer.
  6. Don't expect identical results from two different floating-point implementations.
My general observation is that it is much more complicated than we think it is to codify the stuff we take for granted, so called simple things like a dimension of 4'-0" or an area value like 12.53 SF.

Monday, October 01, 2012

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


Thursday, December 08, 2011

BIM Content Echo

Quick post tonight, James Van put together a post the other day to provide a list of resources for Content. I've got a similar listing on my blog here too but I've been letting it slide for awhile now. Good list and now I've got a nice place to get any that are missing on my page too! :)

Friday, December 10, 2010

OpEd Links Broken for AUGI Forums

I realized last week that I've got over a thousand posts on this blog now since I started it at the end of 2004. Over these past years I've created a fair number of links to other sites. Seems like a good idea because I can just point readers to another spot easily. That is until that site either changes something, the information just goes away...or in the case of AUGI the forums, the domain name service (DNS) isn't pointing at the same server anymore. While AUGI sorts out the details of that situation my posts here have an untold number of broken links. When the forum data is migrated into AUGI at some point I have no illusion that my original URL's will still work. It would be wonderful if they do, or if even some of them do...

Long story short...if you click on a link that promises to take you to a AUGI forum post/thread...it's more than likely to generate this message.


In fact any bookmarks or shortcuts you have created to get to certain parts of the AUGI site will generate the error too. I've received more than a few emails from people about their bookmarks and shortcuts not working anymore.

An aside, reading through the posts at AUGI the past few days I get the impression that members believe that AUGI has a very broad presence in the industry. Seems reasonable based on our combined involvement with AUGI but oddly enough in my travels during the last 6 years the one consistent thing about AUGI is how FEW people have actually heard of it. Stepping in a room of +/-10 architects/engineers about 40 weeks a year I've been surprised to find that at the most one or two are members and often none are. As for those who aren't members most of the time they haven't even heard of AUGI. Considering I do nothing but Revit and Navisworks consulting I've always expected people to be pretty aware of it. So as prolific as the Revit community has been at AUGI it is surprising to find how few are actually aware of it. What's my point? Just that we aren't nearly as famous as we think we are? 8-)

In a recent post Alan (blog: Revit Structure Learning Curve) mentions a survey completed by NBS (National Building Service in the UK) that suggests that about half the "industry" is aware of BIM. I wonder if the survey should be run asking about awareness of Revit instead? I'd be curious if more are aware of the product than of the concept. The reason I mention this is that it is like AUGI in a way, as hot or as relevant as something seems to me, there is always a group of people outside of it all. Unaware or even uninterested.

Even further off topic! I also read that Chris Zoog (founded the Revit forum at Zoogdesign which merged with AUGI in 2004) would be rolling over in his grave (regarding the forum data issue). Rumors of Mr. Zoog's death are greatly exaggerated. If he were dead perhaps he'd be rolling...many years we must wait for that. I for one would be very disappointed if the rumor were true!

Tuesday, April 21, 2009

Revit 2010 - Unresolved References

When Revit opens a project and can't find files it has always told us so. The dialog that it presented in the past and now are different. With 2010 we get this instead.

The language used is better and provides a bit more information. If you click on the Show Details button you get a much more readable listing of the offending files (refrained from that screen capture to protect the "guilty"). The addition of the option to immediately deal with them is also welcome though I suspect most users will just defer that to someone else?

[Added: 4/23/09] For more discussion on the subject of this Task Dialog you can visit a post that was apparently inspired by this post.

Wednesday, January 28, 2009

Reviteristic - Revit Links are More Important?

When we link a Revit model into another project file there are number of instances where the linked model seems to interfere with selecting elements that are actually native parts of the model. I encounter this the most when I'm working with Revit MEP.

For example, using the Create System option for an Air Terminal the option to Select Equipment seems to only have eyes for the architectural model and it can be nearly impossible to select the very nice Single Duct VAV box right in front of you.

What to do? Well you could write a blog post like this and complain to start 8-).

If you change your view to Model Graphics Style: Wireframe you'll find that Revit is no longer as focused on the linked model. Another solution is to have a view with the linked model and another where the link is not displayed. When you are ready to create your systems just switch to the other "cleaner" view and no such issue.

Happy selecting!

Thursday, August 21, 2008

Helping Yourself - Ask Questions the Smart Way

I followed a LINK that Kyle Bernhardt (Autodesk Revit MEP Technical Product Manager) included in his signature at AUGI. This site is a compilation of advice for anyone interested in communicating with "hacker" community.

Eric and Rick are the authors of the site, called "How to Ask Questions the Smart Way", and they start out with this Introduction Section (after the table of contents that is...)

In the world of hackers, the kind of answers you get to your technical questions depends as much on the way you ask the questions as on the difficulty of developing the answer. This guide will teach you how to ask questions in a way more likely to get you a satisfactory answer.

Substitute "Revit" for "Hackers" and you get a pretty similar sort of "lesson" about how to communicate to online forums members for Revit.

They also include the following disclaimer on their site:

Many project websites link to this document in their sections on how to get help. That's fine, it's the use we intended — but if you are a webmaster creating such a link for your project page, please display prominently near the link notice that we are not a help desk for your project!

We have learned the hard way that without such a notice, we will repeatedly be pestered by idiots who think having published this document makes it our job to solve all the world's technical problems.

If you're reading this document because you need help, and you walk away with the impression you can get it directly from the authors of this document, you are one of the idiots in question. Don't ask us questions. We'll just ignore you. We are here to show you how to get help from people who actually know about the software or hardware you're dealing with, but 99.9% of the time that will not be us. Unless you know for certain that one of the authors is an expert on what you're dealing with, leave us alone and everybody will be happier.


I found the site an interesting read...perhaps you will too?