I will correct the original post, but I wanted to clarify, all Keynoting Features are available for usin 3D views, including tagging materials by Keynote. I was correct about not being able to tag materials directly, and what I didn't point is that you cannot tag Rooms/Spaces/Areas, but then we can't see them in 3D either.... :-(
Thanks to my friends at Autodesk for pointing out my mistake.
Showing posts with label errors. Show all posts
Showing posts with label errors. Show all posts
Saturday, April 09, 2011
Wednesday, November 10, 2010
The Danger of Shared Coordinates
So many people have seen or gotten this error before:
"Linked file File FILE NAME.rvt cannot be saved because it has changes in more than just shared coordinates and therefore can invalidate Local Files owned by you."
What this error hints at is that Shared Coordinates are invasive and indicate that even when you think you've done nothing, something has occurred between linked file because they have Shared Coordinates. What we've seen recently with our project that is in Revit Server is that shared coordinates are very invasive! We've seen a number of "false" locks on Central Files from users who are not actively working on the Central File that is locked. Instead the presence of Shared Coordinates between linked files causes a lock on one of the linked the Central File by a user working in the host file.
To be clear, none of these false locks have caused lost work, or prevent team members from getting their work done. There have been a few delays, but mainly it has left us scratching our heads, attempting to determine:
"Linked file File FILE NAME.rvt cannot be saved because it has changes in more than just shared coordinates and therefore can invalidate Local Files owned by you."
What this error hints at is that Shared Coordinates are invasive and indicate that even when you think you've done nothing, something has occurred between linked file because they have Shared Coordinates. What we've seen recently with our project that is in Revit Server is that shared coordinates are very invasive! We've seen a number of "false" locks on Central Files from users who are not actively working on the Central File that is locked. Instead the presence of Shared Coordinates between linked files causes a lock on one of the linked the Central File by a user working in the host file.
To be clear, none of these false locks have caused lost work, or prevent team members from getting their work done. There have been a few delays, but mainly it has left us scratching our heads, attempting to determine:
- Who has the file locked.
- How the lock got there in the first place.
Thursday, May 07, 2009
2010 Graphic Error
Wednesday, March 04, 2009
Missing Room Tag
This morning I had a teammate come to me and ask why a room was not showing up on her plan. I jumped in to investigate. Here are the parameters of the issue:
-Room & Tag could be placed on a ceiling plan
-Room & Tag could not be placed on Floor plan (received the check your visibility graphics error message)
-Room has all the same parameters as the rooms next to it (workset, height, etc.)
Q: Why would this room tag not show while all the others would?
A: Plan region.
A plan region had been placed in one location of this room to show the clerestory that was above the cut plane. The plan region was bigger then the wall thickness so cut into the space the room was in and was preventing the room from being visible. I don't fully understand why the plan region would do this considering the height the plan region was taken at would also cut through the room. I know of plenty of errors that plan regions seem to cause such as hatches in walls suddenly showing up as the wrong hatch because it has a plan region in one area of the wall. And there are plenty more. Just as a forewarning be careful where & when you use these. It may cause you more grief then it's worth.
-K-
-Room & Tag could be placed on a ceiling plan
-Room & Tag could not be placed on Floor plan (received the check your visibility graphics error message)
-Room has all the same parameters as the rooms next to it (workset, height, etc.)
Q: Why would this room tag not show while all the others would?
A: Plan region.
A plan region had been placed in one location of this room to show the clerestory that was above the cut plane. The plan region was bigger then the wall thickness so cut into the space the room was in and was preventing the room from being visible. I don't fully understand why the plan region would do this considering the height the plan region was taken at would also cut through the room. I know of plenty of errors that plan regions seem to cause such as hatches in walls suddenly showing up as the wrong hatch because it has a plan region in one area of the wall. And there are plenty more. Just as a forewarning be careful where & when you use these. It may cause you more grief then it's worth.
-K-
Wednesday, November 05, 2008
CSI Revit (Part II): Tracking down the culprit
We left with how to read journal files, and a suggestion on practicing reading them. Today, we're going to talk about where and how they can come in use for some computer forensic detective work.
Allow me to set the scene.
The first step, was to figure out what could be done in the short term to deal with the problem. This is where our rule about multiple local files came in handy the first time. Team members were able to immediately start rescuing views by opening old local files and copying/pasting the missing Keynote Tags from old to current.
The next step was to figure out what happened to the Keynote tags, needless to user error was the primary suspect, but, whose error, and when? How many times have we all worked on large Revit projects, and had something "go missing" or something was "deleted" and we are left to wonder, what, who, when, how... Well one of our top users decided to track down what happened.
To start, he looked through the local files, local file history, and central file history to narrow down when the keynotes disappeared. For those who don't know, for both central and local files you can pull the save history from the File menu (see screenshot).
Once he had an idea of where to look more specifically is where the journal files became useful. With some sense of the approximate time to look for, our investigator used the find command to look for keynotes. What he eventually found was this in a journal file...
One of the users on the project had used "Select All Instances" of the keynote family used in the project, and hit "delete". For some reason this user was under the impression that "Select All Instances" was valid only for the active view! As it was, the user was helping our investigator, and was the one to find the four pages of text showing every keynote being selected, it was quite the teaching moment for the whole team.
While it took the lead investigator a good chunk of his day to sort through all the related files. It was needless to say quite useful to determine what had happened, most importantly, to help assure it doesn't happen again. While the copies of files, and back-ups helped with restoring the missing work, and helped to narrow down the time period in which the mistake happened, without the user's journal file there would have been no way to so clearly identify the culprit.
Check back at the end of this week (or beginning of next), for the my wrap up on journal files.
Allow me to set the scene.
- At Burt Hill we encourage and keep multiple local files when working on a workshare project. This has come in use multiple times, and for multiple reasons. We usually suggest that a user maintain a week's worth, and sequentially overwrite the files.
- A project team has been working diligently to their deadline. Annotating views, drawing details, setting up sheets, running check prints.
- They're busy working the weekend, 12 hour days to meet their Monday evening print deadline.
The first step, was to figure out what could be done in the short term to deal with the problem. This is where our rule about multiple local files came in handy the first time. Team members were able to immediately start rescuing views by opening old local files and copying/pasting the missing Keynote Tags from old to current.
The next step was to figure out what happened to the Keynote tags, needless to user error was the primary suspect, but, whose error, and when? How many times have we all worked on large Revit projects, and had something "go missing" or something was "deleted" and we are left to wonder, what, who, when, how... Well one of our top users decided to track down what happened.

Once he had an idea of where to look more specifically is where the journal files became useful. With some sense of the approximate time to look for, our investigator used the find command to look for keynotes. What he eventually found was this in a journal file...

While it took the lead investigator a good chunk of his day to sort through all the related files. It was needless to say quite useful to determine what had happened, most importantly, to help assure it doesn't happen again. While the copies of files, and back-ups helped with restoring the missing work, and helped to narrow down the time period in which the mistake happened, without the user's journal file there would have been no way to so clearly identify the culprit.
Check back at the end of this week (or beginning of next), for the my wrap up on journal files.
Monday, October 13, 2008
More phase issues (graphics)
Hello again,
Another issue I found while running the education session last week was dealing with the results of a new insert in an existing wall.
When you place something like a door into an existing wall object, lines for the door, show up in your existing floor plan views, and there is a quasi selectable "infill" object. I also do not remember seeing this behavior in previous versions of Revit.
Another issue I found while running the education session last week was dealing with the results of a new insert in an existing wall.
When you place something like a door into an existing wall object, lines for the door, show up in your existing floor plan views, and there is a quasi selectable "infill" object. I also do not remember seeing this behavior in previous versions of Revit.

Sunday, October 12, 2008
Inserts in Existing Walls
So I realize I've been lapse on my posting of late. Mostly because I haven't much I'm in a position to share. That said. I was recently running a week of education based on our new curriculum and we (the class and I) ran into a really odd error that we had not seen previously.
Specifically the class was focused on Phasing in Revit. We were going through how you can add a door to an existing wall. In our case, we had already deleted an existing door from the same wall object, and there was an infill portion of new wall where we had removed the door. As part of the class we had changed the wall type of the infill, and we had made it larger then the existing wall. When we placed a new door, the new door took on the dimensions of the new wall infill, and the existing wall was not cut.
With a little bit of playing around, we determined that the door was hosted to the new infill wall, and that by using the "Rehost command" in the options bar we were able to host the door properly to the existing wall. I will warn you that getting the door to rehost properly can be tricky. The behavior of hosting to the new infill seems to be consistent, as students saw the same behavior, and I was able to re-create it again too (admitedly all on the same project file). The training file was started in 2008, before being upgraded. None of remeber seeing this behavior previous to 2009. I do know that Autodesk has had some sample file(s) with this behavior, and they used it as a puzzler at AU2008, however in that case it was a plumbing fixture, not a door.
So, the short is, the behavior is not completely new, but I don't remember it being as prevalent previously. So take this as a word of caution.

With a little bit of playing around, we determined that the door was hosted to the new infill wall, and that by using the "Rehost command" in the options bar we were able to host the door properly to the existing wall. I will warn you that getting the door to rehost properly can be tricky. The behavior of hosting to the new infill seems to be consistent, as students saw the same behavior, and I was able to re-create it again too (admitedly all on the same project file). The training file was started in 2008, before being upgraded. None of remeber seeing this behavior previous to 2009. I do know that Autodesk has had some sample file(s) with this behavior, and they used it as a puzzler at AU2008, however in that case it was a plumbing fixture, not a door.
So, the short is, the behavior is not completely new, but I don't remember it being as prevalent previously. So take this as a word of caution.
Subscribe to:
Posts (Atom)