Keynote Schedules Not Updating

I wrote a post in April last year when we were observing some projects that would not update their keynote schedules during printing.

When they issued 2018.3 that issue was reportedly resolved. Moving forward into 2019 and 2020 versions it seems true. However we've seen a few projects that seem to continue to exhibit the problem. Specifically a keynote schedule does not show all of the keynotes that are actually visible in views on the sheet.

With these troubled project files we can force a regeneration IF each sheet view is open during printing. Like before turning the annotation crop boundary off/on or on/off will cause a regeneration too. However printing is when it matters the most. More testing is required before I can be certain there is an ongoing issue in the more recent releases but these projects do exhibit the problem in more recent versions too.

The current solution is to open all the sheets that must print first and then print to PDF. Alternately open a sheet view and print and repeat for all required sheets. If all the views are open then the revision schedule regenerates (you can watch it happen). The sheet view does not have to have Revit's focus, just has to be open in the background at least. Any sheet views that are not open won't refresh.

Work Plane Based Families and Rotate w Copy

I participated in a thread at Autodesk's Revit forum and it took me far too long to catch on to the issue described at the outset. I should have retraced the thread sooner, but I did get there eventually.

I'm referring to the Rotate tool and its Copy option, this...

The issue boils down to this: the Rotate with Copy option works/affects a Work Plane-Based (and face-based) family differently than when a family is merely hosted by a Level (all non "based" families). Let's start here, imagine I want two screens on my desk like this.

These are stock families: TV - Flat Screen.rfa and Desk.rfa The desk has a top surface that isn't visible in plan view so it can't act as a face to host the TV. I changed that. The TV isn't a work plane-based family. In a plan view, when I place it on the desk it ends up eaten by the desk because it looks like this in a 3D view.

Sure, I can use its Elevation from Level parameter to put it on the desk (an illusion of a relationship). When I move the desk I need to remember to select the TV too (or make a group...or...I digress). I get the clever idea, "Make this family Work Plane-Based, that's easy!"

Using Rotate with Copy should give me the result I want in the first image and it does until I check the box for Work Plane-Based. The angle I decide I want between the screens is 22.5 degrees. I added a couple reference planes for the images to help see what happens, the desired result.

That's what I want except that they should be hosted by the desk, not relying on using the Elevation from Level parameter. When I use Rotate with the Copy option after editing the TV family to make it Work Plane-Based (also Always Vertical is checked) I get this result.

Notice the TV angle itself is correct but it's location is wrong...and a warning message appeared to help me notice... It's been moved/copied by double the input value of 22.5 degrees using the origin of rotation correctly and managed to maintain the angle I wanted. This next image summarizes what happened.

That's weird enough on its own but I can go weird by one more, un-check the TV's Always Vertical parameter. After running through the exercise again I get this outcome.

This time it applied the rotation input angle of 22.5 degrees x 2 = 45 degrees to both rotating the family and its position. This time it did it fully wrong while the previous time it only did it half wrong.

Introduce a Floor, instead of a desk family, into the mix and place the TV family before it is Work Plane-Base with Always Vertical and this happens. No rotation, just copy and in the same place no less.

When the TV family is Work Plane-Based and Always Vertical is used then it works wrong in the same way as relying on the desk's face as the host did.

I imagine Revit is attempting to relate the rotation and copy actions to the family's host, since that is the work plane the family is hosted by. Clearly it is unable to do so properly. I think it is reasonable to expect to get the same result whether level based or work plane-based. This post and the images are from using Revit 2020.2 but I did the same things in Revit 2016 with the same results. This has been around for quite awhile now.

If it is any consolation, the Mirror and Polar Array tools don't suffer from this malady but each have their own prep work required to make them a ready replacement.

Cannot Publish Coordinates

I've run into this with a couple clients recently, this warning message appears:

Quirky work-around warning...

• Building Model: Make sure you have a Local File for it (I save to my own PC)
• Site Model: Change the saved path to the Building's Central File to your own Local File instead
• Site Model: Publish Coordinates
• Site Model: SwC (should succeed and get a prompt to Save changes to the linked file)
• Site Model: Close
• Building Model: Open your existing Local File SwC (passes shared coordinate data to central)
• Building Model: Close
• Site Model: Reset the path for the Building to the central location

Any future Publish Coordinates, if necessary, should work after that.

