Keynote and Revision Schedules

[Scott D Davis]

I was working on a new Revit titleblock for our template, which contains a Revision Block area. I was trying to brainstorm a way to get the revision area in the titleblock to fill in automatically. I thought we could do this with a Schedule, but Revision information is not schedulable. Also, relating to another thread here, we need the revision block in the titleblock to only fill in if that sheet contains revisions. I placed a Revision Tag in a model, and filled out the Date, Description, Revision number, etc. Makes it really easy to cloud and Delta Rev A,B,C or 1,2,3, what ever your preference is. Problem is, there is no way currently that I can think of to 'harvest' that data back from the tag to include in the Revision block.

So here is my thoughts for wishlist items:

1. Revision Schedules - That fill in with the information from a Revision Tag.

2. Revision Tag with Sheet Recognition - The Revision Tag itself would be placed in a view. Then, when that view is placed on a sheet, the Rev Tag recognizes what sheet its on. (just like a detail callout, although it doesn't need to be displayed in the tag.) Then, we can create a Revision schedule, and then filter that schedule by sheet to only show the revisions on that particular sheet!

I think this could also be a solution for Keynotes. If the keynote tag would recognize what sheet it is placed on, we could then create a keynote schedule, filtered only to display keynotes on that sheet.

Anyone have any thoughts before I post to the wishlist?

[gregcashen]

Sounds like good workflow to me!

[sfaust]

Excellent. I was just doing this today and trying to think of this. This would be great to have. A variation would be to have an issue record which would be the same for all sheets Issue record isn't too tough to work around right now, but would be nice to have it easier and it seems like if we have a revision record it would be an easy implementation...

[Cathy Hadley]

Yes... I agree... one of the first issues I ran into during an Implementation...

they however put the revision date on every page... whether it was issued or not...

Still some sort of tags added to the titleblock that can be global...

[hj]

what we have done with keynotes is we added a shared parameter to the keynote called sheet. Then we filter our schedules where the sheet name is equal to the sheet parameter. For each new keynote you would have to make a new keynote type. You end up having a bunch of keynote types but it works pretty well.

For revisions we haven't broken it down by sheet but made one revision schedule (in the project template not the titlelbock file) which schedules revision tags. Copied the schedule to each sheet. This shows each revision on each sheet. (each revision becomes a new revision tag type) If you want to break it down by sheet I suppose you could do the same thing as we did with the keynotes.

[Scott D Davis]

Ultimately, keynotes should "read" information about the object that is being keynoted, much like a door tag. We tag a door, and the tag doesn't contain all the information, the door does. When we schedule the door, the tag simply puts the door in the schedule, and the door displays all of the information.

A keynote tag should simply be a pointer. In the object itself, there needs to be a "keynote" numbering system (like "Mark" in doors") and the description needs to be built into the object. This will allow the intelligence of the objects to already be available straight out of the library.

To put it another way, I should not have to place a keynote tag, and then type in a description and keynote number. I should be able to place a keynote tag, and the keynote schedule automatically fills in with the information that is included in the object.

HJ, how did you create you revision schedule?

[hj]

I agree with you about the keynote TAG. That would be very nice to have. Could there be a possible conflict when you need to note something that isn't connected to a specific item?

I believe I created the revision schedule as a note block which schedules the default revision tag shipped with Revit.

[Joef]

What happens from one revision to the next? If the revision information is linked to the revision tag, wouldn't it disappear from your schedule when you removed it for the next issue. Or do you keep all the revision tags on the drawing and simply balloon the most recent revisions? I think the most common practice is to erase the revision 2 tags when going to revison 3, but keep the revision 2 description in the schedule. This would be difficult if the revision description was linked to the tag. Perhaps I am way off on this but I thought I'd impart my .02 cents.

[Scott D Davis]

hmmm....intersting and I hadn't thought of that! How about using phasing? You could make a new phase called Rev 1, then have Rev 2, etc. Each phase would only show the clouds and tags for that revision, while the schedule could still display all revisions, as they would normally be in the titleblock. Plus if you are changing the drawings, the old info would still be there in the previous phase.

[hj]

What happens from one revision to the next? If the revision information is linked to the revision tag, wouldn't it disappear from your schedule when you removed it for the next issue.

For each revision you make a new revision tag type. just duplicate the type, give it a new number, descriptions, etc.

I see what you're saying about the tag having to stay around though... I think scott has a solution for that...although we shouldn't have to use a workaround like that.

[Scott D Davis]

Maybe this brings up a need for two kinds of Phasing: Model Phasing, and Sheet Phasing. Model Phasing would take care of Existing, Demo, New, etc. Sheet Phasing would take care of Schematic Design, Design Development, Construction Docs, Rev 1, Rev 2, Addendum 1, etc.

[PeterJ]

Surely this issue is going to be addressed by the guys at the factory.

I would deal with it by having an issue tool and when that tool was invoked all views that were changed since the previous issue would be recorded and hence the same information could be recorded for all sheets and an incremental tag notche dup by one for that sheet. I think it would still be the responsibility of the person working on the model to choose whether, how and what to cloud as that is a part of how we make our living but in principle it may be possible for Revit to shade an area where changes have occured to make things clear to us.

Personally, would be quite happy to abandon the revision cloud in favour of a light hatch or heavy rectangle, something that moves towards a recognition of the fact that we produce these sheets of paper using a computer and not by hand. If you wanted to get really smart you could use three densities of a dot screen (or colour) to represent current, last and last-but-one revisions and then abandon everything prior to that to avoid cluttering the drawing.

[hj]

haven't completely thought this out yet but I think it would really easy if you could select a revision tag type (say revision 1 if you're working on revision 2) and click a checkbox called "include in revision schedule" even though it's not on any of the sheets. For that matter, you could just place one of those tags on a sheet that you're not going to print out and it would appear on your schedule...

[gregcashen]

Maybe this brings up a need for two kinds of Phasing: Model Phasing, and Sheet Phasing. Model Phasing would take care of Existing, Demo, New, etc. Sheet Phasing would take care of Schematic Design, Design Development, Construction Docs, Rev 1, Rev 2, Addendum 1, etc.

Don't forget Construction Phasing for the CMs. :wink:

[PeterJ]

Don't forget Construction Phasing for the CMs. :wink:

I see Construction phasing as a nested issue such that it sits inside the designers general construction phase and then a revision phasing will be reltaed purely to documents and not have a real temporal relationship with the model at all.

[Haden]

I have tried just what you all are discussing and per HJ's technique for keynotes, I assigned a shared parameter called SHEET NUMBER to the revision tag symbol, and when I place a revision tag and clouds on a sheet, I make sure that at least one of the revision tags has the correct sheet number listed for the SHEET NUMBER parameter. Then, I make a schedule for each sheet, which is actually easy since I just copy the last schedule and rename it for each new sheet. I filter each sheet revision schedule to only include revision tags with the SHEET NUMBER parameter matching the name of that sheet.

It works, and it's relatively simple, but I'd love for Revit to recognize (as someone else has already mentioned) that these revision tags exist in a view which is on a sheet, so that I wouldn't have to assign that parameter.

As for deleting previous revisions, my experience has been that the standard practice around here is to leave the tags (triangles), but erase the clouds each time new revisions are noted. I would like the clouds to be able to go outside of the crop boundary, though, because sometimes you want to cloud things like levels or dimensions which "spill out" beyond the crop boundary. Also, I would like clouds to be less "click-intensive", such as a drag only method.

Ideally, though, Revit needs some kind of Issue tracking or Sheet Phasing as others mentioned, so that I could ideally include columns in my Drawing List to show a summary of which sheets were issued when. My current revision schedule process does not allow this.

[hj]

I would like the clouds to be able to go outside of the crop boundary, though, because sometimes you want to cloud things like levels or dimensions which "spill out" beyond the crop boundary.


We place the clouds on the sheet, not the views to get around this... They're easier to delete as well...