Changing and updating Shared Coordinates in Revit can be quite a challenge. At Virtual Built Technology we often create a Revit Control File to manage and transfer project datums, shared coordinates and other compliance items for the project team.
This video describes the techniques and challenges involved in updating and instituting shared coordinates on a Revit project. It also includes the steps involved in adopting other Revit modelling standards and requirements into your file.
Here are some of the tips included in the video:
how to un-share coordinates for linked models
how to acquire new coordinates
checking that coordinates are correct for linked models
using Transfer Project Standards – Project Info as a method of fixing coordinates
other model compliance steps including: updating base point settings, transferring Phase Settings, loading a Start View for the project
copying locator elements
copying scope boxes
using Dynamo to automatically generate the required worksets for compliance
I have developed a working BIM360 to on-premises backup mechanism. There were a few different ways to go…
I initially considered:
Hacking Windows Explorer to touch the files in the BIM 360 node and try and trigger the BIM360 Docs download and copy to local PC or network location
Developing a Forge app that essentially pulls the desired models out of the BIM 360 cloud to desired location?
In the end, I decided to use the Revit API (Dynamo and Python), along with VirtualBuiltApp, to essentially reverse engineer a folder structure from the local CollaborationCache folder. These ideas are hinted at here.
In simple terms, the BIM 360 Docs on-premises backup workflow is:
Create a super federated BIM 360 model (with all other BIM 360 models linked into it)
A Dynamo script reloads all links in order to cache them locally
The same script interrogates, then determines the target file name and folder from VirtualBuiltApp
Dynamo then copies the files into their ‘backup’ location on the local network
Some more detail is presented below:
A) Cache Cleaner CMD Script (may not really be necessary, as the ‘reload’ should overwrite superseded cache anyway):
Kill Revit if Open… be careful of below steps, particularly if Revit has crashed recently. You might need these local copies 🙂
cd "%LOCALAPPDATA%\Autodesk\Revit\Autodesk Revit 2018"
for /d %i in (*) do move "%~i" oldCache
B) Manual steps to setup Revit model environment to run the script:
Open Federated BIM 360 file (worksets closed)
Unload all links
Open all Worksets
C) Dynamo Script:
Run Dynamo (Python) script that reloads and unloads all links (this collects .rvt into cache). Key Python commands to use are: RevitLinkType.Load() and RevitLinkType.Unload(None).
Coordination Monitor alert, no longer exists
Instance of link needs Coordination Review
“Some numerical data within the imported file was out of range. This numerical data has been truncated.”
“Geometry in the file … has extents greater than 20 miles (33km).”
I came across this link to a Dynamo seminar by Sol Amour delivered in Wellington about a month ago. I have had a bit of contact with Sol over the years and he is a Dynamo pro. Cool to see that Dynamo Nodes got mentioned too.
The Revit API is actually something pretty special. People will go on and on about how Revit needs this feature or that feature, but the fact is that you can build almost any feature you like with the API. Recently, I have been running quite a few batch operations from the scope of a federated Revit model: so I will have one RVT file, with hundreds of Revit links, and I will process them from that main federated model.
On one recent project, we had to deliver to a Client a linked dataset, with Revit link file paths resolving correctly. As you know, people work in many different IT environments, and the pathing of Revit links may vary widely.
I set up an ‘approved’ list of Revit file paths, that looked something like this:
I knew that in Dynamo with Python I could get a lot of information about linked files using the ExternalFileReference class. What I discovered during this process is that there is a TransmissionData API class that let’s you do some pretty interesting things…
You see, I was thinking I would have to set up a batch method to open this files, change the file paths, and close them. But the TransmissionData class is basically what is implemented in eTransmit for Revit – it allows you to ‘lightly touch’ the Revit file and simply change the Revit link paths, and also set a switch saying ‘this file has been transmitted’. This puts the file in an appropriate state for re-opening in the new path environment. Pretty cool huh?
Once I figured out how to implement those TransmissionData actions in Python, I just had to build a node that, running from the federated model:
examines each link for the links inside of it
replaces erroneous paths with the correct file path
sets the new paths to the file
I did this in the hacky way of a “counter with List.Map” in Dynamo. In the future I’ll probably fix it up to be a ‘proper’ Python script but this works for now. In about an hour it fixed the linked file paths of 600 Revit links, all with the click of a single button 🙂
I had a good time at RTC back in 2016, it was awesome to catch up with the usual BIM crew and see what they are all up to. Hopefully I’ll get a chance to post in more detail about a few things I learned this time around… but for now, here are my 2016 presentations for you to check out.
My keynote presentation slides (why BIM is broken and how to fix it…)
My Dynamo presentation slides:
And the Revizto session that I ran with Michael Clothier:
– API Stabilization: 1.0.0 is a commitment to stable code that allows for smoother and more reliable movements from one version to another. To more clearly express this, we have been moving to “semantic versioning” to illustrate the nature of changes in each release. We will be using the fairly standard version naming with an x.y.z system, where x incrementing represents breaks to the API (requiring developer refactors), y indicates changes that are still backwards compatible, and z are smaller bug fixes. Package creators and maintainers are encouraged to assess changes to the previous code, which can be found here
– Graphics performance enhancements: see this post for details
– Documentation: Along with new sections of the DynamoPrimer (http://DynamoPrimer.com), we have started an online documentation of the Dynamo API with a searchable index of public API calls for core functionality. This will be expanded to include regular nodes and Revit functionality. http://dynamods.github.io/DynamoAPI/
– Licensing: Dynamo Studio is now using a new version of the Autodesk installer that allows for easier access to network and token flex licensing tools
– Install: we have created a separate installation for “core” Dynamo functionality, those tools used by all implementations of Dynamo, and Revit, and Studio installations. This allows for the sharing of a common core of Dynamo code and packages.
– List Management: Changes to “replication” or automated matching of different data streams in nodes and Code Block nodes eliminates the need for List.Map and List.Combine in many situations
– Send to Web: formerly known as Share Workspace, we have improved the ability to view and interact with Dynamo online with Customizers
– File Export: Users can now author DWG files in the Translation section of Dynamo Studio.
– Direct Shape: Dynamo in Revit 2017 can now take advantage of faster and more sophisticated direct shape creation. In most cases, solid and surface geometry can be sent directly into the Revit environment as smooth (rather than tesselated) surfaces and solids, categorized to whatever is needed. In the cases where a smooth element cannot be created, a tesselated (mesh) object is created, as was the case previously.