Revit: Moving a Grid Line with Disjoin Checked (Don't Do It)

Made a discovery today, related to the previous post regarding moving items with Disjoin checked. Once again, I failed to notice that was checked. This time I was experimenting with Copy/Monitor. I set up a structural model with some Grids. I cross-linked the structural and architectural models, and Copy/Monitored the structural grids in the architectural model, from the structural link. Then I moved one of the Grids 2'-0" perpendicular to its length and synchronized the change.

Back in the architectural model, I reloaded the structural link and, as expected, was told that there was a Coordination Review for a link. I ran the Coordination Review for the structural link, and, unexpectedly, was told that an element was deleted (not moved!). This was confusing, because I could see the grid line from the structural link; it was there. I did it all again, with the same results. I decided that since it was after 5:00 pm, I would save my models and try again tomorrow. I went to move the grid in the structrual model back to its original spot so I would be ready to roll tomorrow, when I finally noticed that the Disjoin toggle was checked on the Options bar. Remembering my previous problems with moving Views on a Sheet, I cancelled the command and checked the Revit ID number of the Grid. Then I moved it, with Disjoin still checked, and checked the ID number again. It was different!

So it turned out to be operator error (or, more accurately, operator ignorance), rather than a glaring bug. I am willing to own that; in fact, I am glad that is the case because I can fix operator error/ignorance. And I am glad that I figured the issue out in far less time than the previous one took. I just have to get myself to check the Disjoin toggle whenever I use the Move tool, because Move + Disjoin = Copy + Delete Orginal.

Revit: Moving A Legend on a Sheet Deletes the Legend

I was trying to move a Legend on a Revit sheet a precise distance, so I was using the Move tool rather than dragging it and eyeballing the location. Instead of moving the Legend, Revit deleted it, and issued this warning:

There was no second instance of the same Legend. If there were, why delete all of them? Some on-line searching turned up a case where someone had a Section view deleted from a Sheet when they tried to move it. The offered solution was to look at the Options bar after selecting the Move tool and to uncheck the Disjoin toggle if it were checked. It turns out I did have the Disjoin toggle checked, and unchecking it allowed the Legend to be moved as desired, with no deletion and no warning message. I do not understand why having Disjoin checked caused Revit to think there were multiple instances which then needed to be eradicated, but I am glad that I was able to find a way to do what I wanted to do.

Revit: Choosing a Maximum Value in a Formula

Nothing earth-shaking here, just recording this so the next time I need to do it, I do not have to put it together from scratch. The formula to get the larger value of two parameters is relatively easy:

if(A > B, A, B)

But if you need to pick the maximum value of three parameters, it gets a little trickier:

if(A > C, if(A > B, A, B), if(B > C, B, C))

Expanding that to the maximum of four values requires something like the following:

if(A > D, if(A > C, if(A > B, A, B), if(B > C, B, C)), if(D > C, if(D > B, D, B), if(B > C, B, C)))

I am hoping I will not ever need to get the maximum of five or more values.

Revit: Upgrading Family Files

I found this sitting in my Drafts folder. I have no idea why I held back on publishing it, so I am doing so today (2024/4/8). My firm now has a content management system that will upgrade families to future versions, but I still think this is a handy node.

A huge shout out and many thanks to John Pierson for the Batch.UpgradeFamilies node in the Rhythm package. Have a large number of family files to upgrade to a new version of Revit? If you do not have a content management system that handles that chore for you, open the target version of Revit, fire up Dyanmo, pop in the Batch.UpgradeFamilies node, feed it a text string of the path to the root folder for your content, and select the Run button. You can then sit back and watch Revit background open, upgrade, and save every RFA family in that folder and all of the folders below it. Or, more likely, get on with some other task while that is taking place. The best part? It also deletes the backup files, leaving you with just the upgraded file.

It will tie up that version of Revit while it processes the files, but it will do it much faster than you could do it manually, and without the strain on your hands, wrists, and - most importantly - head. It does not get any better than that.

ACA: Deployment for ACA 2022 - Cannot Remove Custom Profile

Finally had some time to start preparing for the creation of a deployment for AutoCAD Architecture 2022. This is the first deployment for an AutoCAD-based product that I will be creating on the new, web-based system, as we typically only deploy every other year. I worked my way through the limited options under Customizations and came to the last section, Custom Profile. We have multiple custom profiles, one for each discipline, and did not try to include those in the deployment previously. I wanted to see if more than one could be added. I exported profiles to two test ARG files, and added one of them, then tried to add the other.

I quickly found that you can only add one; attempting to add another replaces the first one with the second one. All well and fine; all of the text related to custom profile is singular. What prompted this blog post, as a note to my future self, is the fact that there does not appear to be a way to remove a custom profile once you add one. So it looks like I will be trashing what I have done so far and starting over.

Revit: BIM 360 Model Synchronization Error

A user had a curious synchronization error today, on a model hosted on our BIM 360 hub. He emailed me the screen shot below.

I did not know what to make of this - of course the [insert ridiculously long GUID here].rvt file already exists! That is the file he was synchronizing, and had been synchronizing successfully all day, up to that point. And why ask the apparently rhetorical question, "Do you want to replace the existing file?", when there is no opportunity to respond to it? I was perfectly willing to trash the backup versions, as we have not had need to try to pull backups from someone's local cache on a BIM 360 project. (And thank goodness for that, as it is a royal pain just figuring out which [insert ridiculously long GUID here].rvt file is which.) A quick Google search did not generate any useful leads on how to proceed.

I walked over to the indivudual's workstation, repeated the error for myself and got lucky. After dismissing the failed Sync With Central dialog, Revit displayed the ever-popular "You have not saved your model recently" nag dialog. Before I could utter the snarky thought that immediately came to mind, I chose to click on Save. I got another dialog, with the same question about losing backup versions, but this one had Yes and No buttons. I said, yes, save it, and it did. Then I tried to synchronize again, half expecting that Revit would tell me the local was now incompatible with the central, but it synchronized just fine, resolving the crisis.

Dynamo: Pin All Revit Links

I have been setting up projects that have a larger than usual number of Revit links in them, and to save myself the bother of having to remember to pin each one after placement (and the bigger bother of repeatedly checking to make sure I did not miss one), I created a graph to pin all of the Revit links in the current model. The graph is rather simple, if you have the Orchid package installed and can use the Element.Pin node contained therein. I was using Revit 2020; those using other Revit versions will likely need a different version of the Orchid package.

This runs nicely in Dynamo Player. No need to select the Edit Inputs tool, as there are no inputs to edit.

Revit: Controlling the Initial Open/Close State of Worksets When Opening A Model with the Specify Worksets Option

Apologies for the wordy title on this post, but I want to be absolutely clear that I am NOT talking about how to make the Specify option the default option when opening a Revit model (that is covered in this Autodesk Knowledge Network article). I am talking about the open/close state of each Workset in the Opening Worksets dialog once the "Specify" option is used (either by default, or because you chose Specify by selecting the button with the downward pointing triangle icon to the right of the Open button in the Open dialog).

All credit for this goes to MZ1987, who posted this procedure here. I am documenting it in my blog to make it easier for me to find in the future.

1. Open the model with Specify.
2. In the Opening Worksets dialog, select all user-created Worksets and choose the Open button. The values in the Opened column should all be Yes.
3. After the model opens, open the Worksets dialog. Select all of the user-created worksets and select the Editable button. Set the Open/Close state of each Workset to the way you want it to default in the Opening Worksets dialog. [This is the key step.]
4. Synchronize the model, using the Synchronize and Modify Settings option, NOT Synchronize Now. In the Synchronize with Central dialog, make certain that the User-created Worksets toggle is checked.

Close the model. The next time you, or anyone else, opens the model, they should see each user-created Workset defaulting to the Open/Close state chosen in Step 3. I have not yet experimented with this extensively, since my current goal was to get all Worksets set to Yes. It probably does not matter what the Open/Close state is on opening, just that you make the user-created Worksets editable and then set the desired state at that time, before synchronizing and relinquishing the user-created Worksets. I expect those settings will hold until the next time someone makes an entire Workset editable and also changes the Open/Close state of that Workset, and then synchronizes. So you may have to repeat this when that happens; we typically just borrow elements, rather than make an entire workset editable, so I do not see that being a major issue for my firm.

Autodesk Docs/BIM 360 Default Hub

Since I provide support to all Revit projects in our office, I am a member of all of the projects hosted on BIM 360. Most of these are on my firm's hub, but we have a number of joint-venture projects or projects where we are a consultant where the project is hosted on another firm's hub. I have long been annoyed that Autodesk has not provided a means to designate a default hub; they seem to set the one that is first alphabetically as the default most of the time, and that is not my firm's hub. It is particularly frustrating when I am in the web portal, on a project on my firm's hub, when Autodesk magically decides I need to sign in again (usually after a period of inactivity, of an apparently random amount of time, but not always) and, after doing so, it not only does not return me to the page I was on, but punts me off onto another firm's hub.

I am not alone in that frustration. I was amused to see one firm recently change the name of their hub, adding an exclamation point ("!") to the front of the name, so that their hub would be first alphabetically. I noticed because suddenly their hub was the new default hub. I suppose now there will be hub naming wars, as everyone else changes their hub's name to get it to sort at the top of the list.

I suppose I should be happy that the renaming did not break my access to that hub.

Revit: Level Name in Use - But It Is Not

We create new projects from a set of "prototype project" model files, one for each discipline, that are already set up with worksharing and standard worksets and are cross-linked to each other. Models are opened detached from central and then saved to the project folders as central models and the links are reloaded from the project-specific models.

There are six levels in (most) of the prototype models, and the levels in the other models are monitoring the levels in the architectural model, since the architects usually go first. Provided they move/rename the levels in the starter file, it only requires a Coordination Review to get the other discipline models to match the architectural model. (Some projects have more levels, which then need to be added manually.)

I was setting up the other models for a project in which the architectural model was already created, and the process above worked as expected until I got to the structural model. The architects had renamed ROOF to PENTHOUSE ROOF and LEVEL 4 to ROOF. For reasons I did not understand, the Coordination Review renamed ROOF to PENTHOUS, but I was able to change the name and get the monitoring straightened out. The problem was it refused to rename LEVEL 4 to ROOF. I thought may be it was an order of operations thing at first - maybe it was trying to rename LEVEL 4 before it renamed ROOF. But even after I got the PENTHOUSE ROOF level renamed correctly, it still would not rename LEVEL 4 to ROOF, even when doing it manually.

Revit kept claiming that the name ROOF was already in use. We have a Level Schedule in our files, to make checking the names and elevations of levels in a file easy, without worrying about whether a given level's extents will make it show in a given elevation or section - there was no level named ROOF there. I opened Dynamo, and added the Level node, which allows you to select a level, and it did not offer a level named ROOF in the drop-down. I synchronized, closed and reopened the file, hoping that might shake some phantom memory of the old ROOF level out of its system, with no success.

Then it dawned on me that when I renamed the old ROOF level to PENTHOUSE ROOF, it asked me if I wanted to rename views. I clicked on No*, so there was a plan view associated with the PENTHOUSE ROOF level called ROOF. I wondered if that was the reason why Revit would not let me rename LEVEL 4 to ROOF. I was going to rename the views eventually, so I did that and then tried to rename LEVEL 4 one more time. It worked! So it was the fact that there was still a view associated with the PENTHOUSE ROOF level that still had the old level name as the view name that prevented reusing that old name for a different level. I am writing this here in the hope that the next time I run into this, I will have a vague memory of having the issue before, and will search my blog to see how I solved it.

* - I almost never let Revit rename plan views when the name of the associated level is changed. That only changes view names where the entire view name is the level name, and we have many plan views in most models that have the level name in the view name, with additional text. Those will not get changed; I find it easier to use the Dynamo graph I wrote to search for a given string in view names and replace it with a different string when none of the views have had the name changed.