The error message is tied to linked files (DWG) that are actively changing. Revit would notice those links were different than the version it had a record of during a SwC, even though it does not reload links during a SwC. I imagine it takes note of the file date or something high level that defines the DWG in the database. The solution then was to reload those links before using SwC.

I have found since that it has been possible to avoid the warning if any linked DWG files are unloaded prior to using Publish Coordinates. In at least one situation we had to go through the steps above even when there were no DWG's linked/imported. Autodesk documentation says in some cases it can be associated with file corruption.

Quirky...     

Active View can Matter When Linking Using Positioning Auto - Center to Center

If you link a model via Positioning: Auto - Center to Center in a plan view its zero elevation will align with the host model's zero elevation.

Do that in an elevation or section view however and the linked model may not rest at the correct Zero elevation. The discrepancy man be very subtle or quite obvious. It will depend on the adjusted extents of the view that is active.

The trigger appears to be the elevation or section view being cropped very shallow (only one level visible) prior to linking the model (tested as far back as Revit 2015). If all the levels are visible in the view it seems to be more reliable.

Far safer me thinks to just link via a plan view, something to watch out for. 

Navis 2018.1 Update and Autodesk Desktop App

I've had a few successes with AdA recently. It applied its own update and I've received a couple of notices for updates too. This morning I got such a message about Navisworks but when I attempted to install it it I was informed the digital signature couldn't be verified.

There didn't appear to be any way around this via AdA so I visited the Autodesk Portal for my account. I found the update at the top of the list so I downloaded and installed it successfully that way instead.

Insert From File and a Worksharing File

I bumped into a subtle conflict this evening. I created a new file from a stock template. I then used Insert from File > Insert Views from File to acquire a few drafting views. When I closed this new project and decided to open the file the harvested drafting views are stored in this message appeared.

Keep in mind that no files were actually open at the moment. I was looking at the Recent Files list yet when I attempted to create a new local file for the project I just used Insert From File on the message popped up. This means that the file is technically still open in RAM as far as Revit is concerned, it's just not open for me to interact with.

I had to exit Revit so it could relinquish its hold on the file before I could start Revit up again to get back to work.

My Ongoing Saga of Autodesk Desktop Application

This poor half blind, lame in one-leg, incontinent piece of software continues to amuse and aggravate me. Twice in the last two weeks it has let me know I'm missing some updates.

Amusingly and aggravatingly ... they've all been installed already.

So I indulge it and try to install them again thinking that will help it see better. Nope ... sure enough ...the application that needs the update figures out it is installed already.

Typical response for all four items...

Revit Viewer and Worksharing

Reading a thread at Autodesk's Revit Community forum David reminded me of the quirky issues related to the Viewer when worksharing is being used. If someone launches Revit Viewer and then tries to open a project that has enabled worksets they'll get this warning.

When the file is opened and they try to print, export or save they'll get this warning even though they haven't DONE anything...but Revit has made changes to the file in order to create a new local file.

Okay, let's follow the instructions in the first warning message. We'll open the project using Detach from Central. Sorry, "Do not pass Go, do not collect $200". That process also changes the file. Still no export, save or print for you!

The ONLY way we can use Revit Viewer to open a project with Worksets enabled is to open the Central File itself, by un-checking the option to Create New Local. This means that user is now working on the real central file with Revit Viewer.

If you do this you will likely encounter several of the messages shown in the first image. The projects I've done this with all have linked files and it seems to pop up for each link (RVT) used and once more if there are any linked/imported DWG files.

To the good, they won't be able to synchronize their work nor will it prompt them to Save when they close the file. They won't be able to edit much of anything though because they can't borrow elements. The notion of using Revit Viewer to poke around the model, do some experimental stuff within the model is off limits to Viewer mode. We are able to print or publish to DWF, because those formats don't create an editable version of the data/model.

It seems to me that the notion of Revit Viewer for workset projects is fundamentally flawed, if we're thinking of it as a way for Project Managers to poke around, do anything other than JUST LOOK at views. If we'd like them to be able to cut a section view or hide things, do anything that requires temporarily borrowing something, that's all off limits to the Viewer.

For that we'll have to show them how to use Detach from Central AND to be careful not to save that file overwriting the original project.

Revit 2017 - Filters and Reference Planes

Filters have been expanded to see Reference Planes.

You're probably aware that Reference Planes don't have many parameters, just these three instance parameters: Scope Box, Name and Subcategory. They don't have any Type Parameters because they aren't defined by types like grids or levels for example. If we examine the Filters dialog and see how those three parameters play out as criteria we'll find they don't.

