Thursday, March 1, 2012

DWFx markups in Revit

Lately I have been looking at Autodesk Design Review (ADR), especially while testing out the Android mobile version. I really think this has great potential to streamline the very chaotic nature of drawing markups in an AE practice. However I was very disappointed to find that the integration with Revit is extremely primitive and poorly implemented.

A seemingly common problem users run into is an error when synchronizing a central file that contains a linked markup:

Cannot save DWFx

This got me digging a bit deeper into the issue and at face value, it seems like there’s a simple solution: make sure the markup file is closed in ADR. However I ran into several occasions where the file was closed, yet Revit and ADR thought it was open for editing. I’m not sure if this is due to a network glitch, but I found it peculiar that when opening the file in ADR, it would say “read-only”, even though just seconds before opening, I was able to rename the file in Windows Explorer just fine. This issue was probably the reason why I found a decent amount of posts lamenting about similar cases, including some on the AUGI forums.

Typically when the markup is not being edited or is clear from the above mentioned issues, you can save without any problems and the status of each markup, including the history and notes added within the Revit project, are successfully saved to the DWFx file during a sync with central. In those instances where the markup was thought of as being edited, I worked around the issue by making a copy, deleting the original and then relinking the newly created file. I have not verified whether a simple rename of the file would have worked but it’s worth a try.

In Revit, the markups reside on the view workset of each view/sheet, which means only one person can edit that view/sheet and change the status of markups and add notes. Other views/sheets can be edited simultaneously. If you want multiple users to work on the same sheet, you’ll have to print a DWFx of the individual views and mark up those instead of working at the sheet level. If the reviewer wants to check progress by opening the markup, the file has to be copied and then opened separately to avoid the above mentioned error during a sync with central. I honestly do not understand why an option to open the markup in read-only mode doesn’t already exist within ADR!

The reviewer CAN open and work in the DWFx while users are in Revit picking up items identified in the markups and changing their status, however they won’t be able to save the markup edits until the reviewer exits. Note that a local file save does not save the DWFx. In my testing, if I canceled the markup saving when I got the infamous error, the Revit file sync also terminated. However a second synchronization went through and Revit did not attempt to save the DWFx file changes unless I made other changes to it. Once the markup was not being edited, I had to change something else in the markup settings in order for Revit to try saving it again during the next synch with central.

Rants

I was quite amazed that so many holes still exist in the DWFx workflow after all these years. So here are my personal rants for your enjoyment. Feel free to add your own in the comments:

  • Selecting a markup and typing "VH" to hide just that one markup results in all markups being turned off. Since each markup element gets placed in its own subcategory, why not modify only that subcategory’s visibility when this shortcut is used?
  • Every markup element gets its own duplicated subcategory in the Imported Categories tab of the V/G dialog. More sloppy coding??
  • Hiding an element in view when something is complete is one way to de-clutter your view and help you focus on those items that still need attention. The other method is to uncheck the visibility of one of the two subcategories for each markup, but these become too cryptic to identify when there are lots of them. However once the DWFx file is edited in ADR, re-saved and then re-loaded in Revit, visibility is re-set and all hidden elements re-appear! I mean, really?! Visibility of markup items should be remembered between re-loads and items should only become visible if their status has changed or notes have been added.
  • There are no controls within Revit like in ADR to use markup status highlighting (which has no degree of control either in ADR 2012). This is a significant problem. I looked at filters for a potential overlooked solution but there’s no way to access markup (imported categories) properties. We need controls to hide/color markups based on status so users can properly focus on what remains to be accomplished.
  • We really need the ability to open the DWFx as read-only so that markup updates are not hindered when the Revit project is synchronized with central.
  • If the error mentioned above pops up during a sync with central and the user dismisses saving the DWFx changes, they are not prompted to save them again unless further markup edits are done. Revit should attempt to re-save these changes back to the markup at the next sync with central even if no further edits are performed.

EDIT: Also refer to this related post by Steve Stafford.


Share/Save/Bookmark

4 comments:

Andrew W, said...

But at least we can markup drawings on our Android or iDevices!

Antony McPhee said...

I gave up printing to DWF. Revit crashes far too often. I retry every new version but still end up giving up. DWF used to be such a good format. Light, crisp. Now it is just a hugh mess. Do Autodesk get the work experience kids to code DWF?

plawton said...

The number of shortcomings in the product that you review is inexusable. Autodesk claims the premier position among developers of software for the AEC world (and others), but they seem to continually hire teenage programmers, who write something clever, then release it to the world with no apparent QC process. Then, when these new-hires realize that Autodesk is just a programming sweatshop, with no incentive to write clean, solid software, the new hires leave. So, Autodesk needs to con a new batch of college (or high school) grads, and the cycle starts again.

That would be the BEST case scenario - it would be far worse to discover that they have a bunch of experienced programmers in house, who simply ignore the constant stream of problems and shortcomings that they continue to spew.

Either case makes me sick to my stomach, and bodes very ill indeed for the US economy.

Dave Baldacchino said...

Thanks all for taking the time to comment.

Sometimes it sure feels like it. What a sad state...I used to get extremely excited about the software development process, but when I keep coming across a lot of issues that impact our work every single day which are completely ignored in order to make way for fancy tools (I avoided using any expletives but I have plenty in my head right now) that most architects just use in their dreams, it makes me sick to my stomach.

Post a Comment