A while back on the There’s no BIM like home, there was a very interesting post that aimed to use simple language to describe BIM projects and process. According to the author, the XKCD Simple Writer Tool was used to develop the text. Some of the ideas are somewhat UK centric, but the overall concept is great. Here is just one paragraph:
After a builder wins the job, they plan with their team what parts of the job they will do [responsibility matrix], what information is needed and by when [master information delivery plan], as well as how information needs to be set out [standards, methods, and procedures]; writing all of this into a single agreed plan for everyone to follow [post contract-award BIM execution plan]. To make sure everyone can follow the plan, the builders check their team’s skills [supply chain assessments] before starting the job.
In BIM world, we can certainly get carried away with terminology and abbreviations and acronyms. But this is a good reminder that much of our work can actually be described in easy-to-understand language. Check out the full post by author Dan Rossiter at this link.
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 🙂
BIM always makes sense for Healthcare projects, and in my opinion BIM will eventually make total sense for FM and Building Operations. I am deeply embedded in a few projects that are spanning across BIM, FM and Healthcare, and so I was especially interested in this whitepaper:
First Steps to Successful Deployment of BIM for Healthcare Operations
One particular comment really resonated with me, and I have copied it here below:
As Meghan Ruffo, contract BIM manager, Carolinas Health System, points out, tools can be added over time to process additional data. “Don’t think you have to have a perfect system set up to get started,” she advises. “Say you don’t have a space management system that integrates with Revit yet. You can still capture that information, and when you do implement that tool you will be ready to go.”
The paper aims to provide market insight into organisational strategic issues and the role and functions of project managers in BIM implementation. The paper also looks to the future, at how roles might evolve as BIM continues to develop.
I tweeted this today and I thought it was worth a repost here for all the Facebook and LinkedIn followers…
There are no LODs.
There are only:
Design Models,
Construction Models, and
Operations Models
What does the above statement mean?
Firstly, that if you are going to try and standardise something you need to make it simple and practical. Secondly, the content of a BIM dataset is best described by its current purpose. It won’t always be a Design model. Once it starts to become a Construction Model, the Design Model needs to die or be used only for crude reference. And once it becomes an Operations Model, it may need some extra data added, but it will likely need a lot of Design and Construction junk removed.
Don’t try and make a model that lasts forever, for every purpose, and then attempt to standardise that as a point-in-time deliverable with some ridiculous metrics.
Make the BIM standards simple, practical, and closely tied to the current purpose of the model.
BIM documents andfiles are often linked into each other, such as consultant links in a contractor Revit model, or plain NWCs appended to a master NWF Federated coordination file. In each case, the BIM application will try to find and open the linked files when opening the host model.
However, this only works if the pathing is predictable (ie. ‘the file is on C drive in folder MODELS’), and the typical situation is that you are running a corporate LAN that gives secure access to one or more mapped network drives (J drive or H drive or L drive). The problem is that your corporate LAN isn’t typically accessible via the cloud. A number of products exist to try and solve that problem, such as Citrix ShareFile.
But what about Box? It has a reliable, proven infrastructure and apps for all of your main devices. Its scalable and essentially secure. But… What about the mapped drive problem?
As part of our work at Virtual Built, we come across problems and provide solutions for this kind of issue all the time.
Here is how you can shareBIM via the Box cloud andretain file pathing:
The first thing you will need is a common drive letter that can be applied to all of your computers and workstations. Sometimes, you may already have a secondary drive installed, perhaps with a drive letter of E. What we are going to do is point the BoxSync app at a subfolder of E drive, and then all the members of the team will use E:\BOX\BoxSync\ as the ‘root’ for all shared documents and models.
First problem: what if we don’t have an E drive (secondary hard drive or partition)? Well you can trick your system into thinking that you do…
On C drive, make a root folder called C:\E_DRIVE
Right click this folder in Windows Explorer and enable Sharing
After sharing is enabled, you can ‘map’ the local folder as a drive. When mapping, use the local computer name with two backslashes, followed by the folder name.
Shared
Mapped drive to local folder
Now, we install BoxSync 4. After install, you will have one opportunity at first run to set the storage location. We choose to use E:\BOXas the folder…
That is basically it! Now, BoxSync will sync your models and projects from the cloud. When you set up your models inside that root folder (E:\BOX\BoxSync\), then the Revit linksand Navisworks NWCs will all be able to ‘resolve’ properly on each system that you set up in this way. Then, when you save changes in that location they will then be synced back up to the cloud and down to your team, all automatically.
Important Note! There are a few big things to consider:
This does not give simultaneous modification access, such as for a Revit central file. If you and someone else modify the same file, Box will probably save two versions with your username appended.
You may be essentially opening up Local PC Access to the data in your Box folder (because it is no longer in a Windows-controlled appdata location). So be aware of the implications of this…
Box tip: You may also want to check your Logs folder for some big files:
Originally publish Mar 02, 2016 at 19:37 by Luke Johnson