The More Parameters... or Browse button to its right are tempting but we still can't create parameters associated with Reference Planes.

This makes it rather difficult to actually use a Filter for Reference Planes, criteria based filters anyway. We can select them (Reference Planes) first and create a Filter based on selection but that's not really much different than using Visibility/Graphics to turn them off or override their appearance.

While it makes for an enticing item in the list of what's new it will only serve to frustrate you if you pursue it. It's a shame that we aren't offered at least the Name parameter to use in a filter. It looks like the critical path for this feature wandered into the weeds and got stuck in some quicksand.

I'm sure we'll take good advantage of being able to differentiate them from one another and control their visibility using Visibilty/Graphics and View Templates despite this situation.

Multi-Segment Grid and Crop Boundary Interaction

When one segment of a multi-segment grid passes entirely beyond a views crop boundary that segment is not displayed. That seems reasonable to me. The annotation at the end of the grid however also disappears and that doesn't seem as reasonable to me. I'd like that to remain especially since (when) that end isn't coming into contact with the crop boundary. It is easier to see with a video capture embedded below. Whaddyathink?

Revit 2017 - Text Element Error Message

I created a drafting view and placed a single text element. I type a simple sentence and then clicked the new Close button on the ribbon. I received this nonsensical warning for my effort.

Doesn't seem to matter what view I am placing text in, clicking the Close button pops up the warning. I'm curious if others are seeing this too? I was using the stock architectural template from the Imperial Library. Simple fix is to just finish text in the same old way, don't use the Close button.

Edit: A little more testing and the plan view Level 1 doesn't seem to mind anymore. When I tried it again in the Construction template the floor plan view Level 1 didn't complain but Level 2's did and the Ceiling plan for Level 1 did too. Okay...more weirdness. This is after placing text in an Elevation view.

Traded emails with Aaron Maller last evening and pinned down the circumstances that this issue is reproduceable. It boils down to placing text in a view and then placing text in another view while the previous view is still open. Revit doesn't seem to recognize that the new text is in a different view when the Close button is used. Here's a video explanation.

Family Templates and Reference Plane Inequity

This is subtle but still a source of amusement or annoyance. Start a new family using the Generic Model template and try to copy an existing Reference Plane. Nope, the Copy tool is disabled.

Now try it with the Furniture template. Ah, Copy is enabled.

Try it in the Casework family template. You'll find Right, Left and Front Reference Planes are forbidden while the Center (Left/Right) and Back Reference Planes are not. That makes sense. Wait, what?

Okay, the rule is copying a Reference Plane working on furniture is okay and doing that in Generic Model templates = BAD? Doing it in the Casework template is, well it depends...

Actually the only rule is that you can expect some reference planes in some templates to be forbidden to copy while others are not affected by such thinking. Ralph Waldo Emerson cautioned us to avoid a foolish consistency. In this case a little more consistency wouldn't be bad.

...I'm not asking for all of them to be forbidden either...if you're wondering.

Revit Extension and the Big Pause

I've noticed that when I start sketching walls in a new project that at the third segment Revit decides it needs to PAUSE before continuing. It seems it has something to do with having Revit Extensions installed. It thinks needs to add some parameters and interrupts my sketching to do that. Bill (Mr. BIM Thoughts) helped point me toward this bugger the other day when were discussing a few workstations that were pausing to install/update the extension...much worse pause.

If you experience this too...might be the same situation for you.

Revit Version Build Update and Service Pack Naming

Bill (Mr. BIM Thoughts) shared this subtle bugger with me the other day.

Oooh boy... so Revit 2016 R2 is called Update3 behind the scenes if you look at the Control Panel\Programs\Programs and Features > View Installed Updates and Revit 2016 R2's update is called Update 1 for R2...

Phew...just when I think I understand the naming...

Doors and a Sliver of a Room

Following on my post yesterday regarding Doors and Rooms, if you happen to have a room that is NOT at least 14 inches deep you will find that Revit is unwilling to report either its To Room or From Room parameter. If you've been reading this blog a long time you may remember a post I wrote which included a short video that mentions this issue?

A room like pictured below will work because it is 14" deep.

However the room pictured below won't be recognized and the corresponding parameters will be blank, in this case the To Room parameters.

If you are familiar with the Room Calculation Point (I call it RcP) feature it can be used to influence this issue.

