ACA Section Tail Scaling

Here is a heads up to anyone who may be placing Section Marks with "tails" in Model Space from a Layout through a Viewport. The AecCallout command has an apparent defect in the way it creates the anonymous block for the tail. It works fine when placing the Section Mark from the "Model tab" (when "Model" or TILEMODE 1, rather than a "Layout" or TILEMODE 0 is current). It also works correctly when in a Layout and working through a Viewport when the scale of the Viewport is the same as the scale set for "Model".

But if the Viewport's scale is not the same as the "Model" scale, then the anonymous block that gets created is improperly sized. The correct annotation scale (matching that of the Viewport) is applied to the tail block, but the improper size of the block definition results in the final block displaying the same size as one placed through a Viewport that has the same scale as "Model".

To avoid this problem, you can do one of the following:

• Place all callouts from the "Model tab" (TILEMODE 1), setting the desired drawing scale prior to placement.
• Remember to switch to "Model"/TILEMODE 1 and set the drawing scale to match that of the Viewport and then switch back to the Layout.
• Place the callout in the Viewport and then, after placement, change X-scale factor of the block to get it to be the right size [Viewport scale factor/Model scale factor]. The anonymous block created has uniform scaling, so the change to the X-scale factor will be applied to the Y- and Z-scale factors as well.

I imagine that I would generally be placing the callout in TILEMODE 1, but if not, I would most likely change the scale factor of the anonymous block, rather than hopping back and forth from "Model" to "Layout". As noted in this thread in the AutoCAD^® Architecture Discussion Group, this problem has been observed in the 2009, 2010 and 2011 releases.

The block at the other end of the Section Mark, displaying the Section Number and, possibly, the Sheet Number, does not suffer from this defect.

Revisions and Dependent Views in Revit

I came across an issue related to my previous post on Revision Clouds and Dependent Views in Revit^® Architecture. The floors on my project are shown in three sectors on three separate sheets at 1/4" = 1'-0", and I had a relatively small change to make within a single room in the middle or "B" sector that happened to be right next to the match line separating it from Sector "C" on my project. Due to the floor geometry, the match line is neither straight nor parallel to the dependent view cropping boundary, and at the revised area, a good deal of the room in which the change was made appears on the Sector "C" sheet as well.

I had made the change, clouded it and reissued the Sector "B" sheet without giving any thought to the Sector "C" sheet. Some time later, I opened the Sector "C" sheet and was checking to see if the revisions on it agreed with the plot in my half-size set and was surprised to find that an additional revision was listed. I quickly determined that the revision was for the change that I had documented in Sector "B" and that the reason it showed up was because the revision cloud, as I had drawn it, ended up being entirely within the annotation crop boundary for the dependent view shown on the Sector "C" sheet. That annotation crop boundary was a substantial distance beyond the model crop boundary, at what I believe was the initial default location.

Since the revision was generated by the revision cloud, there was no way to manually remove it from the list of revisions on the Sector "C" sheet. In order to remove the revision from the Sector "C" sheet, I edited the annotation crop boundary, dragging it as tight to the model crop boundary as possible, and then modified the revision cloud so that part of it extended beyond the annotation crop boundary. As noted in the previous post, once the revision cloud was not entirely within the Sector "C" annotation crop boundary, it no longer showed up in the Sector "C" dependent view and the revision no longer showed on the Sector "C" sheet, and I was good to go.

Modifying the annotation crop boundary caused a few annotation objects that had previously showed on the Sector "C" sheet to disappear, but these were all beyond the match line and still show on the Sector "B" sheet. I will need to remember to edit the annotation crop boundaries that are beyond a match line from the default location on future projects, and to keep in mind where those annotation crop boundaries are when placing future revision clouds in the vicinity of match lines.

Revit® Architecture Dependent Views and Revision Clouds

Another interesting Revit^® Architecture discovery I made the other day while scrambling to get some revised drawings plotted in time to reissue them yesterday. The floor plans and reflected ceiling plans of this project are shown at 1/4" = 1'-0", and three separate drawing sheets are required to do so. (See this article for the key plan from that project.)

One of the long sides of the building has an array of typical patient rooms, and there was a change to the location of the light fixtures at the patient room entrance alcoves along that entire side, due to a conflict with ductwork. We have a ceiling plan view of the entire floor, and that view has three dependent views, each cropped to one of the three sectors. Annotation placed in the dependent view shows in the parent view, and vice versa, so I often work in the parent view, since that gives access to the entire floor.

I thought I would be "efficient" to put all of the revision clouds for the revised entrance alcove lighting in one revision cloud object. You can draw multiple, separate revision clouds in sketch mode in a single revision cloud object. So I drew them all in one object on one floor, added revision tags to each sub-cloud (you have to reclick the tag tool in the ribbon for each additional tag to be added to the same object) and then clipboard copied the object and tags and pasted it aligned to the other floor. I was so proud of how efficient I had been, until I checked one of the sheets and found that the revision clouds did not show up! Then I opened each of the dependent views and saw that the revision clouds were not visible there, either.

I double-checked to see that other revision clouds I had done as individual clouds did in fact show in both the parent and dependent views (they did) and was on the verge of getting disfunctionally frustrated when it occurred to me that perhaps the reason why the clouds were not showing in the dependent views was because one cloud object had graphics that were beyond the clip boundary of each dependent view. I made two additional copies of the cloud object on one of the floors - so that I would have one for each depenent view. Then I edited each of the copies, deleting all of the clouds that were not in the dependent view to be served by that copy. Once that was done, the clouds showed up in the dependent views and I was back in business, after adding tags to the two copies and then deleting the mega-cloud on the other floor and copying the three new clouds and tags to the other floor.

In hindsight, it makes sense that an annotation object that falls outside of the annotation crop boundary would not show up in a particular dependent view, but that did not occur to me when I started the clouding task. I will have to keep that in mind in the future.