Keep in mind it will also negatively affect which room you can regard as the To Room, if not for this door specifically any other doors that need the opposite behavior.

The Room Calculation Point (RcP) feature was added to doors to provide a way to change how the To Room assignment is controlled. Originally the To Room value for a door was (still is without the RcP being enabled) decided based on the side of the wall the door swings in toward.

There are doors which must swing out of a room but still belong to the room they swing from. For example a classroom's door (like shown in the images above) often swings outward to the corridor (often set into an alcove), for exiting requirements usually. However we still think of and document the door as belonging to the classroom, not the corridor.

If the door is placed so that the panel swings into the classroom (using stock doors) then the To Room parameter is assigned to the classroom. If we then flip its orientation so the panel swings out of the classroom the To Room value remains associated with the classroom (check out the post I mention above for a video of this behavior).

The RcP feature changes that behavior to alter the To Room value to follow the flip of the door orientation regardless, which means in my example, and the images above, the To Room value would change to reference the Corridor instead.

May you have sliverless designs...

Stretching Schedule Properties Dialog

When we stretch the schedule properties dialog only the Available Fields list gets wider. The side dedicated to the parameters assigned to the schedule gets no love.

It's been this way for quite awhile but it still seems strange to me...

Revit MEP - Detail Callout Bias or Gotcha

Many of Revit mEp families use a nested annotation symbol to provide the standard graphics we are used to seeing in electrical documentation. Here's a little example of a few of these families.

If you created a Callout view and these symbols vanish my bet is that you've used a Detail Callout. Here's what a Detail Callout view of the same families looks like.

It's definitely a quirky thing, but these nested annotations in outlets don't show up in Detail Callout view. Feel free to start trying adjustments to Visibility/Graphics, Detail Level, Discipline and more...I've been down the road already. I'm pretty sure we're looking at a bug, or at least a conundrum brought about by the way these nested annotations work.

This view type is also fussy about creating other elements, like a room/space for example. As such I understand that this view type is intended as the last stop or end of the road with regard to drafting up a detail, for detailing not modeling with. It's just odd that these annotation elements won't appear in the view.

If you want an enlarged plan to show these annotation then avoid the Detail Callout, use the Floor Plan type instead.

Revit MEP - Conduit Run Schedule is Biased

I think it is a Reviteristic (read quirky or bizarre) that a Conduit Run Schedule will only see types that are created based on Conduit without Fittings. I'm pretty sure we'd all like schedules to include runs that use Conduit WITH fittings too. I understand that the fittings make it harder to provide a summary of a run but that's kind of the point isn't it, to do the things that are hard for us?

If we follow the help documentation advice to add a shared parameter to conduit and conduit fittings we can create a schedule that summarizes runs via a Multi-Category schedule. Unfortunately the very desirable and important Length parameter dies to us in that context, no joy there.

Dockable Windows

Revit has supported docking the Project Browser, Properties Palette, System Browser(for MEP) and Reconcile Hosting for a few releases now. I find new users often struggle with the actual task of docking them because the UI interaction isn't entirely intuitive. There are graphic cues offered but users don't seem to recognize them right away. I find I have to make a point of stressing that the location of the cursor is paramount and that while they should be looking for the visual cues, the cursor is what drives them.

I made this short video (Two Minutes) to help capture the subtlety I'm talking about.

While I am at it, personally I find Reconcile Hosting hard to find. It has a button on the Collaborate ribbon > Coordinate panel but I also expect it to be lurking on the View ribbon > User Interface. That's because the Properties Palette, Project Browser and System Browser are there and Reconcile Hosting is the same sort of thing. At least I think so since it can be docked among the others. I also find it quirky that, since there is a button for Reconcile Hosting, there isn't a button for the System Browser on the Systems and/or Analyze ribbons.

Filled Regions and Arc or Radial Dimensions

Alex at RFO brought up a quirky dimension issue when we use Filled Regions. We can apply aligned dimensions to a finished region's sketch but if you want to use a Radial or Diameter dimension on a arc segment, after finishing the sketch, Revit turns a blind eye to it. The dimension tool doesn't recognize the arc segment of the finished filled region.

Alex told me to fix it, so this squeaky wheel post is my contribution to fixing it. :)

For now the work-around is to drop a detail line on top of the arc segment, the dimension tool will see that.

Definitely fits in the Dept. of Quirky.